Glossaire / Transactions et frais
Locktime
Aussi appelé nLockTime.
- Qu'est-ce que le locktime ?
- Le locktime est constitué des quatre derniers octets d'une transaction : il fixe la hauteur de bloc ou l'horodatage le plus ancien auquel le réseau acceptera de l'inclure dans un bloc.
Voyez le locktime comme un chèque postdaté inscrit dans le protocole. Un seul champ, deux significations, décidées par un seuil : toute valeur inférieure à 500 000 000 se compte en blocs, et toute valeur égale ou supérieure se compte en secondes depuis 1970. La plupart des transactions que vous enverrez porteront un locktime, et il ne fera rien d'autre que vous protéger d'un tour de passe-passe subtil de mineur.
Comment cela fonctionne
Le locktime se trouve à la toute fin de la transaction sérialisée et il est vérifié avant que tout le reste de la dépense soit examiné.
La règle du seuil est ce qui permet à un seul champ de remplir deux fonctions. Un locktime de 900 000 signifie que la transaction ne peut pas apparaître dans un bloc en dessous de la hauteur 900 000. Un locktime de 1 800 000 000 est un horodatage Unix et signifie que la transaction ne peut pas apparaître avant que le temps médian des onze blocs précédents ne dépasse ce moment. La ligne de partage, 500 000 000, correspond au 5 novembre 1985, ce qui est bien avant l'existence du bitcoin et bien au-dessus de toute hauteur de bloc plausible. Le champ fait quatre octets, la date maximale exprimable est donc le 7 février 2106.
Il existe un interrupteur. Le locktime n'est appliqué que si au moins une entrée porte un numéro de séquence inférieur à 0xffffffff. Réglez toutes les entrées sur 0xffffffff et le champ est entièrement ignoré, ce qui fut le fonctionnement des transactions pendant des années avant que les portefeuilles n'y trouvent un usage.
Cet usage est la lutte contre le vol de frais. Quand les frais sont élevés, un mineur qui perd une course de blocs a intérêt à tenter de re-miner le bloc précédent et d'en voler les frais plutôt que de construire vers l'avant. Si les portefeuilles fixent le locktime de chaque transaction à la pointe actuelle de la chaîne, ces transactions deviennent invalides dans tout bloc antérieur, ce qui supprime l'essentiel du butin et de l'incitation. Bitcoin Core fait ainsi sur les dépenses ordinaires, et environ une fois sur dix il choisit une hauteur uniformément parmi les 100 blocs précédents, afin que les transactions issues de logiciels de portefeuille différents ne se distinguent pas les unes des autres.
Où le voir
Ouvrez n'importe quelle transaction récente sur un explorateur de blocs et le champ locktime contiendra généralement un nombre proche de la hauteur à laquelle elle a été minée.
C'est le comportement de lutte contre le vol de frais, et le constater est une légère empreinte du logiciel qui a construit le paiement. Les portefeuilles qui laissent le champ à zéro annoncent eux aussi quelque chose. Les sociétés d'analyse de chaîne lisent ce champ précisément parce que peu d'utilisateurs y pensent.
Les usages délibérés sont plus étroits. Un locktime dans le futur crée une transaction qui peut être signée et remise maintenant mais diffusée seulement plus tard, ce qui est la base de schémas simples d'héritage et de voies de remboursement. Les transactions de fermeture forcée de Lightning et les swaps sous-marins utilisent des verrous temporels pour qu'une contrepartie qui disparaît ne puisse pas bloquer votre argent pour toujours. Quiconque construit ces montages doit noter la faiblesse évidente : une transaction verrouillée ne vaut que par les bitcoins qui la sous-tendent, et si l'expéditeur dépense ces entrées autrement auparavant, la transaction postdatée devient sans valeur.
Locktime vs OP_CHECKLOCKTIMEVERIFY
Le locktime restreint une transaction ; OP_CHECKLOCKTIMEVERIFY restreint un bitcoin. La différence compte parce qu'un seul des deux lie quelqu'un d'autre que celui qui signe.
Le locktime est choisi par celui qui construit la transaction, il ne protège donc personne : un expéditeur peut simplement construire une autre transaction sans lui. OP_CHECKLOCKTIMEVERIFY, défini dans le BIP65 et actif sur le réseau depuis le bloc 388 381 le 14 décembre 2015, place la condition dans le script de la sortie elle-même. Toute dépense future de ce bitcoin doit elle-même porter un locktime égal ou supérieur au point indiqué, et aucune signature ne peut le contourner. C'est ce qui transforme un verrou temporel d'une intention en une règle, et c'est pourquoi les montages de coffre-fort, de séquestre et d'héritage sont écrits avec l'opcode plutôt qu'avec le champ.