OP_CHECKLOCKTIMEVERIFY vergleicht ein nichtnegatives Stack-Argument mit dem absoluten nLockTime der ausgebenden Transaktion und prüft nSequence dieses Eingangs. Die Finalitätsregeln prüfen danach die tatsächliche zeitliche Zulässigkeit.
nLockTime allein verzögert eine bestimmte Transaktion. CLTV in der Output-Bedingung verhindert die Umgehung desselben Pfads durch niedrigeres nLockTime; andere Pfade sind getrennt zu prüfen. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Developer Reference — Transactions]
Werte unter 500000000 bedeuten Blockhöhe, ab dieser Grenze einen Zeitstempel. CLTV-Argument und nLockTime müssen denselben Typ haben; Zahlenvergleich allein reicht nicht. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v29.0 — Script interpreter]
Das Argument muss nichtnegativ und höchstens nLockTime sein. CLTV liest keine Computeruhr und pausiert das Skript nicht; eine unerfüllte Prüfung lässt die Validierung scheitern. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v29.0 — Script interpreter]
nSequence des geprüften Eingangs darf nicht 0xffffffff sein. Damit wird das Abschalten von nLockTime durch finale Sequences verhindert; CLTV verlangt keine bestimmte positive relative Wartezeit. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v29.0 — Script interpreter]
Bei nLockTime = 900000 und nichtfinalem Eingang ist 900001 die früheste Kandidatenhöhe, da nLockTime unter der Blockhöhe liegen muss. Ein bei Argumentgleichheit erfolgreiches CLTV verschiebt diese Grenze nicht. [Bitcoin Core v29.0 — Transaction finality]
Zeitbasiertes nLockTime wird nach BIP 113 mit Median Time Past des vorherigen Blocks verglichen, dem Median der letzten bis zu 11 Blockzeiten. Es muss strikt kleiner sein; das ist keine genaue lokale Zustellzeit. [BIP 113 — Median time-past lock-time calculations] [Bitcoin Core v29.0 — Transaction finality]
CLTV verbraucht sein Argument nicht. In <Höhe> OP_CHECKLOCKTIMEVERIFY OP_DROP <Schlüssel> OP_CHECKSIG entfernt es OP_DROP; dies ist ein Bedingungsschema, keine fertige Finanzierungsanleitung. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v29.0 — Script interpreter]
Eine Zeitsperre allein autorisiert keinen Eigentümer. Die Signaturbedingung muss gelten; ein anderer Zweig kann frühere Ausgaben erlauben, und Ablauf sendet keine Zahlung automatisch. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Developer Reference — Transactions]
CLTV legt einen festen Punkt fest, keine Blockzahl seit Output-Bestätigung. CSV mit BIP 68 behandelt das Eingangsalter; Mining-Verzögerungen und Reorganisationen garantieren kein festes Datum. [Bitcoin Core v29.0 — Transaction finality] [Bitcoin Developer Reference — Transactions]
BIP 65 führte CLTV als Soft Fork anstelle von OP_NOP2 ein. Prüfen Sie ganzen Pfad, Grenztyp, nLockTime, nSequence und Gebühr; ein aktiver Opcode garantiert keine schnelle Bestätigung. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core 0.11.2 — BIP 65 release notes]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit CHECKSEQUENCEVERIFY, Bitcoin-Script-Opcode, Timelock, Bitcoin Script. Auf diesen Eintrag verweisen außerdem Timelock, HTLC, Bitcoin-Script-Opcode, CHECKSEQUENCEVERIFY.