Zum Inhalt springen
buybitcoinsmart

Glossar / Protokoll und Upgrades

OP_CHECKTEMPLATEVERIFY

Auch bekannt als CTV, BIP119.

Was ist OP_CHECKTEMPLATEVERIFY?
OP_CHECKTEMPLATEVERIFY ist ein vorgeschlagener Opcode, der es einer Ausgabe ermöglichen würde, sich im Voraus auf die genaue Transaktion festzulegen, die sie ausgeben darf, bis hin zu ihren Ausgaben und Beträgen.

Spezifiziert im BIP-119.

BIP-119 beschreibt ihn, Jeremy Rubin veröffentlichte den ersten Entwurf im Januar 2020, und das Netzwerk hat ihn nicht übernommen. Der Opcode würde einen 32 Byte großen Hash vom Stack nehmen und fehlschlagen, sofern nicht ein Hash der Vorlage der ausgebenden Transaktion übereinstimmt, also ihrer Version, ihrer Locktime, der Anzahl ihrer Eingaben, ihrer Sequenznummern, ihrer Ausgaben und des Eingabeindex. Nichts in Ihrer Wallet verwendet ihn, und nichts wird es tun, bis ein Soft Fork ihn aktiviert.

Wie er funktioniert

Status: vorgeschlagen, nicht aktiviert. BIP-119 ist seit 2020 ein Entwurf, eine vorgeschlagene Aktivierung im Jahr 2022 rief genug Widerspruch hervor, um auf Eis gelegt zu werden, und Bitcoin Core enthält keine Deployment-Parameter für ihn.

Das Design nutzt einen alten Upgrade-Trick. Der Opcode 179, früher OP_NOP4, tut derzeit überhaupt nichts, ein Skript, das ihn enthält, ist also für jeden Node im Netzwerk gültig. Ein Soft Fork würde dieses Byte neu definieren, sodass aktualisierte Nodes die Prüfung durchführen, während alte das Skript weiter durchwinken, denselben Weg, den CLTV über OP_NOP2 und CSV über OP_NOP3 genommen haben.

Was gehasht wird, ist mit ungewöhnlicher Sorgfalt gewählt. Die Vorlage umfasst die Ausgaben, die Beträge, die Anzahl der Eingaben und ihre Sequenznummern, lässt aber bewusst die Outpoints aus, also die Txids der Coins, die ausgegeben werden. Sie wegzulassen hat zwei Folgen, auf denen der ganze Vorschlag ruht. Erstens können Sie den Hash berechnen, bevor die finanzierende Transaktion existiert, und genau das erlaubt es Ihnen, eine Kette künftiger Ausgaben aufzubauen und sie dann zu finanzieren. Zweitens kann eine Vorlage keine Festlegung auf sich selbst enthalten, die Beschränkung kann also nicht endlos wiederholt werden, weshalb ihre Befürworter sie den engen Covenant nennen.

Das Ergebnis ist eine Ausgabe, deren Txid schon vorher bekannt ist. Eine Wallet kann Ihnen einen Beleg für eine Zahlung aushändigen, die später existieren wird, und beweisen, dass keine andere Ausgabe dieses Coins möglich ist.

Wo er auftritt

OP_CHECKTEMPLATEVERIFY läuft nirgends im Mainnet, der Ort zum Nachsehen ist also die Gruppe von Anwendungen, die auf eigenen Signets aufgebaut sind und ausgeliefert würden, wenn der Opcode aktiviert würde.

Überlastungskontrolle wird am häufigsten genannt. Eine Börse, die auf einen Gebührenanstieg trifft, zahlt 1.000 Auszahlungen in eine einzige Ausgabe, die sich auf einen Baum weiterer Zahlungen festlegt; jeder Nutzer kann später seinen eigenen Zweig erweitern und die Lieferung entgegennehmen, wenn die Gebühren fallen, und die Börse hat eine Ausgabe statt tausend ausgegeben. Tresore sind das zweite: Eine Auszahlung muss zuerst in einer Zwischenausgabe mit Verzögerung landen, was Ihnen ein Zeitfenster gibt, die Mittel in die Cold Storage zurückzuholen, wenn der Antrag nicht von Ihnen stammte. Zahlungspools und die nicht interaktive Finanzierung von Lightning-Kanälen nutzen dasselbe Muster: erst festlegen, dann erweitern.

Für jeden, der Bitcoin kauft, ist die ehrliche Einschätzung, dass dies nichts ändert, wonach Sie handeln könnten. Es lohnt sich, das Kürzel zu kennen, weil es ständig in Debatten darüber auftaucht, was Bitcoin werden sollte, und weil die Tresorfunktionen, mit denen manche Verwahrungsdienste werben, tatsächlich durchsetzbar wären, wenn er jemals aktiviert würde.

OP_CHECKTEMPLATEVERIFY vs. OP_CHECKLOCKTIMEVERIFY

OP_CHECKTEMPLATEVERIFY beschränkt die Form der ausgebenden Transaktion, während OP_CHECKLOCKTIMEVERIFY beschränkt, wann eine Ausgabe erfolgen darf, und nichts darüber sagt, wohin das Geld geht. Wegen der nahezu identischen Namen werden die beiden ständig verwechselt.

Der andere Unterschied ist der Status, und er ist der entscheidende. OP_CHECKLOCKTIMEVERIFY wird seit Block 388.381 am 14. Dezember 2015 durchgesetzt und täglich von Lightning, Treuhandskripten und Vererbungs-Wallets genutzt. OP_CHECKTEMPLATEVERIFY wurde noch nie von einem einzigen Node im Mainnet durchgesetzt. Wenn ein Dienst Ihnen sagt, Ihre Coins seien durch eine Vorlagenfestlegung geschützt, beschreibt er etwas, das das Netzwerk derzeit nicht prüft.

Nicht zu verwechseln mit

Häufig gestellte Fragen

Ist OP_CHECKTEMPLATEVERIFY auf Bitcoin aktiv?

Nein. Er ist ein Entwurfsvorschlag, der einen Opcode belegt, der derzeit nichts tut, kein Node setzt ihn also durch. Jede Aktivierung bräuchte einen Soft Fork mit Parametern, die nicht in Bitcoin Core aufgenommen wurden.

Würde CTV rekursive Covenants erlauben?

Nein, und das ist der Zweck des Designs. Die Festlegung ist ein flacher Hash einer einzigen Transaktionsvorlage und kann keine weitere Festlegung enthalten, eine Beschränkung kann sich also nicht an jede künftige Ausgabe erneut anhängen.

Weiterlesen

Verwandte Begriffe

Mehr zum Thema Protokoll und Upgrades

Diese Seite auf Englisch lesen