Verrous temporels : CLTV et CSV

Curiosité

1. Pourquoi un champ de transaction existe-t-il pour retarder les dépenses si une nouvelle transaction peut toujours le contourner ?
2. Comment un mineur peut-il, à lui seul, mentir sur l’heure sans rompre le consensus pour tous les autres ?
3. Quelle est la différence entre attendre jusqu’à une année précise et attendre deux ans à partir de maintenant ?

Explorer

1. Chaque transaction Bitcoin contient un champ nLockTime, une valeur de quatre octets qui empêche la transaction d’être minée avant un certain point. Si la valeur est inférieure à 500 000 000, elle représente une hauteur de bloc ; si elle est égale ou supérieure à ce seuil, il s’agit d’un horodatage Unix. Ce mécanisme ne s’applique toutefois qu’à cette instance précise de la transaction. Un utilisateur peut toujours créer une nouvelle transaction avec les mêmes entrées et un locktime nul, et dépenser immédiatement les pièces. Le nLockTime seul n’offre aucune garantie quant à des conditions futures, car il ne lie pas la sortie elle-même.
2. OP_CHECKLOCKTIMEVERIFY (CLTV), proposé par Peter Todd dans le BIP65 et activé en décembre 2015, change la donne. CLTV est un opcode de script qui compare le nLockTime de la transaction à une valeur présente sur la pile. Si le locktime est inférieur à la valeur requise, l’exécution échoue. Comme cette vérification a lieu dans le script de verrouillage de la sortie, toute tentative de dépenser cette sortie de transaction non dépensée (UTXO) précise doit satisfaire la condition. On obtient ainsi un verrou temporel absolu : les pièces restent indépensables tant qu’un moment ou une hauteur de bloc fixés par le consensus global n’ont pas été atteints.
3. Les verrous temporels relatifs fonctionnent différemment : ils mesurent une durée plutôt que des points absolus. Le BIP68 réinterprète le champ nSequence des entrées de transaction, jusque-là inutilisé à cette fin, pour encoder des délais relatifs. OP_CHECKSEQUENCEVERIFY (CSV), défini dans le BIP112 et activé en même temps que le BIP68 en juillet 2016, compare la valeur de séquence de l’entrée à une durée requise. Cela permet aux scripts d’imposer des conditions comme « cette sortie ne peut pas être dépensée avant 144 blocs après sa confirmation ». Le délai est relatif à la confirmation de cet UTXO précis, ce qui le rend idéal pour des chemins de récupération temporisés ou l’expiration des canaux de paiement.
4. Les verrous basés sur le temps incitaient aussi les mineurs à manipuler les horodatages. Les mineurs pouvaient fixer l’horodatage des blocs jusqu’à deux heures dans le futur afin d’inclure plus tôt que prévu davantage de transactions soumises à un verrou temporel. Le BIP113, activé en même temps que les verrous temporels relatifs en juillet 2016, a introduit le Median Time Past (MTP). Les vérifications de verrous temporels se font désormais par rapport à la médiane des horodatages des onze blocs précédents, et non plus par rapport à l’horodatage du bloc lui-même. Ainsi, aucun mineur isolé ne peut influencer sensiblement l’horloge ; le MTP a généralement environ une heure de retard sur l’heure réelle, ce qui fournit une référence stable et vérifiable pour tous les calculs de verrous temporels.
5. Ces mécanismes sous-tendent des applications complexes comme les canaux de paiement et les protocoles d’héritage. Dans les canaux Lightning, les paiements en cours utilisent des verrous temporels absolus (CLTV) afin qu’un paiement non réclamé puisse être remboursé après une échéance, tandis que des délais relatifs (CSV) sur les propres sorties d’une partie laissent à l’autre partie le temps de sanctionner un état de canal obsolète. Pour l’héritage, les scripts peuvent combiner exigences multisignatures et verrous temporels : par exemple, deux clés sont nécessaires pour l’accès au quotidien, mais après un an d’inactivité, une troisième clé (celle d’un héritier) rejoint le quorum via une condition CSV. Ces paramètres sont fixés à la création du portefeuille et ne peuvent plus être modifiés une fois les fonds verrouillés.
6. Les verrous temporels sont des contraintes permanentes : ils se déverrouillent à un moment fixé, mais n’offrent aucun mécanisme pour reverrouiller ou prolonger les délais après activation. Si un script encode une valeur de séquence de 100 blocs, les pièces deviennent dépensables exactement lorsque cette hauteur relative est atteinte à partir de la confirmation. Des erreurs d’encodage peuvent rendre les fonds inaccessibles plus longtemps que prévu ou, à l’inverse, les déverrouiller trop tôt. Pour une vérification pratique, ouvrez n’importe quelle transaction récente dans un explorateur de blocs et examinez le champ nLockTime. La plupart des portefeuilles le fixent à la hauteur de bloc actuelle, de sorte que la transaction ne peut pas être incluse dans un bloc de hauteur inférieure ; cela supprime une incitation pour les mineurs à réécrire le dernier bloc afin d’en récupérer les frais (« fee sniping »).

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• P. Todd, BIP65: OP_CHECKLOCKTIMEVERIFY (2014)
• M. Friedenbach, BtcDrak, N. Dorier & kinoshitajona, BIP68: Relative lock-time using consensus-enforced sequence numbers (2015)
• BtcDrak, M. Friedenbach & E. Lombrozo, BIP112: CHECKSEQUENCEVERIFY (2015)
• Bitcoin Core source code, policy/policy.cpp and script/interpreter.cpp
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 7