Glossar / Protokoll und Upgrades
OP_CHECKSEQUENCEVERIFY
Auch bekannt als CSV, BIP112.
- Was ist OP_CHECKSEQUENCEVERIFY?
- OP_CHECKSEQUENCEVERIFY sperrt einen Coin für einen Zeitraum, der ab seiner eigenen Bestätigung gemessen wird, und lässt jede Ausgabe scheitern, deren Eingabe nicht lange genug gewartet hat.
Spezifiziert im BIP-112.
Der Opcode liest eine Zahl vom Stack und vergleicht sie mit dem Sequence-Feld der Eingabe, die ausgegeben wird, sodass die Uhr läuft, wenn der Coin in einen Block gelangt, und nicht zu einem Kalenderdatum. BIP-112 hat ihn definiert, und das Netzwerk begann ihn am 4. Juli 2016 ab Block 419.328 durchzusetzen. Jeder Lightning-Kanal, den Sie eröffnen, hängt davon ab.
So funktioniert er
Der Opcode 178 hieß früher OP_NOP3 und tat nichts, und so gelangte die Regel als Soft Fork in das Netzwerk und nicht als Spaltung.
Die Prüfung läuft gegen drei Eingaben: die Zahl auf dem Stack, das Sequence-Feld der Eingabe, die ausgegeben wird, und die Version der Transaktion. Version 2 oder höher ist erforderlich, weil die Regeln für relative Zeitsperren aus BIP-68 erst ab dieser Version gelten. Ist das höchste Bit eines der beiden Werte gesetzt, ist die Zeitsperre abgeschaltet und der Opcode gibt auf. Andernfalls müssen beide bei ihrer Einheit übereinstimmen und der Stack-Wert darf das Sequence-Feld nicht überschreiten.
Die Einheiten gibt es in zwei Varianten, und sie lassen sich in einem Vergleich nicht mischen. Ist ein bestimmtes Flag nicht gesetzt, zählt die Zahl Blöcke; ist es gesetzt, zählt die Zahl Intervalle von 512 Sekunden. In beiden Fällen stehen sechzehn Bit zur Verfügung, sodass die Obergrenze bei 65.535 Blöcken liegt, etwa 455 Tagen, oder bei derselben Anzahl von 512-Sekunden-Intervallen, was etwas unter 389 Tagen liegt. Alles Längere braucht stattdessen eine absolute Zeitsperre.
Ein Scheitern ist keine Verzögerung, sondern eine Ablehnung. Vor Ablauf der Wartezeit ist die Ausgabe keine anhängige Transaktion in einer Warteschlange, sondern eine ungültige, die kein Node weiterleitet und kein Miner aufnimmt. Nichts muss erneut versucht werden, bis der Coin alt genug ist; zu diesem Zeitpunkt wird dieselbe Transaktion gültig.
Wo er auftritt
Lightning ist nach Volumen der größte Nutzer, und der Opcode steckt im Script, das Ihre eigene Seite jedes Kanals schützt.
Wenn ein Kanal einseitig geschlossen wird, geht der Saldo der schließenden Partei in einen Output, der erst nach Ablauf einer Verzögerung ausgegeben werden kann, das to_self_delay von BOLT 3, üblicherweise einige hundert Blöcke. Die Verzögerung besteht, damit der andere Peer ein Zeitfenster hat, eine Widerrufung zu veröffentlichen und die Mittel zu nehmen, falls die Schließung einen veralteten Zustand verwendet hat. Ihr Geld ist in beiden Fällen sicher, aber deshalb lässt Sie eine erzwungene Schließung einen Tag oder länger warten, während eine kooperative Schließung sofort auszahlt.
Dieselbe Konstruktion findet sich bei Submarine Swaps und Atomic Swaps, wo ein Erstattungspfad erst geöffnet werden darf, nachdem die Gegenpartei eine faire Gelegenheit hatte, Anspruch zu erheben, sowie bei Wiederherstellungs-Wallets, bei denen ein Sicherungsschlüssel nach langer Stille nutzbar wird.
Eine Falle verdient eine Warnung. Eine relative Zeitsperre wird ab der Bestätigung des konkreten Coins gemessen, der ausgegeben wird, sodass sie bei jeder Bewegung dieses Coins neu beginnt. Das Zusammenlegen von Dust, das Ausgeben des Wechselgelds oder das Umsortieren Ihrer Outputs durch eine Wallet setzt den Countdown in jedem eingerichteten Wiederherstellungszweig zurück, und ein Erbe, der erwartet hat, dass der Sicherungsschlüssel im nächsten Monat funktioniert, kann die Uhr auf null zurückgesetzt vorfinden.
OP_CHECKSEQUENCEVERIFY vs. OP_CHECKLOCKTIMEVERIFY
CSV fragt, wie lange der Coin bereits existiert; CLTV fragt, wie spät es ist. Die beiden Opcodes stehen in der Nummerierung nebeneinander, 178 und 177, und sie werden für sehr unterschiedliche Aufgaben gewählt.
Verwenden Sie die absolute Form, wenn die Frist ein echtes Datum ist: ein Trust, der 2030 freigeschaltet wird, eine Erstattung, die zu einer bekannten Höhe abläuft. Verwenden Sie die relative Form, wenn die Wartezeit beginnen soll, wann immer der Vertrag beginnt, was jedes Script braucht, das einmal geschrieben und vielfach wiederverwendet wird. Lightning konnte für Kanalverzögerungen keine absoluten Zeitsperren verwenden, weil ein heute eröffneter Kanal und ein im nächsten Jahr eröffneter Kanal unterschiedliche Scripts bräuchten. Die beiden kamen zudem einige Monate versetzt, CLTV am 14. Dezember 2015 ab Block 388.381 und CSV im darauffolgenden Juli, und der zweite entstand vor allem, weil der erste nicht ausreichte, um Zahlungskanäle zu bauen.