CLTV

Anna prévoit de conserver ses bitcoins de façon à ce que Pierre et elle autorisent ensemble les paiements ordinaires. En cas d’indisponibilité prolongée, elle souhaite aussi une voie de secours utilisable seulement après une limite choisie. CLTV inscrit cette condition temporelle dans le script, les règles permettant de dépenser les bitcoins reçus. Le champ nLockTime seul ne retarderait qu’une transaction particulière. CLTV empêche de contourner cette voie avec une nouvelle transaction portant une limite plus basse. D’autres branches peuvent néanmoins avoir des règles différentes. [1] [5]

CLTV ne reconnaît pas le propriétaire et n’envoie pas d’argent. Si la voie de secours exige la signature d’Anna, elle doit toujours la fournir une fois la condition temporelle remplie. La clé privée est une valeur numérique secrète qui permet de créer cette signature. Le temps ne restitue pas une clé privée perdue. Les fonds ne passent pas non plus automatiquement à une autre adresse : quelqu’un doit préparer, signer et diffuser une transaction valide. Si une autre branche autorise une dépense plus tôt, le verrou de la voie de secours ne restreint pas à lui seul cette possibilité. [1]

Un bloc regroupe des transactions en un lot ajouté à l’historique commun. CLTV convient à une condition liée à un point prédéterminé, pas à l’exigence d’attendre un certain nombre de blocs après la réception de ces bitcoins. C’est CSV, avec BIP 68 et ses règles de verrouillage relatif, qui répond à ce second besoin. Le délai dépend alors de la confirmation d’une sortie précise : un montant reçu assorti de conditions de dépense. Aucune de ces approches ne garantit une date exacte. Le rythme du minage varie et une réorganisation peut modifier l’historique confirmé. Lors d’une réorganisation, le réseau adopte une autre branche valide de la chaîne, qui remplace une partie de l’historique précédent. [1] [7] [8] [9]

CLTV distingue deux types de valeurs. En dessous de 500000000, il s’agit d’une hauteur de bloc, sa position dans la chaîne. À partir de cette limite, il s’agit d’un horodatage, une représentation numérique du temps. La condition du script et le nLockTime de la transaction qui dépense doivent utiliser le même type. Comparer seulement la grandeur des nombres ne suffit pas : une position de bloc et une heure ne représentent pas la même chose. [1] [3] [5]

Un Full Node vérifie lui-même les règles. Il compare la limite non négative du script au nLockTime absolu de la transaction. Cette limite ne doit pas dépasser nLockTime ; l’égalité est autorisée pour cette vérification. La transaction doit aussi respecter les règles d’inclusion dans un bloc donné. CLTV ne consulte pas l’horloge de votre ordinateur et ne suspend pas un programme jusqu’au matin. Si la vérification échoue, cette tentative d’utiliser la voie de dépense est invalide. [1] [3] [4]

Une entrée de transaction désigne les bitcoins reçus auparavant que l’on souhaite dépenser. Elle comporte notamment le champ nSequence. Pour l’entrée vérifiée par CLTV, ce champ ne doit pas valoir 0xffffffff, la valeur spéciale de séquence finale. Si toutes les entrées l’utilisaient, nLockTime pourrait être désactivé. CLTV l’empêche en exigeant une séquence non finale pour cette entrée. Cela ne fixe toutefois pas automatiquement une durée d’attente relative précise : d’autres règles s’en chargent. [1] [3] [4]

Prenons une transaction fictive avec nLockTime fixé à 900000 et une entrée non finale. Pour cette condition temporelle, le premier bloc possible est 900001. L’inclusion exige que nLockTime soit strictement inférieur à la hauteur du bloc candidat. Le bloc 900000 ne suffit donc pas, même si la comparaison interne de CLTV acceptait l’égalité. Ici, « finalité » signifie admissibilité dans un bloc, pas irréversibilité du paiement. Les frais, les autres conditions et le choix du mineur peuvent encore retarder la confirmation. [4]

Pour un horodatage, BIP 113 utilise le Median Time Past du bloc précédent : la valeur centrale des horodatages triés des derniers blocs, jusqu’à 11. Ce n’est ni votre montre ni l’heure du bloc en cours de minage. Le nLockTime temporel doit lui être strictement inférieur. Impossible donc de promettre que les fonds seront dépensables exactement à midi, heure locale. Cette condition est vérifiable par le réseau ; elle n’est pas un calendrier précis de paiements. [2] [4]

Pendant son évaluation, le script utilise une pile, un espace de travail où s’empilent les données. CLTV vérifie son argument temporel sans le retirer. Dans un schéma simple, OP_CHECKLOCKTIMEVERIFY est donc suivi de OP_DROP pour le supprimer ; une clé publique est ensuite placée sur la pile et OP_CHECKSIG vérifie la signature. La clé publique sert à vérifier les signatures et n’a pas besoin de rester secrète. Cet exemple explique le rôle des instructions, mais ne constitue pas une recette prête à bloquer des fonds. La version du script, les données initiales et toutes les autres voies de dépense doivent aussi être correctes. [1] [3]

BIP 65 a introduit CLTV par un soft fork, un durcissement des règles remplaçant l’ancien OP_NOP2. Ce n’est donc pas simplement une fonctionnalité envisagée pour l’avenir. Il faut pourtant vérifier toute la conception : type de limite, nLockTime, nSequence, signatures et branches alternatives. Bitcoin Core v29.0 et les spécifications liées permettent de consulter les détails. Pour l’utilisateur, l’essentiel est de comprendre qui peut dépenser avant et après la limite, ainsi que les possibilités de récupération. [1] [3] [6] [10]