Covenants et coffres : CTV, OP_CAT et le débat de 2026

Curiosité

1. Pourquoi un script Bitcoin standard peut-il vérifier qui détient les clés, mais pas où vont les pièces ensuite ?
2. Quelles contraintes spécifiques OP_CHECKTEMPLATEVERIFY impose-t-il aux transactions futures ?
3. Pourquoi la réactivation d’un seul opcode de concaténation, par soft fork, ouvrirait-elle la voie aux covenants ?

Explorer

Partie IPropositions de covenants : CTV et OP_CAT

1. Le langage de script standard de Bitcoin vérifie la possession d’une clé ou d’un hachage, mais il ne peut pas restreindre la destination des pièces une fois déverrouillées. Un covenant change cela en imposant des conditions sur le `scriptPubKey` des sorties descendantes. On compare souvent ce mécanisme aux titres-restaurant : contrairement aux espèces, qui se dépensent partout, ces fonds sont réservés à des restaurants partenaires précis. Parmi les usages proposés figurent des coffres (vaults) avec des chemins de retrait différé, le contrôle de la congestion et des conceptions plus simples de Lightning.
2. Jeremy Rubin a proposé OP_CHECKTEMPLATEVERIFY (CTV) en 2019. Cet opcode intègre dans l’UTXO actuel un hachage d’un modèle de transaction future. Pour le dépenser, la transaction de dépense elle-même doit correspondre exactement à ce modèle ; aucune signature n’intervient dans l’étape de vérification. Il fixe le coup suivant avant que le coup en cours ne soit joué. Tout écart dans les montants, les destinations ou la structure du script fait échouer immédiatement la validation, ce qui garantit le strict respect du chemin prédéfini.
3. La limite de CTV est sa rigidité : les sorties de la transaction suivante sont fixées au moment où les pièces sont verrouillées, si bien que les frais doivent être gérés autrement, par exemple avec une sortie d’ancrage et le mécanisme child-pays-for-parent (CPFP). En contrepartie, CTV est simple à analyser et peu coûteux à valider.
4. OP_CAT, un opcode qui concatène deux éléments de la pile, a été désactivé par Satoshi Nakamoto en 2010 par précaution contre les attaques par épuisement de la mémoire. Le BIP347 propose de le réactiver uniquement dans tapscript. Combiné à des astuces reposant sur les signatures Schnorr, OP_CAT permet des covenants et d’autres logiques complexes sans exiger de nouvelles règles de consensus pour chaque cas d’usage. Il fournit une brique élémentaire que les développeurs peuvent combiner pour créer des restrictions sur mesure sur les transactions futures.
5. Parmi les propositions apparentées figure OP_CHECKSIGFROMSTACK (BIP348), qui vérifie une signature portant sur un message arbitraire fourni sur la pile plutôt que sur la transaction de dépense. Cette flexibilité, combinée à CTV (ou, séparément, à la proposition ANYPREVOUT), permettrait des canaux Lightning symétriques où aucune des parties n’aurait à stocker des données de pénalité pour chaque ancien état du canal.
6. En 2026, aucune de ces propositions de covenants n’a encore été activée, même si les efforts d’activation et les discussions se poursuivent. Le débat porte toujours sur leur utilité, le risque qu’elles ajoutent aux règles de consensus et le processus de gouvernance nécessaire à leur activation. L’extension des règles de consensus soulève des questions de complexité du réseau et de maintenabilité à long terme qui restent sans réponse au sein de la communauté.

Partie IICovenants et vaults : le débat en 2026

7. Les scripts Bitcoin vérifient actuellement des conditions portant sur la transaction en cours, telles que les signatures ou les timelocks. Ils ne peuvent pas examiner les sorties de la transaction qui les dépense. Les covenants élargissent cette portée : un scriptPubKey peut imposer des contraintes au scriptPubKey des sorties créées par la transaction qui le dépense. Cela restreint la destination suivante des pièces, ce qui permet des fonctionnalités comme les listes blanches d’adresses et les canaux de paiement non interactifs.
8. Le BIP-119 propose OP_CHECKTEMPLATEVERIFY (CTV). Il permet à un script d’intégrer un hash de modèle ; la transaction de dépense doit correspondre à ce modèle pour ses sorties, son nombre d’entrées, ses séquences, son locktime et sa version, mais pas quant aux entrées dépensées. CTV est non récursif : il ne contraint que l’étape immédiatement suivante. Il remplace OP_NOP4 et nécessite un soft fork. Il peut servir de base à des « vaults », qui ajoutent un délai permettant de récupérer les fonds en cas de vol.
9. Dans un vault, les retraits doivent passer par une période d’attente (par exemple 12 heures) pendant laquelle une clé de récupération distincte peut mettre les fonds en sécurité. Si un attaquant vole la clé d’usage courant et lance un retrait, le propriétaire le voit on-chain et récupère les fonds avant la fin du délai. Le vol de clé passe ainsi d’une perte irréversible à un incident récupérable, à condition que la victime surveille la blockchain.
10. Malgré des discussions depuis 2013, aucun soft fork de covenant n’a été activé. Taproot (novembre 2021) reste la dernière mise à niveau majeure. En février 2026, un client d’activation pour le BIP-119 a été publié sans participation de Bitcoin Core. Il exige un signalement de 90 % des mineurs entre mars 2026 et mars 2027. En mai 2026, ce signalement restait proche de zéro, signe d’une absence de consensus sur son adoption.
11. La spécification d’OP_CAT (BIP-347) a été finalisée en mars 2026, mais elle ne comporte pas de paramètres d’activation. OP_CAT permet de concaténer des éléments de script, ce qui autorise une logique plus complexe que CTV seul. CTV est souvent associé à CheckSigFromStack (CSFS), qui vérifie une signature sur des données arbitraires issues de la pile, et pas seulement sur la transaction de dépense. Ensemble, ils apportent des gains d’expressivité importants pour les smart contracts et la conception de protocoles.
12. Le débat porte sur des compromis : les covenants renforcent la sécurité et permettent de nouveaux protocoles comme les vaults, mais ajoutent de la complexité et des risques de gouvernance. Un soft fork modifie les règles de consensus, ce qui exige un large accord des mineurs et des opérateurs de nœuds. La stagnation actuelle reflète une prudence face aux bugs d’implémentation et à l’irréversibilité des changements d’état de la chaîne. Les utilisateurs doivent mettre en balance ces gains et le risque d’une activation ratée ou contestée.

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.

• J. Rubin, OP_CHECKTEMPLATEVERIFY (BIP119), 2019-2020
• BIP347: OP_CAT in Tapscript (E. Heilman & A. Sabouri, 2023)
• BIP348: CHECKSIGFROMSTACK (B. Black & J. Rubin, 2024)
• Bitcoin Optech, 'Covenants' topic guide
• J. Rubin, BIP-119: OP_CHECKTEMPLATEVERIFY (2020)
• E. Heilman & A. Sabouri, BIP-347: OP_CAT in Tapscript (2024)
• Delving Bitcoin activation discussions (2026)