Timelock

nLockTime et CLTV forment la paire absolue, BIP68 et CSV la paire relative. nLockTime limite une transaction précise dans son ensemble ; il ne verrouille pas à lui seul un UTXO contre une autre transaction ayant des réglages différents. CLTV ou CSV dans la branche Script exécutée imposent les champs correspondants de la transaction qui dépense la sortie. Une autre branche autorisée peut avoir d’autres conditions. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [BIP 68 — Relative lock-time] [BIP 112 — CHECKSEQUENCEVERIFY]

nLockTime est un champ de 32 bits non négatif ; zéro désactive la condition temporelle absolue. Si toutes les entrées sont réglées sur SEQUENCE_FINAL, de valeur 0xffffffff, un nLockTime non satisfait est ignoré. Un verrou absolu effectif exige qu’au moins une entrée possède un autre nSequence. L’évaluation porte sur cette transaction précise, pas sur un gel permanent de ses entrées. [Bitcoin Core v31.0 — Transaction finality] [Bitcoin Core v31.0 — Sequence constants]

LOCKTIME_THRESHOLD vaut 500000000. Un nLockTime inférieur désigne une hauteur de bloc ; une valeur égale ou supérieure désigne un timestamp Unix. Lorsque le contrôle absolu est actif, nLockTime doit être strictement inférieur à la hauteur du bloc candidat ou au MTP pertinent. L’égalité ne suffit pas ; il ne s’agit ni d’un montant, ni d’une hauteur moyenne, ni d’une date d’activation du protocole. [Bitcoin Core v31.0 — Transaction finality] [Bitcoin Core v31.0 — Locktime threshold]

BIP113 utilise pour la finalité temporelle le MTP du bloc précédent : la médiane des timestamps des 11 derniers blocs se terminant par ce bloc. Ce n’est ni une moyenne arithmétique, ni l’heure actuelle de l’utilisateur, ni le timestamp du bloc candidat. Bitcoin Core utilise GetMedianTimePast ; atteindre une date calendaire ne garantit pas à lui seul que le verrou soit satisfait. [BIP 113 — Median time-past]

OP_CHECKLOCKTIMEVERIFY exige un opérande non négatif, un type hauteur/temps identique à celui de nLockTime et un opérande inférieur ou égal à nLockTime. L’entrée qui dépense la sortie concernée ne doit pas avoir nSequence égal à 0xffffffff. L’opcode ne lit directement ni l’horloge ni la hauteur de la chaîne ; les réglages de la transaction sont vérifiés séparément lors du contrôle de sa validité temporelle. Les autres conditions de Script restent nécessaires. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v31.0 — Script interpreter]

Pour les transactions de version 2 ou supérieure, BIP68 active la condition relative pour les entrées dont le bit 31 n’est pas activé. Les 16 bits de poids faible déterminent le délai ; le bit 22 sélectionne des unités de 512 secondes, sinon des blocs. Le délai en blocs se calcule depuis la hauteur de confirmation de la sortie dépensée. Le délai temporel va du MTP du bloc précédant sa confirmation au MTP précédant le bloc candidat. Il ne s’agit pas du temps écoulé depuis la création de la transaction dans le portefeuille. [BIP 68 — Relative lock-time] [Bitcoin Core v31.0 — Transaction finality]

Avec un opérande actif non négatif, OP_CHECKSEQUENCEVERIFY exige une version au moins égale à 2, le drapeau de désactivation de l’entrée désactivé, un type de délai identique et un nSequence masqué suffisant. BIP68 impose séparément l’âge réel. CSV permet une branche de récupération différée. Pour une sortie Lightning to_local, le délai to_self_delay limite le propriétaire de la transaction de commitment ; l’autre partie, munie de la bonne clé de révocation, peut utiliser la branche de pénalité sans ce délai. [BIP 112 — CHECKSEQUENCEVERIFY] [BOLT 3 — Commitment transaction outputs]

Le bit 31 est SEQUENCE_LOCKTIME_DISABLE_FLAG et désactive l’interprétation relative de BIP68 uniquement pour l’entrée concernée. La valeur 0xfffffffe contient ce bit, mais n’est pas SEQUENCE_FINAL : elle permet un nLockTime effectif et CLTV. La valeur 0xffffffff est finale. Un opérande CSV non négatif avec le drapeau de désactivation activé se comporte comme NOP ; en revanche, ce drapeau activé dans l’entrée ne satisfait pas une exigence CSV active. Ces deux cas ne doivent pas être confondus. [BIP 112 — CHECKSEQUENCEVERIFY] [Bitcoin Core v31.0 — Sequence constants]

Un verrou temporel définit une condition d’éligibilité, pas un planificateur d’envoi. Le portefeuille doit conserver ou créer la transaction, fournir les signatures et les autres données, satisfaire toutes les conditions et assurer les frais ainsi que la propagation. La politique locale et la sélection du mineur influencent encore la confirmation. Une réorganisation peut modifier la hauteur de confirmation de l’entrée et son âge relatif ; le temps écoulé ne garantit pas un résultat irréversible. [BIP 68 — Relative lock-time] [Bitcoin Core v31.0 — Transaction finality]

La RPC decoderawtransaction de Core 31 affiche version, locktime et sequence de chaque entrée. Pour CLTV/CSV, vérifiez le Script réellement utilisé et la sortie dépensée ; le simple décodage ne prouve pas la validité. La RPC testmempoolaccept teste un candidat signé par rapport à la chaîne actuelle et à l’évaluation locale du consensus et de la politique, sans l’accepter dans le mempool ni le diffuser. Vérifiez allowed et le motif de rejet ; un succès ne promet pas de confirmation future. [Bitcoin Core 31.0 — decoderawtransaction RPC] [Bitcoin Core 31.0 — testmempoolaccept RPC] [Bitcoin Core v31.0 — Mempool RPC implementation]