MSTR Cat

Blockchain/Niveau IV · Tiefer ins Protokoll/4.1 Script/Lektion 4

Timelocks: CLTV und CSV

Die Uhr, die nicht zurückgedreht werden kann, und der Median, der sie ehrlich hält

MaterialienEin Block-Explorer mit Ansichten zu Transaktionsdetails (z. B. mempool.space oder blockchain.com)Ein Rechner, der in der Lage ist, Unix-Zeitstempel zu verarbeitenDie Spezifikationsdokumente BIP65, BIP68 und BIP113

Neugier

  1. Warum gibt es ein Transaktionsfeld zur Verzögerung der Ausgaben, wenn eine neue Transaktion es immer umgehen kann?
  2. Wie kann ein einzelner Miner über die Zeit lügen, ohne den Konsens für alle anderen zu stören?
  3. Was ist der Unterschied zwischen dem Warten bis zu einem bestimmten Jahr und dem Warten von zwei Jahren ab jetzt?

Erkunden

  1. Jede Bitcoin-Transaktion enthält ein Feld nLockTime, einen vier Byte großen Wert, der verhindert, dass die Transaktion vor einem bestimmten Zeitpunkt gemined wird. Liegt der Wert unter 500.000.000, steht er für eine Blockhöhe; liegt er bei oder über diesem Schwellenwert, ist er ein Unix-Zeitstempel. Dieser Mechanismus gilt jedoch nur für genau diese Transaktion. Ein Nutzer kann jederzeit eine neue Transaktion mit denselben Inputs und einer Locktime von null erstellen und die Coins sofort ausgeben. nLockTime allein bietet keine Sicherheit für künftige Bedingungen, da es den Output selbst nicht bindet.
  2. OP_CHECKLOCKTIMEVERIFY (CLTV), von Peter Todd in BIP65 vorgeschlagen und im Dezember 2015 aktiviert, ändert das. CLTV ist ein Script-Opcode, der die nLockTime der Transaktion mit einem Wert auf dem Stack vergleicht. Ist die Locktime kleiner als der geforderte Wert, schlägt die Ausführung fehl. Da diese Prüfung im Locking-Script des Outputs stattfindet, muss jeder Versuch, genau diesen Unspent Transaction Output (UTXO) auszugeben, die Bedingung erfüllen. So entsteht ein absoluter Timelock: Die Coins sind nicht ausgebbar, bis ein netzwerkweit per Konsens bestimmter Zeitpunkt oder eine bestimmte Blockhöhe erreicht ist.
  3. Relative Timelocks funktionieren anders: Sie messen eine Dauer statt absoluter Zeitpunkte. BIP68 deutet das nSequence-Feld von Transaktions-Inputs, das zuvor nicht für diesen Zweck genutzt wurde, neu, um relative Verzögerungen zu kodieren. OP_CHECKSEQUENCEVERIFY (CSV), definiert in BIP112 und im Juli 2016 zusammen mit BIP68 aktiviert, vergleicht den Sequenzwert des Inputs mit einer geforderten Dauer. So können Scripts Bedingungen wie „Dieser Output darf erst 144 Blöcke nach seiner Bestätigung ausgegeben werden“ durchsetzen. Die Verzögerung bezieht sich auf die Bestätigung genau dieses UTXO und eignet sich daher ideal für zeitbasierte Wiederherstellungspfade oder das Auslaufen von Zahlungskanälen.
  4. Zeitbasierte Locks gaben Minern außerdem einen Anreiz, Zeitstempel zu manipulieren. Miner konnten Block-Zeitstempel bis zu zwei Stunden in die Zukunft setzen, um mehr zeitgesperrte Transaktionen früher als vorgesehen aufzunehmen. BIP113, im Juli 2016 zeitgleich mit den relativen Timelocks aktiviert, führte Median Time Past (MTP) ein. Timelock-Prüfungen vergleichen seitdem mit dem Median der Zeitstempel der letzten elf Blöcke statt mit dem Zeitstempel des Blocks selbst. So kann kein einzelner Miner die Uhr nennenswert beeinflussen; MTP liegt typischerweise etwa eine Stunde hinter der tatsächlichen Uhrzeit und bietet eine stabile, überprüfbare Referenz für alle Timelock-Berechnungen.
  5. Diese Mechanismen bilden die Grundlage für komplexe Anwendungen wie Zahlungskanäle und Erbschaftsprotokolle. In Lightning-Kanälen nutzen laufende Zahlungen absolute Timelocks (CLTV), sodass eine nicht eingelöste Zahlung nach Ablauf einer Frist zurückerstattet werden kann, während relative Verzögerungen (CSV) auf den eigenen Outputs einer Partei der Gegenseite Zeit geben, einen veralteten Kanalzustand zu bestrafen. Für Erbschaften können Scripts Multisig-Anforderungen mit Timelocks kombinieren: Etwa sind für den täglichen Zugriff zwei Schlüssel nötig, doch nach einem Jahr Inaktivität tritt über eine CSV-Bedingung ein dritter Schlüssel (der eines Erben) dem Quorum bei. Diese Parameter werden bei der Erstellung der Wallet festgelegt und lassen sich nicht mehr ändern, sobald die Mittel gesperrt sind.
  6. Timelocks sind dauerhafte Beschränkungen; sie lösen sich zu einem festgelegten Zeitpunkt, bieten aber keinen Mechanismus, um nach der Aktivierung erneut zu sperren oder Verzögerungen zu verlängern. Kodiert ein Script einen Sequenzwert von 100 Blöcken, werden die Coins genau dann ausgebbar, wenn diese relative Höhe ab der Bestätigung erreicht ist. Kodierungsfehler können Mittel länger als beabsichtigt unzugänglich machen oder sie umgekehrt zu früh freigeben. Zur praktischen Überprüfung öffnen Sie eine beliebige aktuelle Transaktion in einem Block-Explorer und sehen sich das Feld nLockTime an. Die meisten Wallets setzen es auf die aktuelle Blockhöhe, sodass die Transaktion nicht in einen Block mit niedrigerer Höhe aufgenommen werden kann; das nimmt Minern einen Anreiz, den jüngsten Block neu zu schreiben, um dessen Gebühren einzustreichen („Fee Sniping“).

Kernfakten

  • Werte für nLockTime unter 500.000.000 werden als Blockhöhen interpretiert; Werte von 500.000.000 und mehr sind Unix-Zeitstempel.
  • OP_CHECKLOCKTIMEVERIFY (BIP65) wurde im Dezember 2015 aktiviert und setzt absolute Timelocks auf Script-Ebene durch.
  • OP_CHECKSEQUENCEVERIFY (BIP112) und BIP68 wurden im Juli 2016 aktiviert und ermöglichen relative Timelocks über das nSequence-Feld.
  • Median Time Past (MTP), eingeführt durch BIP113, verwendet den Median der letzten elf Blöcke, um eine Manipulation der Zeit durch Miner zu verhindern.
  • CSV-Verzögerungen werden relativ zur Bestätigungshöhe oder -zeit des konkreten UTXO gemessen, der ausgegeben wird.
  • Wallets setzen nLockTime in der Regel auf die aktuelle Blockhöhe, um das Risiko von Fee Sniping zu verringern.

Übung neun, sechs, drei, eins

9SammelnListen Sie 9 Einsatzzwecke von Timelocks auf, die Sie beschrieben finden (Lightning, Vaults, Erbschaft, Treuhand, Atomic Swaps und andere), und notieren Sie jeweils, ob ein absoluter oder ein relativer Lock verwendet wird.
6GruppierenGruppieren Sie die 9 nach Zweck in 6 Kategorien: Rückerstattung, Strafzeitfenster, Erbschaft, Spar-Sperre, Vertragsfrist oder Sonstiges.
3VerdichtenReduzieren Sie die 6 auf 3 Gründe, warum ein Timelock im Script des Outputs und nicht nur in der ausgebenden Transaktion verankert sein muss.
1KristallisierenSchreiben Sie 1 Satz, der erklärt, wie MTP Timelocks von einem Modell, das auf Vertrauen in Miner beruht, in eine deterministische Konsensregel verwandelt.

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

In der interaktiven Akademie öffnen →

EN PT ES ZH JA KO RU FR MS