CSV

Anna und Peter können ihre gemeinsam verwahrten Coins im Einvernehmen ausgeben. Zusätzlich möchten sie einen Wiederherstellungsweg, den Anna allein nutzen kann, jedoch erst nach einer Wartezeit ab Bestätigung des betreffenden Outputs. CSV hilft, diese Bedingung durchzusetzen. Anders als CLTV mit seiner festen Höhe oder Zeit ist die Grenze kein vorher bestimmter Punkt in der gesamten Historie. Sie hängt von konkreten Coins ab. Das Anlegen einer Wallet, eine vorbereitete Signatur oder langes Warten einer unbestätigten Transaktion ersetzen diesen Ausgangspunkt nicht. Eine Wallet ist eine Anwendung oder ein Gerät zum Empfangen und Senden von Bitcoin. [1] [2] [8]

Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. Die Blockhöhe bezeichnet die Position eines Blocks in der Kette. Angenommen, ein Output wird auf Höhe 900000 bestätigt und die vorgeschriebene Verzögerung beträgt 10 Blöcke. Nach dieser Sperre ist eine Ausgabe frühestens in Block 900010 möglich. Ein Abstand von nur 9 Blöcken reicht nicht. Eine genaue Minutenzahl ist damit nicht versprochen: Blöcke kommen nicht in regelmäßigen Abständen. Auch ausreichendes Alter ist noch keine Zahlungsbestätigung. Die Transaktion muss ansonsten gültig sein und tatsächlich von einem Miner in einen Block aufgenommen werden. [2] [4] [9]

Die Wartezeit lässt sich auch in Schritten von 512 Sekunden codieren. Code 2 steht dann für 1024 Sekunden. Verglichen werden aber nicht zwei Computeruhren. Ausgangspunkt ist die Median Time Past des Blocks vor dem Bestätigungsblock des Outputs; der andere Endpunkt ist die Median Time Past des Blocks vor dem vorgesehenen neuen Block. Das ist der mittlere Zeitstempel der letzten bis zu 11 Blöcke nach dem Sortieren. Die Differenz dieser Mediane muss die geforderte Wartezeit erreichen. Es ist kein genauer Wecker nach Ortszeit. [2] [4] [7]

Eine Wallet kann für eine Zahlung mehrere früher empfangene Beträge zusammenführen. Jeder Transaktionseingang verweist auf einen zuvor empfangenen Output, dessen Alter ab seiner Bestätigung in der Kette gemessen wird. Das Feld nSequence gehört zum Eingang selbst. Dieses trägt die Information für die relative Wartezeit. Es genügt nicht, wenn nur ein Teil des Geldes alt genug ist: Alle anwendbaren Sperren der Transaktion müssen erfüllt sein. Eine Reorganisation der Kette kann zudem den Bestätigungszeitpunkt verschieben. Frühere Ausgabefähigkeit ist deshalb keine unumkehrbare Eigenschaft eines Coins. Bei einer Reorganisation übernimmt das Netzwerk einen anderen gültigen Zweig der Kette und ersetzt damit einen Teil der bisherigen Blockhistorie. [2] [4] [9]

Ein Full Node prüft die Regeln selbstständig in zusammenhängenden Schritten. CSV nach BIP 112 vergleicht das Skriptargument mit nSequence des Eingangs, der den Output ausgibt. Es berechnet das Alter nicht selbst; das übernimmt BIP 68 bei der Transaktionsprüfung. Bei einem gewöhnlichen Argument ohne Abschaltflag muss die Transaktionsversion mindestens 2 sein und Bit 31 von nSequence darf nicht gesetzt sein. Ein Bit ist ein kleiner Schalter innerhalb eines Zahlenfelds. Ein negatives Argument, eine ältere Version oder ein unvereinbares nSequence lassen die Prüfung scheitern. [1] [2] [3]

Bit 22 bestimmt, wie die Wartezeit zu lesen ist. Ist es nicht gesetzt, zählt man Blöcke; ist es gesetzt, sind es Schritte von 512 Sekunden. Skriptargument und nSequence müssen denselben Typ verwenden. Das ähnelt dem Vergleich von Messwerten: Eine größere Zahl genügt nicht, wenn eine Seite Kilometer und die andere Stunden zählt. Hier geht es entsprechend um den Unterschied zwischen Blockanzahl und Zeitspanne. [1] [2] [3]

Die unteren 16 Bits enthalten die Dauer. Die Maske 0x0000ffff wählt diesen Teil des Zahlenfelds aus. CSV vergleicht ihn zusammen mit dem Typ der Verzögerung; ein beliebig großes nSequence bedeutet nicht automatisch längeres Warten. Nach Auswahl der relevanten Bits darf die Skriptanforderung den Wert des Eingangs nicht überschreiten. Für Walletentwickler ist das eine wichtige technische Grenze. Nutzer sollten sie jedoch nicht von Hand einstellen, ohne den gesamten Ablauf zu verstehen. [1] [2] [3]

Eine Verzögerung von null fügt keine Wartezeit hinzu, aber die übrigen Prüfungen von gewöhnlichem CSV gelten weiterhin. Anders liegt der Fall, wenn im nichtnegativen Skriptargument selbst Bit 31 gesetzt ist. Dann verhält sich CSV wie ein NOP, eine Anweisung ohne Wirkung auf die relative Sperre. Ein solches Argument erzwingt kein Warten. Das ist vom gleichen Flag in nSequence des Eingangs zu unterscheiden: Bei einem gewöhnlichen Argument darf dieses Eingangsflag nicht gesetzt sein. [1] [3]

Braucht Annas Wiederherstellungsweg ihre Signatur, muss sie diese auch nach Ablauf liefern. Der private Schlüssel ist ein geheimer Zahlenwert, mit dem eine solche Signatur erzeugt wird. Ein verlorener privater Schlüssel kommt nicht zurück, und ein anderer Zweig kann weiterhin früheres Ausgeben erlauben. Bei der Skriptausführung lässt CSV sein Argument auf dem Stack, dem Arbeitsstapel für Daten, liegen; häufig folgt OP_DROP, um es zu entfernen. Das Entfernen dieser Daten berechtigt aber niemanden zum Geld. Dafür sind Signaturen und die übrigen Bedingungen des gewählten Weges zuständig. [1] [3] [5]

BIP 112 führte CSV als Ersatz für OP_NOP3 gemeinsam mit BIP 68 und BIP 113 ein. Es ist eine aktive Fähigkeit, kein bloßer Plan. Verwendet wird sie etwa in Zahlungskanälen des Lightning Network, wo eine Verzögerung der anderen Partei Zeit zum Reagieren geben kann; die Reaktion selbst löst sie nicht aus. Nach dem Warten muss die Transaktion weiterhin verbreitet und bestätigt werden. Gebühren, verfügbare Daten und der Zustand der Kette bleiben wichtig. Bitcoin Core v29.0 und die genannten Spezifikationen dokumentieren die Prüfungen. [1] [2] [6]