Bitcoin change rarement de visage. Il préfère retoucher l’ossature, calmement, presque en silence. Un angle ici, une soudure là, puis il laisse le temps faire son tri naturel. Cette lenteur n’est pas un défaut. C’est une méthode. Et CHECKTEMPLATEVERIFY, souvent abrégé CTV, incarne parfaitement cette manière de faire : une proposition modeste en apparence, décrite dans le BIP 119, qui ajoute un opcode : OP_CHECKTEMPLATEVERIFY, afin d’imposer un modèle de dépense à une transaction future. Dans le langage Bitcoin, on range ça dans la famille des covenants.
CTV, en clair : un verrou de transaction, pas une baguette magique
L’idée n’est pas de transformer Bitcoin en machine à smart contracts généralistes. L’idée est plus fine, plus “ingénieur” que “marketing”. CTV vise à rendre certains scénarios contractuels beaucoup plus simples, et surtout plus sûrs, en évitant d’introduire une introspection trop puissante dans Script. On gagne en contrôlabilité sans ouvrir une boîte de Pandore. On remplace des bricolages fragiles par une règle ancrée dans le consensus.
Ce qui est intéressant, c’est le contraste avec l’époque. D’un côté, des blockchains qui misent tout sur la flexibilité maximale, quitte à payer le prix en surface d’attaque et en complexité. De l’autre, Bitcoin qui privilégie la robustesse, la vérifiabilité, la minimisation des risques. CTV est un outil taillé pour ce second camp. Il ne promet pas la lune. Il promet moins de surprises.
Pour comprendre CTV sans se perdre
Pour comprendre CTV sans se perdre, imagine une sortie Bitcoin comme une enveloppe scellée. D’habitude, on fixe des conditions classiques : “il faut une signature”, “il faut deux signatures sur trois”, “il faut attendre telle date”. CTV ajoute une nuance plus directive : “pour ouvrir l’enveloppe, tu dois dépenser selon un plan précis”.
Ce plan est un template, un modèle de transaction, et CTV engage à l’avance certains champs de la transaction de dépense. Au moment de dépenser, le réseau vérifie que la transaction correspond au modèle. Si ça ne colle pas, c’est rejeté. Pas “presque”. Pas “à peu près”.
Cette approche est volontairement restrictive. CTV ne donne pas à Script une capacité d’examiner n’importe quoi. Il ne devient pas un mini-EVM coincé dans un UTXO. Il impose plutôt une règle simple : la transaction qui dépense doit matcher une empreinte.
Le BIP 119 décrit précisément ce mécanisme comme une forme de “pattern matching” sur une spécification hachée de transaction. Et c’est là que la magie de Bitcoin opère. En retirant de la liberté, on retire aussi une partie des angles morts. Résultat : des constructions qui reposent aujourd’hui sur des montages hors consensus peuvent devenir plus propres, moins fragiles, moins dépendantes de la confiance.
Ce que CTV vérifie réellement dans une transaction Bitcoin
CTV est souvent présenté comme “de l’introspection limitée”. La formule est juste, et elle explique une grande partie de sa philosophie. Bitcoin Optech résume les éléments pris en compte par l’engagement CTV : la version de transaction, le locktime, le nombre d’entrées et leur structure, les sequences, le nombre de sorties et leur structure, et même la position de l’input dépensé dans la transaction. C’est ciblé. C’est volontaire. Et c’est précisément ce cadrage qui rend l’outil défendable dans l’univers Bitcoin.
Il y a un détail à sentir, pas juste à lire : CTV ne te dit pas “tu peux programmer de la logique complexe sur tout le contenu d’une transaction”. Il te dit plutôt “tu peux verrouiller un chemin de dépense qui ressemble à une transaction précise, ou à une famille de transactions très proches”.
C’est pour ça que le mot template compte autant. On ne programme pas un contrat au sens large. En effet, on pré-dessine une dépense. On la rend obligatoire. Et dans Bitcoin, ce genre d’outil a une vertu rare : il réduit la créativité… donc il réduit les surprises. Moins d’interactions imprévues, moins de “ça marchait en test mais pas en prod”, moins de dépendances implicites entre opcodes.
Le vrai problème que CTV attaque : les transactions pré-signées et la confiance résiduelle
Beaucoup de constructions avancées sur Bitcoin (BTC) existent déjà, en théorie. On peut faire des montages avec des transactions pré-signées, préparer une cascade de dépenses, simuler un coffre-fort, construire des scénarios à plusieurs étages. Le problème n’est pas la possibilité abstraite. Le problème, c’est la tenue dans le monde réel. Car les transactions pré-signées introduisent presque toujours une épine très Bitcoin : la confiance résiduelle.
Tu finis par dépendre d’hypothèses implicites. “Personne ne va signer autre chose.” “Les signatures resteront disponibles.” “Les participants ne vont pas changer d’avis au pire moment.” Et c’est souvent exactement au pire moment que la réalité te rappelle qu’un arrangement social n’est pas une garantie cryptographique.
CTV a été conçu pour retirer une bonne partie de cette fragilité. Le BIP met en avant la réduction des besoins de confiance, d’interactivité et de stockage liés au pré-signing. Ce point est central, presque philosophique : dans Bitcoin, un contrat qui exige de se faire confiance n’est pas un contrat. C’est un accord fragile. Et un accord fragile casse précisément quand il devient cher. CTV déplace donc le gardien : on ne s’appuie plus sur la bonne foi, on s’appuie sur le consensus.
Un détour utile : Bitcoin aujourd’hui, c’est déjà des contraintes partout
Avant d’aller plus loin, il faut casser une fausse opposition qu’on voit souvent traîner : “covenants = contrôle = anti-Bitcoin”. La réalité est plus nuancée. Bitcoin est déjà un système de contraintes, partout, tout le temps. Le supply est une contrainte. Le rythme des blocs est une contrainte. La validation est une contrainte.
Les scripts sont une contrainte. Les standards de relay sont une contrainte. Même la structure UTXO est une contrainte architecturale fondamentale. Bitcoin n’est pas une plateforme qui cherche à tout permettre. C’est un protocole qui cherche à permettre un petit nombre de choses, mais à les permettre très bien, très sûrement, avec une adversité maximale.
Et sur la chaîne, on voit bien que les usages évoluent par couches, sans “autorisation marketing”. Regarde simplement les types d’UTXO : le rapport UTXO set de mempool.space montrait, sur un snapshot 2025, une part importante de Taproot (p2tr) en nombre d’UTXO, mais une part plus faible en valeur totale stockée.
Ça raconte une adoption progressive, par paliers, plutôt qu’un basculement brutal. CTV s’inscrit exactement dans cette logique : pas une révolution, une brique. Et comme souvent sur Bitcoin, la question n’est pas “est-ce puissant ?” mais “est-ce que ça reste sûr quand on le met dans les mains du monde entier ?”
Les “vaults” : quand la sécurité devient un scénario, pas une habitude
Un des cas d’usage les plus cités pour CTV, ce sont les vaults, les coffres-forts Bitcoin. Le principe est simple à formuler mais difficile à rendre vraiment solide : tu veux déposer des bitcoins dans une sortie qui, si elle est dépensée, déclenche une période de latence. Cette latence donne le temps de réagir en cas de vol. Tu peux imaginer une transaction d’alerte qui renvoie les fonds vers un cold storage si une dépense suspecte démarre. Dans un monde où les attaques sur les wallets ne relèvent pas de la théorie, ce genre de construction est tout sauf un gadget.
James O’Beirne a beaucoup travaillé sur ce thème, et son papier “Vaults and Covenants” explique comment des covenants peuvent réduire le risque de vol, en discutant différentes constructions. Là où CTV devient séduisant, c’est qu’il peut simplifier la mise en œuvre : au lieu d’empiler des transactions pré-signées et des conditions qui deviennent vite un labyrinthe, tu rends certains chemins obligatoires.
Le vault n’est plus un montage qu’on espère stable. Il devient un montage que le consensus impose. Galaxy résume bien ce lien : OP_VAULT, proposé en 2023, s’appuie sur CTV pour définir des conditions de dépense sans exiger que le déposant pré-signe une collection de transactions complexes. Et ce n’est pas du confort. C’est une réduction massive de la surface d’erreur humaine. Or sur Bitcoin, l’erreur humaine est l’ennemi le plus rentable.
CTV et Lightning : moins de coordination, plus de “non-interactif”
Lightning est souvent présenté comme “le” plan d’échelle de Bitcoin. C’est vrai en partie, mais Lightning a un coût caché : la coordination. Ouvrir et gérer des canaux implique des échanges, des signatures, des mises à jour d’état, des contraintes de disponibilité.
Même si l’expérience utilisateur s’améliore, le squelette reste exigeant. CTV est régulièrement mentionné comme une pièce utile pour réduire certains besoins d’interactivité, notamment via des constructions qui ressemblent à des channel factories ou à des arbres de sorties servant de réserve de canaux potentiels.
Le concept de timeout trees, associé aux travaux de John Law, vise justement à produire une arborescence de transactions off-chain qui restent sûres contre le vol seulement pendant une période donnée. Bitcoin Optech a publié une fiche dédiée début janvier 2026. L’intérêt, côté Bitcoin, est presque poétique : tu transformes une coordination permanente en un plan pré-écrit. Tu réduis la danse des signatures. Tu formalises des sorties prêtes à servir.
Même si toutes les promesses “Lightning non interactif” ne dépendent pas uniquement de CTV, une partie des idées de scaling LN discutées ces dernières années font explicitement référence à des covenants simples comme CTV, y compris dans des contenus orientés développeurs. CTV ne remplace pas Lightning, mais il peut rendre certains chemins Lightning plus fluides, plus industrialisables, moins artisanaux.
Une parenthèse “réalité terrain” : ce que racontent les métriques on-chain et LN
Les débats sur CTV sont techniques, mais ils visent des usages concrets. Et ces usages vivent dans un environnement réel : frais, mempool, adoption de Lightning. Au 14 janvier 2026, mempool.space affichait des frais très bas pour les transactions “no priority”, autour de 1 sat/vB dans l’interface publique, avec un minimum indiqué autour de 0,1 sat/vB selon les vues.
C’est une photographie, pas une loi physique. Mais ça rappelle quelque chose de simple : le marché des frais respire par cycles, et les constructions contractuelles doivent fonctionner aussi bien dans le calme que dans la congestion. Sur une mesure plus macro, YCharts indiquait un average transaction fee proche de 0,94 $ par transaction autour de cette même période.
Côté Lightning, 1ML affichait environ 4 796 nœuds et 13 356 canaux au moment de la capture, avec des variations sensibles sur 30 jours selon leur méthodologie. Ces chiffres ont deux lectures : Lightning existe, il tourne, mais l’infrastructure reste mouvante, parfois fragile, parfois opaque. Beaucoup de canaux sont privés et n’apparaissent pas dans certains index, ce qui rend les photos publiques toujours partielles.
Dans ce contexte, une amélioration qui réduit la coordination ou la complexité peut compter. Pas parce que ça “moon” quoi que ce soit. Parce que ça réduit les coûts d’ingénierie. Et sur Bitcoin, les coûts d’ingénierie finissent toujours par se transformer en coûts utilisateurs.
CTV et pools de minage : l’idée d’une redistribution sans opérateur
Un sujet revient régulièrement quand on parle d’architecture Bitcoin : la centralisation des pools de minage. Pas forcément une centralisation malveillante. Plutôt une centralisation par commodité. Tu délègues à un opérateur la coordination, la sélection, la distribution. CTV ouvre une porte conceptuelle intéressante : rendre certaines distributions obligatoires via un plan de transaction.
Le pool ne serait plus un guichet qui promet. Il deviendrait un processus où la récompense suit un modèle verrouillé. Dans cette veine, Bitcoin Optech place les timeout trees dans un cadre plus large de contrats “trustless” structurés en arbre. Il faut rester prudent : entre une possibilité cryptographique et un produit déployé, il y a un canyon. Mais l’intuition est là : CTV peut rendre plus réaliste une coordination “sans chef” sur certains flux, en réduisant la latitude d’un intermédiaire.
Pourquoi CTV fait débat : le mot “covenant” déclenche une alarme culturelle
Sur Bitcoin, certains mots agissent comme des étincelles. “Inflation.” “Hard fork.” “Censorship.” Et “covenant.” Même si CTV est volontairement limité, il appartient à cette famille. Et cette famille inquiète une partie de la communauté pour une raison simple : si tu peux restreindre les dépenses, tu peux imaginer des usages qui ressemblent à du contrôle. C’est souvent là que les discussions quittent le code pour entrer dans la sociologie. Pas parce que les gens deviennent irrationnels. Parce que Bitcoin est un protocole politique au sens noble : il coordonne des intérêts sans arbitre.
On a vu des débats vifs autour de la lettre “CTV + CSFS”, publiée le 9 juin 2025, demandant de prioriser la revue et l’intégration de CTV (et CSFS) dans Bitcoin Core. Cette lettre a cristallisé des réactions, notamment sur la forme, certains y voyant une pression via une liste de signataires. Des réponses sur la mailing list ont explicitement critiqué l’idée de pousser un changement de consensus de cette manière.
Sur X, ce clivage apparaît aussi : Jimmy Song commentait l’absence de recoupement entre certains signataires de lettres différentes, avec un ton sceptique, tandis que d’autres voix poussaient pour “faire passer” CTV + CSFS afin de donner plus d’outils aux développeurs.
On trouve même des oppositions plus frontales, avec une prudence assumée : “je n’implémenterai pas CTV/CSFS, j’aime Bitcoin comme il est, tout changement majeur introduit des risques”. Ce débat n’est pas un accident. C’est une fonction de sécurité du protocole. Bitcoin n’évolue pas parce qu’une fonctionnalité est cool. Il évolue quand le rapport bénéfice/risque est défendable face à des adversaires compétents.
CTV n’arrive jamais seul : CSFS, OP_CAT, et la question des “paquets” d’opcodes
CTV est souvent discuté avec d’autres propositions, et ça change la dynamique. La lettre de 2025 parlait de CTV + CSFS ensemble. CSFS, OP_CHECKSIGFROMSTACK, est un opcode connu sur des sidechains type Elements, parfois proposé pour Bitcoin, et discuté dans la littérature Optech. L’idée derrière l’association est simple : certains cas d’usage deviennent plus intéressants quand on combine des primitives.
CTV verrouille une structure de transaction. CSFS aide à vérifier des signatures sur des messages arbitraires, ouvrant des schémas plus riches. Mais associer des opcodes, c’est aussi additionner les débats. Tu ne défends plus une brique. Tu défends un lot. Et Bitcoin aime rarement les lots. Le protocole préfère les ajouts minimaux, analysables isolément.
On voit d’ailleurs d’autres propositions revenir dans la même période, comme OP_CAT, souvent cité dans des discussions sur de possibles upgrades à venir. CTV se retrouve au centre de cette géométrie : assez simple pour être acceptable à certains, assez symbolique pour inquiéter d’autres.
Le point rarement expliqué : CTV peut rendre Bitcoin plus simple… en le rendant moins flexible
Ça sonne paradoxal, mais c’est l’un des arguments les plus solides en faveur de CTV. Quand un système est trop flexible, il devient un terrain d’improvisation. Et l’improvisation est la mère des bugs. Surtout quand l’argent est réel. Surtout quand l’adversaire peut être un robot patient. CTV limite ce qu’on peut exprimer, donc il peut rendre certains contrats plus simples à raisonner, plus simples à auditer, donc plus robustes.
C’est aussi pour ça que des ressources de vulgarisation technique décrivent CTV comme l’une des propositions de covenant les plus “matures”, précisément parce qu’elle vise une simplicité conservatrice plutôt qu’une expressivité sans limite. Ce n’est pas une promesse de magie. C’est une promesse d’ingénierie : réduire la complexité opérationnelle de scénarios qui existent déjà, mais qui sont aujourd’hui pénibles à déployer proprement.
Où en est CTV, concrètement, début 2026 ?
CTV est une proposition documentée (BIP 119) maintenue dans le dépôt officiel des BIPs. Le fait d’être publié ne veut pas dire “accepté”, et le dépôt rappelle explicitement que la publication n’implique pas consensus. Il y a eu des démarches publiques pour pousser la revue et l’intégration, notamment via la lettre CTV + CSFS de juin 2025, qui mentionnait une pull request d’implémentation dans Bitcoin Core (PR #31989) comme point de référence.
Il y a aussi eu des discussions sur la mailing list autour d’ateliers et de processus de revue. Et comme toujours sur Bitcoin, l’état réel est sobre : la proposition existe, les cas d’usage sont étudiés, le débat technique et social continue, et l’activation dépendra d’un alignement rare entre prudence, clarté, et intérêt collectif.
CTV, une brique discrète qui pourrait compter lourd
CHECKTEMPLATEVERIFY ne cherche pas à rendre Bitcoin “fun”. Il cherche à rendre Bitcoin plus prévisible dans certains scénarios complexes. Les promesses les plus crédibles tournent autour de la sécurité, de la réduction de confiance, et de l’amélioration de certaines architectures de scalabilité par des schémas structurés en arbres. La sécurité d’abord, via des vaults mieux cadrés, plus auditables, moins dépendants de montages fragiles.
La scalabilité ensuite, surtout indirectement, en facilitant des constructions proches des timeout trees et certains chemins Lightning moins interactifs. La réduction de confiance enfin, en remplaçant des arrangements sociaux par des règles de consensus, ce qui est une des mécaniques fondamentales du design Bitcoin. Reste la prudence culturelle : CTV porte l’étiquette “covenant”, donc il déclenche des réflexes. Parfois justifiés. Parfois exagérés. Mais ce filtre fait partie du protocole autant que la cryptographie.
Si CTV est activé un jour, il ne sera probablement pas célébré comme un feu d’artifice. Il sera intégré comme une pièce d’horlogerie. On l’oubliera presque. Et c’est peut-être la meilleure définition d’une bonne évolution sur Bitcoin.
