OP_CHECKTEMPLATEVERIFY

Anna möchte Geld zurücklegen, das später zwischen Peter und Eva verteilt werden soll. Dabei will sie sich nicht allein auf das Versprechen eines Verwalters verlassen. Nicht ausgegebene Mittel sind in Bitcoin als Transaktions-Outputs, UTXOs, verzeichnet: Jeder trägt einen Betrag und die Bedingungen seiner Verwendung. CTV könnte diese Bedingungen um einen konkreten Verteilungsplan ergänzen. Beim Ausgeben würden die Nodes, also Programme zur Prüfung der Netzwerkregeln, kontrollieren, ob die neue Transaktion dem Plan entspricht. Ein anderer Empfänger oder ein abweichender festgelegter Betrag bestünde die Prüfung nicht. Jeremy Rubin beschreibt diesen Vorschlag in BIP119; die BIP-Nummer wurde 2020 zugeteilt. [1] [3]

Die Vorlage legt die Struktur des Transfers fest: Auf wie viele frühere Outputs verweisen die Inputs und welche neuen Outputs müssen entstehen? Bei den neuen Outputs bindet sie Beträge und Skripte, also deren spätere Ausgabebedingungen. Im Detail umfasst BIP119 außerdem die Transaktionsversion, nLockTime als Feld für zeitliche Beschränkungen der gesamten Transaktion, die Input-Felder nSequence, die Zeitsperren beeinflussen können, sowie den Index des gerade geprüften Inputs. Ist ein scriptSig, ein Input-Skript mit Ausgabedaten, nicht leer, wird auch ein Hash aller scriptSig-Felder einbezogen. Es geht somit um mehr als eine Empfängerliste: Auch die Änderung eines anderen erfassten Felds ergibt eine andere Vorlage. Verweise auf bestimmte frühere Coins und ihre Beträge sind eine gesonderte Frage, auf die wir unten zurückkommen. [1]

Ein Byte ist eine übliche Einheit für Datenmengen. Die vorgeschlagene Prüfung arbeitet mit einem 32 Byte langen, mittels SHA256 berechneten Hash. Der Knoten berechnet denselben Fingerabdruck aus der Transaktion, die den Output ausgibt, und lehnt Abweichungen ab. Eine digitale Signatur weist die Berechtigung zur Zahlung nach. Sie wird mit einem privaten Schlüssel erzeugt, also einem geheimen Zahlenwert, der dabei nicht offengelegt wird. Ein anderer Skriptteil kann eine Signatur verlangen; CTV ersetzt sie nicht generell. Andere Argumentlängen führen diese Prüfung nicht aus und sind für spätere Erweiterungen reserviert, können aber von der Weiterleitungsrichtlinie abgelehnt werden. Ein falsches Argument bedeutet also nicht automatisch eine sichere Sperre. [1] [4] [12]

Im folgenden Beispiel rechnen wir in sats, den kleinsten Bitcoin-Einheiten. Der Hash der Vorlage enthält weder unmittelbar die Outpoints, also Verweise auf die konkret ausgegebenen UTXOs, noch deren Eingangsbeträge. Die Zahl der Inputs steht trotzdem fest. Nehmen wir genau einen erlaubten Input und Outputs von zusammen 99 000 sats. Ein Input von 100 000 sats lässt 1 000 sats als Gebühr übrig. Ein kleinerer Eingangsbetrag als die Output-Summe kann die Transaktion nicht finanzieren. Ein größerer Input erhöht bei gleichen Outputs die Gebühr, statt automatisch Wechselgeld zu erzeugen. [6] [9]

Eine Vorlage kann den Übergang zu einem weiteren Output verlangen, dessen Skript eine Verzögerung und einen Rettungspfad enthält. So lässt sich ein Tresor mit Reaktionszeit bei unerwünschten Auszahlungen aufbauen. CTV ist nicht das gesamte Sicherheitssystem: Schlüssel, Bedingungen späterer Outputs, Überwachung und rechtzeitige Bestätigung der Rettung sind entscheidend. Manche Einschränkungen lassen sich stattdessen mit vorab signierten Transaktionen umsetzen, jedoch mit anderen Anforderungen an Zusammenarbeit und Schlüssellöschung. [8] [5]

Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. Bei der vorgeschlagenen Stauvermeidung wird zunächst ein Output bestätigt, der die Mittel an eine spätere Verteilung bindet. Die einzelnen Empfänger-Outputs entstehen erst durch Folgetransaktionen, etwa bei geringerer Netzauslastung. Empfänger brauchen Angaben zum Plan und eine Möglichkeit, ihren Anspruch umzusetzen. Das ist nicht dasselbe wie eine bereits auf ihrer Adresse bestätigte gewöhnliche Zahlung und schafft keinen unbegrenzten Platz im Block. [7] [11]

Eine Wallet ist eine Anwendung oder ein Gerät zum Empfangen und Senden von Bitcoin. Anna kann den Plan lange vor der Veröffentlichung einer Zahlung vorbereiten, kennt dann aber die künftigen Gebührensätze noch nicht. Feste Outputs erlauben ihr nicht, den an ihre Wallet zurückgehenden Betrag beliebig zu verringern und die Differenz einem Miner anzubieten. Die Konstruktion braucht deshalb eine Möglichkeit, Gebühren zu ergänzen. Ein passend vorbereitetes CPFP ist eine Option: Eine Folgetransaktion gibt einen Output der ursprünglichen Transaktion aus und bietet eine Gebühr, die einen Miner zur Aufnahme beider motivieren soll. Eine andere Option ist eine Vorlage, die von Anfang an einen weiteren Input vorsieht. Einer Vorlage für genau einen Input lässt sich dieser nicht einfach hinzufügen. Der Mempool ist die Sammlung unbestätigter Transaktionen eines einzelnen Nodes; die Aufnahme darin garantiert noch keinen Platz im Block. [2] [6] [10]

CTV allein prüft eine bestimmte Vorlage; es ist keine allgemeine Sprache zum Lesen und beliebigen Vergleichen sämtlicher Transaktionsdaten. Verzweigte Pläne künftiger Transaktionen sind möglich, dürfen aber nicht mit allgemeinen rekursiven Covenants verwechselt werden. Kombinationen mit weiteren vorgeschlagenen Anweisungen können mehr leisten. Bei einer Demonstration muss erkennbar sein, ob sie nur CTV oder ein ganzes Änderungspaket verwendet. [1] [2]

Bei der Prüfung am 17. Oktober 2026 hat BIP119 den Status Draft, ist also noch ein Entwurf. OP_NOP4, eine Anweisung ohne Wirkung bei der heutigen Blockprüfung, würde dadurch eine neue Prüffunktion erhalten. Eine solche Verschärfung gemeinsamer Regeln heißt Soft Fork. Das Dokument legt die Aktivierung jedoch nicht selbst fest. Die Veröffentlichung eines BIP macht den Opcode noch nicht zu einer durchgesetzten Anweisung; auch Code, die Unterstützung eines Entwicklers oder eine Demonstrations-Wallet belegen keine Durchsetzung im Bitcoin-Hauptnetz, dem Mainnet. Bei jeder Vorführung sind deshalb Netzwerk, Regeln und weitere benötigte Vorschläge zu beachten. [1]

Solange die Regel nicht durchgesetzt wird, bietet sie nicht schon deshalb Schutz, weil sie in einem Skript steht; Konsens und Mempool-Ablehnung sind verschieden. Auch mit CTV-Unterstützung kann eine einzige verpflichtende Vorlage ohne Ausweichpfad einen unterfinanzierten Output dauerhaft festsetzen. Eine neue kleine Einzahlung blockiert nicht automatisch andere korrekt finanzierte UTXOs. Ein sicherer Entwurf braucht Prüfungen von Beträgen, Gebühren, Sicherungen und allen Wiederherstellungspfaden. [1] [4] [6]