Glossaire / Protocole et mises à jour
OP_CHECKTEMPLATEVERIFY
Aussi appelé CTV, BIP119.
- Qu'est-ce qu'OP_CHECKTEMPLATEVERIFY ?
- OP_CHECKTEMPLATEVERIFY est un opcode proposé qui permettrait à une sortie de s'engager à l'avance sur la transaction exacte autorisée à la dépenser, jusqu'à ses sorties et ses montants.
Spécifié dans BIP-119.
Le BIP-119 le décrit, Jeremy Rubin a publié la première ébauche en janvier 2020, et le réseau ne l'a pas adopté. L'opcode prendrait un hash de 32 octets depuis la pile et échouerait si le hash du modèle de la transaction de dépense, c'est-à-dire sa version, son locktime, son nombre d'entrées, ses séquences, ses sorties et l'index de l'entrée, ne correspond pas. Rien dans votre portefeuille ne l'utilise, et rien ne l'utilisera tant qu'un soft fork ne l'aura pas activé.
Comment cela fonctionne
Statut : proposé, non activé. Le BIP-119 est à l'état d'ébauche depuis 2020, une activation proposée en 2022 a suscité assez d'objections pour être mise de côté, et Bitcoin Core ne contient aucun paramètre de déploiement pour cet opcode.
La conception réutilise une vieille astuce de mise à niveau. L'opcode 179, auparavant OP_NOP4, ne fait actuellement rien du tout, si bien qu'un script qui le contient est valide pour tous les nœuds du réseau. Un soft fork redéfinirait cet octet pour que les nœuds mis à jour effectuent la vérification tandis que les anciens continuent d'accepter le script, le même chemin qu'ont suivi CLTV via OP_NOP2 et CSV via OP_NOP3.
Ce qui est haché est choisi avec un soin inhabituel. Le modèle couvre les sorties, les montants, le nombre d'entrées et leurs numéros de séquence, mais laisse délibérément de côté les outpoints, c'est-à-dire les txid des bitcoins dépensés. Les laisser de côté a deux conséquences sur lesquelles repose toute la proposition. Premièrement, vous pouvez calculer le hash avant que la transaction de financement existe, ce qui permet de construire une chaîne de dépenses futures puis de la financer. Deuxièmement, un modèle ne peut pas contenir d'engagement envers lui-même, la restriction ne peut donc pas se répéter indéfiniment, ce qui explique que ses partisans l'appellent la restriction étroite.
Le résultat est une dépense dont le txid est connu avant qu'elle ait lieu. Un portefeuille peut vous remettre un reçu d'un paiement qui existera plus tard et prouver qu'aucune autre dépense de ce bitcoin n'est possible.
Où cela se voit
OP_CHECKTEMPLATEVERIFY ne s'exécute nulle part sur le mainnet, donc l'endroit où regarder est l'ensemble des applications construites sur des signets personnalisés qui seraient déployées si l'opcode était activé.
Le contrôle de la congestion est le cas le plus cité. Une plateforme d'échange confrontée à une flambée des frais paie 1 000 retraits dans une seule sortie qui s'engage sur un arbre de paiements ultérieurs ; chaque utilisateur peut ensuite développer sa propre branche et prendre livraison quand les frais baissent, et la plateforme a dépensé une sortie au lieu de mille. Les coffres-forts sont le second cas : un retrait doit d'abord arriver dans une sortie de préparation avec un délai, ce qui vous laisse une fenêtre pour récupérer les fonds vers un stockage à froid si la demande n'était pas la vôtre. Les pools de paiement et le financement non interactif de canaux Lightning utilisent la même forme : engagement puis expansion.
Pour quiconque achète du bitcoin, la position honnête est que cela ne change rien sur quoi vous puissiez agir. Il vaut la peine de reconnaître l'acronyme parce qu'il revient constamment dans les débats sur ce que le bitcoin devrait devenir, et parce que les fonctions de coffre-fort que certains services de conservation vantent seraient réellement exécutoires s'il était activé un jour.
OP_CHECKTEMPLATEVERIFY vs OP_CHECKLOCKTIMEVERIFY
OP_CHECKTEMPLATEVERIFY contraint la forme de la transaction de dépense, tandis qu'OP_CHECKLOCKTIMEVERIFY contraint le moment où une dépense peut avoir lieu et ne dit rien sur la destination de l'argent. Les noms presque identiques font que les deux sont constamment confondus.
L'autre différence est le statut, et c'est celle qui compte. OP_CHECKLOCKTIMEVERIFY est appliqué depuis le bloc 388 381 le 14 décembre 2015, et il est utilisé tous les jours par Lightning, les scripts de séquestre et les portefeuilles d'héritage. OP_CHECKTEMPLATEVERIFY n'a jamais été appliqué par un seul nœud sur le mainnet. Si un service vous dit que vos bitcoins sont protégés par un engagement de modèle, il décrit quelque chose que le réseau ne vérifie pas actuellement.