OP_CHECKTEMPLATEVERIFY

Anna veut réserver des fonds à répartir plus tard entre Peter et Eva. Elle ne souhaite pas dépendre uniquement de la promesse d’une personne qui détiendrait l’argent. Dans Bitcoin, les fonds non dépensés sont enregistrés comme des sorties de transactions, les UTXO : chacune contient un montant et ses conditions d’utilisation. CTV pourrait ajouter à ces conditions un plan précis de répartition. Lors de la dépense, les nœuds, ces logiciels qui vérifient les règles du réseau, contrôleraient que la nouvelle transaction respecte le plan. Un autre destinataire ou un montant différent de celui fixé ne passerait pas le contrôle. Jeremy Rubin décrit cette proposition dans BIP119, dont le numéro BIP a été attribué en 2020. [1] [3]

Le modèle précise la structure du transfert : à combien de sorties antérieures les entrées font référence et quelles nouvelles sorties doivent être créées. Pour ces dernières, il fixe les montants et les scripts, donc leurs conditions de dépense futures. Plus précisément, BIP119 inclut aussi la version de la transaction ; nLockTime, un champ pour les contraintes temporelles de l’ensemble de la transaction ; les champs nSequence des entrées, qui peuvent agir sur les verrous temporels ; et l’indice de l’entrée en cours de vérification. Si un scriptSig, un script d’entrée fournissant des données de dépense, n’est pas vide, le hash de tous les champs scriptSig est également inclus. C’est donc davantage qu’une liste de destinataires : modifier une autre donnée couverte produit aussi un modèle différent. Les références aux anciennes pièces précisément utilisées et leurs montants sont une question distincte, abordée plus bas. [1]

L’octet est une unité courante de mesure des données. La vérification proposée utilise un hash de modèle de 32 octets calculé avec SHA256. Le nœud recalcule l’empreinte depuis la transaction dépensant la sortie et rejette toute différence. Une signature numérique prouve l’autorisation d’un paiement à l’aide d’une clé privée, une valeur numérique secrète, sans révéler cette clé. Une autre partie du script peut exiger une signature ; CTV ne la remplace pas partout. Les autres longueurs d’argument n’effectuent pas cette vérification et sont réservées à des extensions futures, bien que la politique de relais puisse les rejeter. Un argument incorrect ne garantit donc pas un verrouillage sûr. [1] [4] [12]

Dans l’exemple suivant, les montants sont exprimés en sats, les plus petites unités de bitcoin. Le hash du modèle ne contient directement ni les outpoints, c’est-à-dire les références aux UTXO précisément dépensés, ni leurs montants d’entrée. Le nombre d’entrées est pourtant fixé. Supposons une seule entrée autorisée et des sorties totalisant 99 000 sats. Une entrée de 100 000 sats laisse 1 000 sats de frais. Une entrée inférieure au total des sorties ne finance pas cette transaction. À sorties inchangées, une entrée supérieure augmente les frais au lieu de créer automatiquement de la monnaie rendue. [6] [9]

Le modèle peut imposer le passage vers une autre sortie dont le script comprend un délai et une voie de secours. Cela permet de construire un coffre laissant du temps pour réagir à un retrait indésirable. CTV n’est pas toute la sécurité : clés, conditions ultérieures, surveillance et confirmation du secours à temps restent essentielles. Certaines restrictions peuvent aussi utiliser des transactions présignées, mais avec d’autres exigences de coopération et d’effacement des clés. [8] [5]

Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Dans le contrôle de congestion proposé, une première sortie confirmée engage les fonds vers une répartition ultérieure. Les sorties individuelles des destinataires peuvent être créées par des transactions suivantes, par exemple quand le réseau est moins chargé. Les destinataires doivent connaître le plan et pouvoir exercer leur droit. Ce n’est pas un paiement ordinaire déjà confirmé à leur adresse, et cela ne rend pas l’espace d’un bloc illimité. [7] [11]

Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. Anna peut préparer le plan bien avant de publier le paiement, sans encore connaître les frais futurs. Les sorties fixes ne lui permettent pas de réduire librement le montant rendu à son portefeuille pour proposer la différence au mineur. La construction doit donc prévoir comment ajouter des frais. Un CPFP bien préparé est une possibilité : une transaction suivante dépense une sortie de la première et propose des frais destinés à inciter un mineur à inclure les deux. Autre possibilité : un modèle prévoyant dès le départ une entrée supplémentaire. On ne peut pas simplement ajouter cette entrée à un modèle n’en autorisant qu’une. Le mempool est l’ensemble des transactions non confirmées conservées par un nœud donné ; y être accepté ne garantit pas l’inclusion dans un bloc. [2] [6] [10]

CTV seul vérifie un modèle précis ; ce n’est pas un langage général permettant de lire et de comparer librement toutes les données d’une transaction. Il permet de préparer des plans ramifiés de transactions futures, sans se confondre avec des Covenants récursifs généraux. Des combinaisons avec d’autres instructions proposées peuvent aller plus loin. Il faut vérifier si une démonstration utilise seulement CTV ou tout un ensemble de modifications. [1] [2]

Lors de la vérification du 17 octobre 2026, BIP119 a le statut Draft : il s’agit encore d’une proposition en cours d’élaboration. Il donnerait une nouvelle fonction de contrôle à OP_NOP4, une instruction actuellement sans effet lors de la validation des blocs. Ce renforcement des règles communes est appelé Soft Fork. Le document ne définit toutefois pas lui-même l’activation. Publier un BIP ne fait pas de l’opcode une instruction effectivement imposée ; ni du code, ni le soutien d’un développeur, ni un portefeuille de démonstration ne prouvent son application sur le réseau principal de Bitcoin, mainnet. Il faut donc préciser le réseau, les règles et les autres propositions dont dépend chaque démonstration. [1]

Tant que la règle n’est pas appliquée, sa présence dans un script ne suffit pas à protéger les fonds : consensus et rejet du mempool sont différents. Même avec CTV, un modèle obligatoire unique sans issue alternative peut emprisonner une sortie insuffisamment financée. Un nouveau petit dépôt ne bloque pas automatiquement les autres UTXO correctement financés. Une conception sûre doit vérifier montants, frais, sauvegardes et toutes les voies de récupération. [1] [4] [6]