OP_CHECKLOCKTIMEVERIFY compare un argument de pile non négatif au nLockTime absolu de la transaction de dépense et vérifie nSequence de l'entrée. Les règles de finalité vérifient ensuite l'éligibilité temporelle réelle.
nLockTime seul retarde une transaction donnée. CLTV dans la condition de sortie empêche de contourner ce même chemin par un nLockTime inférieur ; les autres chemins doivent être examinés séparément. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Developer Reference — Transactions]
Sous 500000000, la valeur désigne une hauteur de bloc ; à partir de ce seuil, un horodatage. Argument CLTV et nLockTime doivent avoir le même type ; comparer les nombres ne suffit pas. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v29.0 — Script interpreter]
L'argument doit être non négatif et inférieur ou égal à nLockTime. CLTV ne consulte pas l'horloge locale ni ne suspend le script ; un contrôle non satisfait fait échouer la validation. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v29.0 — Script interpreter]
nSequence de l'entrée contrôlée ne doit pas être 0xffffffff. Cela empêche de désactiver nLockTime par des sequences finales ; CLTV n'exige pas de délai relatif non nul particulier. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v29.0 — Script interpreter]
Avec nLockTime = 900000 et une entrée non finale, la première hauteur candidate est 900001 : la finalité exige nLockTime strictement sous la hauteur du bloc. L'égalité de l'argument CLTV ne change pas ce seuil. [Bitcoin Core v29.0 — Transaction finality]
Selon BIP 113, nLockTime temporel est comparé au Median Time Past du bloc précédent, médiane des horodatages des jusqu'à 11 derniers blocs. Il doit être strictement inférieur ; ce n'est pas une heure locale exacte de livraison. [BIP 113 — Median time-past lock-time calculations] [Bitcoin Core v29.0 — Transaction finality]
CLTV ne consomme pas son argument. Dans <hauteur> OP_CHECKLOCKTIMEVERIFY OP_DROP <clé> OP_CHECKSIG, OP_DROP le retire ; c'est un schéma de condition, pas une recette de financement prête à l'emploi. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v29.0 — Script interpreter]
Un verrou temporel seul n'autorise pas un propriétaire. La condition de signature doit rester satisfaite ; une autre branche peut permettre de dépenser plus tôt et l'échéance n'envoie aucun paiement automatiquement. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Developer Reference — Transactions]
CLTV fixe un point, pas un nombre de blocs depuis la confirmation de sortie. CSV avec BIP 68 traite l'âge d'une entrée ; retards miniers et réorganisations ne garantissent pas de date fixe. [Bitcoin Core v29.0 — Transaction finality] [Bitcoin Developer Reference — Transactions]
BIP 65 a introduit CLTV par soft fork remplaçant OP_NOP2. Vérifiez chemin complet, type de seuil, nLockTime, nSequence et frais ; un opcode actif ne garantit pas une confirmation rapide. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core 0.11.2 — BIP 65 release notes]
Pour une vision complète, lisez aussi CHECKSEQUENCEVERIFY, Bitcoin Script opcode, Timelock, Bitcoin Script. Cette entrée est également citée par Timelock, HTLC, Bitcoin Script opcode, CHECKSEQUENCEVERIFY.