CLTV steht für die Anweisung OP_CHECKLOCKTIMEVERIFY in Bitcoin Script. Sie verknüpft das Ausgeben mit einer festen Blockhöhen- oder Zeitgrenze. Danach müssen weiterhin die übrigen Bedingungen erfüllt, eine Transaktion erstellt und diese in einen Block aufgenommen werden. Nichts wird von selbst versendet.
Anna plant eine Verwahrung, bei der sie und Peter gewöhnliche Zahlungen gemeinsam freigeben. Falls jemand längere Zeit nicht erreichbar ist, möchte sie zusätzlich einen Wiederherstellungsweg, der erst nach einer gewählten Grenze nutzbar wird. CLTV schreibt diese Zeitbedingung in das Skript, also die Regeln zum Ausgeben zuvor empfangener Coins. Das Feld nLockTime allein würde nur eine bestimmte Transaktion verzögern. CLTV verhindert, diesen Weg mit einer neuen Transaktion und niedrigerer Grenze zu umgehen. Andere Zweige können dennoch andere Regeln haben. [1] [5]
CLTV erkennt keinen Eigentümer und verschickt kein Geld. Verlangt der Wiederherstellungsweg Annas Signatur, muss sie diese auch nach erfüllter Zeitbedingung liefern. Der private Schlüssel ist ein geheimer Zahlenwert, mit dem eine solche Signatur erzeugt wird. Ein verlorener privater Schlüssel kommt durch Zeitablauf nicht zurück. Die Coins wechseln auch nicht automatisch zu einer anderen Adresse: Jemand muss eine gültige Transaktion erstellen, signieren und verbreiten. Erlaubt ein anderer Zweig ein früheres Ausgeben, wird dieser durch die Zeitsperre im Wiederherstellungszweig nicht automatisch eingeschränkt. [1]
Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. CLTV eignet sich für eine vorher festgelegte Grenze, nicht für „warte eine bestimmte Anzahl von Blöcken ab Empfang dieser Coins“. Dafür gibt es CSV zusammen mit BIP 68, den Regeln für relative Sperren. Dabei zählt die Bestätigung des jeweiligen Outputs, also eines zuvor empfangenen Betrags mit Ausgabebedingungen. Keiner der Ansätze garantiert ein genaues Kalenderdatum. Die Blockabstände schwanken, und eine Reorganisation kann die bestätigte Historie ändern. Bei einer Reorganisation übernimmt das Netzwerk einen anderen gültigen Zweig der Kette und ersetzt damit einen Teil der bisherigen Blockhistorie. [1] [7] [8] [9]
CLTV unterscheidet zwei Arten von Werten. Unter 500000000 steht der Wert für die Blockhöhe, die Position in der Kette. Ab dieser Grenze steht er für einen Zeitstempel, also numerisch dargestellte Zeit. Die Skriptbedingung und nLockTime der ausgebenden Transaktion müssen denselben Typ verwenden. Ein bloßer Größenvergleich reicht nicht: Die Position eines Blocks und ein Zeitpunkt haben unterschiedliche Bedeutungen. [1] [3] [5]
Ein Full Node prüft die Regeln eigenständig. Er vergleicht die nichtnegative Skriptgrenze mit dem absoluten nLockTime der Transaktion. Die Grenze darf nLockTime nicht überschreiten; Gleichheit ist bei dieser Prüfung erlaubt. Zusätzlich müssen die Regeln für die Aufnahme in einen konkreten Block erfüllt sein. CLTV liest weder die Uhr deines Rechners noch hält es ein Programm bis morgen an. Scheitert die Prüfung, ist dieser Versuch, den Ausgabepfad zu nutzen, ungültig. [1] [3] [4]
Ein Transaktionseingang bezeichnet zuvor empfangene Coins, die ausgegeben werden. Zu seinen Feldern gehört nSequence. Beim von CLTV geprüften Eingang darf es nicht 0xffffffff sein, der besondere Wert für eine finale Sequenz. Hätten alle Eingänge diesen Wert, ließe sich nLockTime abschalten. CLTV verhindert das, indem es für diesen Eingang eine nichtfinale Sequenz verlangt. Damit wird aber nicht automatisch eine bestimmte relative Wartezeit festgelegt; dafür gelten andere Regeln. [1] [3] [4]
Nehmen wir eine Beispieltransaktion mit nLockTime gleich 900000 und einem nichtfinalen Eingang. Für diese Zeitbedingung kommt frühestens Block 900001 infrage. Zur Aufnahme muss nLockTime strikt kleiner als die Höhe des vorgesehenen Blocks sein. Block 900000 genügt daher nicht, obwohl CLTV selbst Gleichheit zugelassen hat. „Finalität“ bedeutet hier Aufnahmefähigkeit, nicht Unumkehrbarkeit der Zahlung. Gebühren, weitere Bedingungen und die Auswahl des Miners können die Bestätigung zusätzlich verzögern. [4]
Bei Zeitstempeln verwendet BIP 113 die Median Time Past des vorherigen Blocks: den mittleren Wert der sortierten Zeitstempel der letzten bis zu 11 Blöcke. Maßgeblich sind weder deine Uhr noch der Zeitstempel des gerade geschürften Blocks. Ein zeitbasiertes nLockTime muss strikt darunter liegen. Deshalb lässt sich keine Verfügbarkeit genau zur örtlichen Mittagszeit versprechen. Die Bedingung ist im Netzwerk überprüfbar, aber kein minutengenauer Zahlungsplan. [2] [4]
Bei der Auswertung nutzt das Skript einen Stack, einen Arbeitsstapel für Daten. CLTV prüft sein Zeitargument, entfernt es aber nicht. In einem einfachen Schema folgt deshalb auf OP_CHECKLOCKTIMEVERIFY ein OP_DROP, das das Argument entfernt; anschließend wird ein öffentlicher Schlüssel auf den Stack gelegt und die Signatur mit OP_CHECKSIG geprüft. Der öffentliche Schlüssel dient zur Prüfung von Signaturen und muss nicht geheim bleiben. Das erklärt die Rollen der Anweisungen, ist jedoch keine fertige Anleitung zum Sperren von Geld. Skriptversion, Eingangsdaten und sämtliche anderen Ausgabepfade müssen ebenfalls stimmen. [1] [3]
BIP 65 führte CLTV als Soft Fork ein: eine Verschärfung der Regeln, die das frühere OP_NOP2 ersetzte. Es handelt sich also nicht bloß um eine künftige Funktion. Trotzdem muss der gesamte Entwurf geprüft werden: Grenztyp, nLockTime, nSequence, Signaturen und alternative Zweige. Technische Einzelheiten lassen sich in Bitcoin Core v29.0 und den verlinkten Spezifikationen nachlesen. Für Nutzer zählt vor allem, wer vor und nach der Grenze ausgeben darf und ob sie die Wiederherstellungsmöglichkeiten verstehen. [1] [3] [6] [10]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit CSV, Opcode, Timelock, Bitcoin Script, Bitcoin, Full Node. Auf diesen Eintrag verweisen außerdem Timelock, HTLC, Opcode, CSV.