OP_CHECKLOCKTIMEVERIFY

Un verrou temporel inscrit dans la pièce plutôt que dans la transaction qui la dépense. Peter Todd l'a spécifié dans le BIP65, où il a repris l'emplacement de l'ancien opcode sans effet NOP2, et la règle est appliquée depuis le bloc 388 381 en décembre 2015. Si vous avez déjà mis en place un plan de succession ou un chemin de récupération, cet opcode est ce qui maintient la porte fermée.

Comment cela fonctionne

OP_CHECKLOCKTIMEVERIFY lit un nombre sur la pile du script, le compare au champ locktime de la transaction qui tente de dépenser la pièce, et interrompt tout le script si la dépense est prématurée.

Le BIP65 énumère cinq façons dont la vérification échoue : la pile est vide, l'élément du haut est négatif, l'élément et le locktime de la transaction ne s'accordent pas sur le fait de compter des blocs ou des secondes, l'élément est supérieur au locktime de la transaction, ou le numéro de séquence de l'entrée est fixé à 0xffffffff. Cette dernière condition ferme un trou évident. Un locktime est entièrement ignoré lorsque toutes les entrées sont marquées comme finales, donc sans elle celui qui dépense pourrait simplement désactiver l'échéance et repartir avec l'argent.

Deux détails surprennent ceux qui lisent un tel script pour la première fois. L'opcode ne consomme pas le nombre qu'il vérifie, donc les scripts réels le font suivre d'OP_DROP pour nettoyer la pile. Et il accepte un opérande de cinq octets plutôt que les quatre habituels, parce que la plus grande valeur qu'il peut avoir à comparer est 2**32-1, toute la plage du champ qu'il vérifie.

La mécanique du soft fork était du type ordinaire. Redéfinir un opcode sans effet est invisible pour un logiciel qui n'a pas été mis à jour : un ancien nœud exécute l'opcode, ne fait rien et accepte le bloc quand même. L'activation a utilisé les seuils de signalement des mineurs de l'époque, 750 blocs en 1 000 pour commencer l'application et 950 en 1 000 pour la rendre obligatoire.

Où vous le rencontrez

OP_CHECKLOCKTIMEVERIFY apparaît partout où de l'argent doit rester immobile jusqu'à une certaine date.

Les portefeuilles de succession et de récupération en sont le cas le plus clair. Un descriptor peut indiquer que votre propre clé dépense à tout moment tandis qu'une clé de sauvegarde ne dépense qu'après une hauteur donnée, ce qui offre à un héritier un chemin qui ne nécessite la coopération de personne et aucun avocat tenant une enveloppe scellée. Miniscript l'écrit sous la forme du fragment after(), et les portefeuilles qui le prennent en charge vous montrent la hauteur en langage clair plutôt qu'en script brut.

Lightning l'utilise pour l'échéance absolue d'un paiement routé. Une facture BOLT11 porte un delta d'expiration final, 18 blocs par défaut, et les contrats hachés le long de la route sont empilés au-dessus de ce chiffre afin que chaque saut puisse récupérer ses fonds dans un ordre fixe si le paiement ne se termine jamais.

Le séquestre et les remboursements sans tiers suivent la même forme : payez dans un script maintenant, et si la contrepartie ne signe jamais, récupérez l'argent une fois l'échéance passée. L'opcode est aussi la réponse honnête à quiconque vend un « coffre à verrouillage temporel » comme produit, car c'est tout ce qu'un tel produit peut être.

OP_CHECKLOCKTIMEVERIFY vs OP_CHECKSEQUENCEVERIFY

OP_CHECKLOCKTIMEVERIFY nomme un instant ; OP_CHECKSEQUENCEVERIFY nomme une durée. L'un dit « pas avant décembre », l'autre dit « pas avant 144 blocs après la confirmation de cette pièce précise », et seul le second démarre son compte à rebours quand la pièce arrive. Le BIP112 a défini la forme relative et elle s'est activée au bloc 419 328 en juillet 2016, environ sept mois après son homologue absolu. Les protocoles contractuels utilisent les deux, souvent dans un même script : une échéance absolue pour borner tout l'accord, et un délai relatif pour garantir à une partie une fenêtre de réaction.