Stell dir einen Timelock als Regel vor: „Dieser Weg steht erst später offen.“ Er kann sich auf eine bestimmte Blockhöhe, also die Position eines Blocks in der Kette, eine aus der Blockchain abgeleitete Zeit oder eine Wartezeit seit Bestätigung eines Outputs beziehen. Ein Output ist ein Betrag mit Regeln darüber, wer ihn unter welchen Bedingungen ausgeben darf. Warten ersetzt weder eine Unterschrift noch andere Anforderungen und versendet auch kein Geld. Entscheidend ist außerdem, ob die Zeit nur eine vorbereitete Transaktion beschränkt oder durch die Ausgaberegeln des Geldes selbst erzwungen wird.
Anna und Pavel können gemeinsame Mittel so einrichten, dass sie diese jederzeit gemeinsam ausgeben dürfen, Anna allein aber erst nach einer Wartezeit. Reagiert Pavel nicht mehr, bietet der verzögerte Zweig einen vorher vereinbarten Rückweg. Ein Zweig ist hier eine erlaubte Ausgabemöglichkeit; jede kann andere Bedingungen haben. Die Sperre muss deshalb nicht alle Möglichkeiten zugleich blockieren. Die Regeln müssen beim Erstellen des Outputs bereits zu ihm gehören. Später in einer gewöhnlichen Wallet „in einer Woche entsperren“ zu notieren reicht nicht. Auch nach dem Warten braucht Anna den passenden Schlüssel und die Angaben zum Erstellen einer gültigen Transaktion. Ein Timelock regelt Zugriff, stellt aber keine verlorenen Schlüssel wieder her. [3]
Eine absolute Sperre bezieht sich auf eine feste Grenze, die im nLockTime-Feld der Transaktion steht. Hat eine Transaktion ein wirksames nLockTime von Blockhöhe 1 000 000, erfüllt frühestens Block 1 000 001 diese Bedingung: Gleichheit reicht noch nicht. Eine relative Sperre misst dagegen eine Wartezeit ab Bestätigung des verwendeten Outputs. Entsteht Annas Output in Block 1 000 000 und verlangt der betreffende Zweig eine Verzögerung von 6 Blöcken, kann seine Ausgabe diese Bedingung frühestens in Block 1 000 006 erfüllen. Das sind Beispielzahlen, nicht die aktuelle Höhe des Netzes. Bedingungen für Signaturen, weitere Inputs und mögliche zusätzliche Sperren gelten weiterhin. Sechs Blöcke sind auch nicht genau eine Stunde: Blöcke kommen in unregelmäßigen Abständen. Die relative Wartezeit beginnt weder beim Erstellen der Wallet noch dann, wenn Anna das Geld nutzen möchte. [1] [2] [5]
Angenommen, Annas Wartezeit ist gerade vorbei. Das Netzwerk handelt nicht für sie. Jemand muss weiterhin eine Transaktion erstellen oder eine vorbereitete verwenden, Signaturen liefern, eine Gebühr zahlen und sie ins Netz senden. Erst dann kann ein Miner sie in einen Block aufnehmen. Ein erfüllter Timelock ist eine erfüllte Bedingung, keine Platzreservierung und keine automatische Überweisung. Normalerweise bestimmt er den Beginn einer Ausgabemöglichkeit, nicht deren selbsttätiges Erlöschen. Bei einer Reorganisation wird ein Teil der Kette durch einen anderen gültigen Zweig ersetzt. Das kann die Bestätigung eines Outputs und die Berechnung seiner relativen Wartezeit ändern. Bei einer eigenen Konstruktion sind alle Zweige, die Wallet-Unterstützung und Sicherungen von Schlüsseln wie Ausgaberegeln vorher zu prüfen; Zeit repariert keine falsch festgelegte Bedingung. [2] [5]
Zeitbasierte Bedingungen verwenden Median Time Past, kurz MTP. Für den geprüften Block ist das der Median der Zeitstempel der letzten 11 Blöcke bis einschließlich des vorherigen Blocks. Sortiere die Zeiten und nimm die mittlere, also die sechste: Das ist der Median, nicht das arithmetische Mittel. BIP113 beschreibt diese Regel, Bitcoin Core verwendet dafür GetMedianTimePast. Maßgeblich ist also weder die aktuelle Zeit auf Annas Handy noch der Zeitstempel des vorgeschlagenen Blocks. Mitternacht im Kalender muss nicht der Moment sein, in dem die Sperre erfüllt ist. Höhenbasierte Sperren warten dagegen auf Blöcke; sie zählen keine Sekunden herunter. [4]
Jetzt lassen sich vier Namen aus der Dokumentation unterscheiden. nLockTime ist ein Feld der gesamten Transaktion für eine absolute Grenze. nSequence an einem Input enthält eine relative Verzögerung nach BIP68. nLockTime allein sperrt aber keine UTXO, also einen noch nicht ausgegebenen Output, gegen eine andere Transaktion mit anderen Einstellungen. Wer ausgabeberechtigt ist, kann eine solche Transaktion erstellen, sofern die Regeln des Outputs das nicht verhindern. Bitcoin Script ist die Sprache, in der diese Ausgaberegeln formuliert werden. OP_CHECKLOCKTIMEVERIFY, kurz CLTV nach BIP65, verlangt im verwendeten Zweig die passende absolute Einstellung. OP_CHECKSEQUENCEVERIFY, also CSV nach BIP112, prüft die relative Einstellung; die tatsächliche Wartezeit erzwingt BIP68. Weder CLTV noch CSV senden Geld oder ergänzen eine fehlende Signatur. Ein anderer erlaubter Zweig kann unter anderen Bedingungen nutzbar sein. [1] [2] [3]
Die folgenden Abschnitte sind eine technische Referenz. Ein Feld ist eine gespeicherte Angabe in der Transaktion; ein Input verweist auf einen Output, der ausgegeben werden soll. Jeder Input hat ein nSequence-Feld. Ein besonderer Wert kann die Wirkung von nLockTime abschalten, weshalb ein eingetragenes Datum allein nicht genügt. nLockTime ist ein nicht negatives 32-Bit-Feld; null deaktiviert die absolute Zeitbedingung. Wenn alle Inputs auf SEQUENCE_FINAL mit dem Wert 0xffffffff gesetzt sind, wird ein nicht erfülltes nLockTime ignoriert. Für eine wirksame absolute Sperre muss mindestens ein Input ein anderes nSequence haben. Geprüft wird diese konkrete Transaktion, keine dauerhafte Sperre ihrer Inputs. [5] [7]
Dasselbe Feld kann zwei Dinge ausdrücken; eine Zahlengrenze trennt sie. Ein Unix-Timestamp stellt Zeit als Sekunden seit Anfang 1970 in UTC dar. Der Kandidatenblock ist der Block, in den die geprüfte Transaktion aufgenommen werden soll. LOCKTIME_THRESHOLD hat den Wert 500000000. Ein niedrigeres nLockTime bezeichnet eine Blockhöhe, ein gleicher oder höherer Wert einen Unix-Timestamp. Bei aktiver absoluter Prüfung muss nLockTime strikt kleiner sein als die Höhe des Kandidatenblocks oder der maßgebliche MTP. Gleichheit reicht nicht aus; es geht weder um einen Geldbetrag noch um eine durchschnittliche Höhe oder das Aktivierungsdatum eines Protokolls. [5] [8]
Ein Operand ist ein Wert, der einer Anweisung übergeben wird; ein Opcode ist die Script-Anweisung selbst. CLTV vergleicht die im Zweig gespeicherte Anforderung mit der Transaktionseinstellung. Ob die Blockchain weit genug fortgeschritten ist, prüft eine andere Kontrolle. Es ist also mehr als ein Vergleich des heutigen Datums mit einer Zahl. OP_CHECKLOCKTIMEVERIFY verlangt einen nicht negativen Operanden, denselben Typ Höhe/Zeit wie nLockTime und einen Operanden, der höchstens gleich nLockTime ist. Der betreffende ausgebende Input darf nicht nSequence 0xffffffff haben. Der Opcode liest weder die Uhr noch die Blockchain-Höhe direkt; die Transaktionseinstellungen werden getrennt bei der Prüfung ihrer zeitlichen Gültigkeit kontrolliert. Die übrigen Script-Bedingungen bleiben erforderlich. [1] [6]
Die Zahl nSequence enthält sowohl die Wartezeit als auch Schalter für ihre Bedeutung. Ein Bit ist eine Null oder Eins in dieser Darstellung; das Setzen kann eine Option einschalten. Die folgenden Bitpositionen gehören zum technischen Format und sind keine Bestätigungszahlen. Bei Transaktionen ab Version 2 aktiviert BIP68 die relative Bedingung für Inputs, deren Bit 31 nicht gesetzt ist. Die unteren 16 Bits bestimmen die Verzögerung; Bit 22 wählt Einheiten von 512 Sekunden, andernfalls werden Blöcke verwendet. Die blockbasierte Verzögerung zählt ab der Bestätigungshöhe des ausgegebenen Outputs. Die zeitbasierte Verzögerung reicht vom MTP des Blocks vor dessen Bestätigung bis zum MTP vor dem Kandidatenblock. Es geht nicht um die Zeit seit der Erstellung der Transaktion in der Wallet. [2] [5]
CSV prüft die relative Wartezeit auf ähnliche Weise. Eine Maske wählt die relevanten nSequence-Bits aus, ein Disable-Flag ist ein Ausschalter. Lightning Network ist ein Netz aus Zahlungskanälen: Die Beteiligten aktualisieren darin die vereinbarte Aufteilung gemeinsam gebundener Mittel. Die Verzögerung gibt der Gegenseite Zeit zu reagieren, falls jemand einen alten, bereits widerrufenen Zustand veröffentlicht. Eine Commitment-Transaktion hält die Aufteilung fest; mit einem Revokationsschlüssel kann die Gegenseite den betreffenden Output einer widerrufenen Version über einen Strafzweig ausgeben. OP_CHECKSEQUENCEVERIFY verlangt bei einem aktiven nicht negativen Operanden mindestens Version 2, ein nicht gesetztes Disable-Flag des Inputs, einen übereinstimmenden Verzögerungstyp und ein ausreichend großes maskiertes nSequence. Das tatsächliche Alter wird gesondert durch BIP68 erzwungen. CSV ermöglicht einen verzögerten Wiederherstellungszweig. Beim Lightning-Output to_local beschränkt to_self_delay den Eigentümer der Commitment-Transaktion; die Gegenpartei mit dem richtigen Revokationsschlüssel kann den Strafzweig ohne diese Verzögerung verwenden. [3] [9]
Zwei fast gleiche Zahlen können unterschiedlich wirken. Die folgenden Werte mit 0x sind hexadezimal geschrieben. NOP bezeichnet eine Anweisung, die hier keine Zeitbeschränkung hinzufügt. Wichtig ist auch, ob der Schalter im Transaktionsinput oder im an CSV übergebenen Wert steht. Bit 31 ist SEQUENCE_LOCKTIME_DISABLE_FLAG und deaktiviert die relative Interpretation nach BIP68 nur für den jeweiligen Input. Der Wert 0xfffffffe enthält dieses Bit, ist aber nicht SEQUENCE_FINAL: Er erlaubt wirksames nLockTime und CLTV. Der Wert 0xffffffff ist final. Ein nicht negativer CSV-Operand mit gesetztem Disable-Flag verhält sich wie NOP; ein gesetztes Flag im Input erfüllt hingegen keine aktive CSV-Anforderung. Diese beiden Fälle dürfen nicht verwechselt werden. [3] [7]
Ein RPC ist ein Befehl zur Arbeit mit dem eigenen Knoten, also dem Programm, das Bitcoin-Blöcke und -Transaktionen prüft. Dekodieren macht gespeicherte Angaben nur lesbar; der Prüfbefehl untersucht dann, ob eine bestimmte signierte Transaktion bestehen würde. Ein Mempool ist die lokale Liste wartender Transaktionen des Knotens. Die RPC decoderawtransaction in Core 31 zeigt version, locktime und sequence der einzelnen Inputs. Prüfe für CLTV/CSV das tatsächlich verwendete Script und den ausgegebenen Output; bloßes Dekodieren beweist keine Gültigkeit. Die RPC testmempoolaccept prüft einen signierten Kandidaten anhand der aktuellen Blockchain, der Gültigkeitsregeln von Bitcoin und der lokalen Annahmeregeln des Knotens, ohne Aufnahme in den Mempool und ohne Übertragung. Prüfe allowed und den Ablehnungsgrund; Erfolg verspricht keine künftige Bestätigung. [10] [11] [12]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit CLTV, CSV, Lightning Network, Payment Channel, Transaktion, Bitcoin Script. Auf diesen Eintrag verweisen außerdem Bestätigung, Bitcoin Script, HTLC, CLTV.