OP_CHECKLOCKTIMEVERIFY

Ein Timelock, das in den Coin geschrieben ist und nicht in die Transaktion, die ihn ausgibt. Peter Todd spezifizierte es in BIP65, wo es den Platz des alten No-Op-Opcodes NOP2 übernahm, und die Regel wird seit Block 388.381 im Dezember 2015 durchgesetzt. Wenn Sie schon einmal einen Nachlassplan oder einen Wiederherstellungspfad eingerichtet haben, ist dieser Opcode das, was die Tür zuhält.

Wie es funktioniert

OP_CHECKLOCKTIMEVERIFY liest eine Zahl vom Script-Stack, vergleicht sie mit dem Locktime-Feld der Transaktion, die den Coin ausgeben will, und bricht das gesamte Script ab, wenn die Ausgabe zu früh erfolgt.

BIP65 listet fünf Arten auf, wie die Prüfung fehlschlägt: Der Stack ist leer, das oberste Element ist negativ, das Element und das Locktime der Transaktion sind sich uneinig, ob sie Blöcke oder Sekunden zählen, das Element ist größer als das Locktime der Transaktion, oder die Sequenznummer des Inputs ist auf 0xffffffff gesetzt. Die letzte Bedingung schließt ein offensichtliches Loch. Ein Locktime wird vollständig ignoriert, wenn alle Inputs als final markiert sind, sodass ohne sie ein Ausgebender einfach die Frist abschalten und mit dem Geld davonziehen könnte.

Zwei Details überraschen Leser eines solchen Scripts beim ersten Mal. Der Opcode verbraucht die Zahl, die er prüft, nicht, daher folgen echte Scripts ihm mit OP_DROP, um den Stack aufzuräumen. Und er akzeptiert einen fünf Byte großen Operanden statt der üblichen vier, weil der größte Wert, mit dem er möglicherweise verglichen werden muss, 2**32-1 ist, der volle Bereich des Feldes, das er prüft.

Die Soft-Fork-Mechanik war die gewöhnliche. Die Neudefinition eines No-Op ist für Software unsichtbar, die nicht aktualisiert wurde: Ein alter Node führt den Opcode aus, tut nichts und akzeptiert den Block trotzdem. Die Aktivierung nutzte die Miner-Signalschwellen der damaligen Zeit: 750 Blöcke von 1.000, um mit der Durchsetzung zu beginnen, und 950 von 1.000, um sie verbindlich zu machen.

Wo Sie es sehen

OP_CHECKLOCKTIMEVERIFY taucht überall dort auf, wo Geld stillliegen muss, bis ein Datum erreicht ist.

Wallets für Nachlass und Wiederherstellung sind der klarste Fall. Ein Deskriptor kann festlegen, dass Ihr eigener Schlüssel jederzeit ausgibt, während ein Backup-Schlüssel erst nach einer angegebenen Höhe ausgibt, was einem Erben einen Weg gibt, der keine Zusammenarbeit von irgendjemandem und keinen Anwalt mit einem versiegelten Umschlag benötigt. Miniscript schreibt dies als after()-Fragment, und Wallets, die es unterstützen, zeigen Ihnen die Höhe in klarer Sprache statt im Roh-Script.

Lightning nutzt es für die absolute Frist einer gerouteten Zahlung. Eine BOLT11-Rechnung trägt ein finales Ablaufdelta, standardmäßig 18 Blöcke, und die gehashten Verträge entlang der Route sind über diesem Wert gestapelt, damit jeder Hop seine Mittel in einer festen Reihenfolge zurückholen kann, wenn die Zahlung nie abgeschlossen wird.

Treuhand und vertrauenslose Rückerstattungen folgen derselben Form: jetzt in ein Script einzahlen, und wenn die Gegenpartei nie unterschreibt, das Geld zurücknehmen, sobald die Frist abgelaufen ist. Der Opcode ist auch die ehrliche Antwort an jeden, der einen „zeitlich gesperrten Tresor“ als Produkt verkauft, denn mehr kann ein solches Produkt nicht sein.

OP_CHECKLOCKTIMEVERIFY vs. OP_CHECKSEQUENCEVERIFY

OP_CHECKLOCKTIMEVERIFY benennt einen Zeitpunkt; OP_CHECKSEQUENCEVERIFY benennt eine Dauer. Das eine sagt „nicht vor Dezember“, das andere sagt „nicht bevor 144 Blöcke nach Bestätigung genau dieses Coins vergangen sind“, und nur das zweite startet seine Uhr, wenn der Coin eintrifft. BIP112 definierte die relative Form, und sie wurde bei Block 419.328 im Juli 2016 aktiviert, etwa sieben Monate nach ihrem absoluten Gegenstück. Vertragsprotokolle verwenden beide, oft in einem Script: eine absolute Frist, um die gesamte Vereinbarung zu begrenzen, und eine relative Verzögerung, um einer Partei ein Fenster zur Reaktion zu garantieren.