Covenants, OP_CAT et OP_CTV : Tout savoir sur la prochaine mise à jour de Bitcoin

Comment résoudre les problèmes de scalabilité de Bitcoin ?

Dans la communauté des cryptomonnaies, la blockchain Bitcoin a la réputation d'être un réseau lent et coûteux à utiliser, avec une capacité de calcul limitée qui rend la création de smart contracts plus complexe que sur d'autres blockchains.

Cette lenteur, la petite taille de ses blocs et sa capacité de calcul limitée sont pourtant les caractéristiques qui font de Bitcoin le réseau le plus sécurisé, le plus décentralisé et le plus résistant à la censure qui existe. Augmenter la taille des blocs, par exemple, ferait grossir la blockchain trop vite et ferait grimper rapidement le coût de fonctionnement d'un nœud.

La décentralisation d'une blockchain dépend avant tout du nombre de nœuds qui partagent l'historique des transactions. Si cet historique grossit plus vite que les capacités du matériel informatique, le réseau risque de se centraliser peu à peu, car participer à la validation deviendra plus cher et moins accessible.

Ce principe s'appuie sur la loi de Moore, qui explique aussi le trilemme de la blockchain, selon lequel une blockchain qui cherche à passer à l'échelle doit faire des compromis sur sa sécurité et sa décentralisation.

À titre de comparaison, Ethereum est plus scalable que Bitcoin, mais la taille de sa blockchain augmente très vite, ce qui le pousse vers la centralisation avec le temps. De la même manière, le réseau Kaspa est plus scalable que Bitcoin et pourrait devenir plus décentralisé, mais il fait un compromis sur la sécurité en utilisant des nœuds dits « élagués » (pruned nodes).

Pour rendre Bitcoin plus rapide, plusieurs types d'infrastructures, que l'on retrouve sur notre carte Bitcoin L2, ont été proposés :

• Les sidechains, des chaînes alternatives qui fonctionnent en étroite relation avec Bitcoin sans en dépendre entièrement ni profiter de sa sécurité, comme Liquid (L-BTC) ou Stacks (STX) ;
• Les solutions de layer 2, des infrastructures qui effectuent les calculs en dehors du réseau principal et n'y inscrivent au final qu'une empreinte, comme BitVM et RGB, toujours en développement ;
• Le Lightning Network, un réseau de canaux de liquidité qui permet de transférer des BTC de manière quasi instantanée et pour un coût très faible.

Parmi les solutions proposées figurent aussi des modifications de la blockchain Bitcoin elle-même, comme la mise à jour SegWit en 2017 et Taproot, en place depuis 2021.

Plus récemment, le sujet des covenants a gagné en visibilité. Ces mécanismes, qui permettraient de fixer des conditions à la manière dont des BTC pourront être dépensés, alimentent de nombreux débats autour d'une possible mise à jour de Bitcoin et d'un nouveau soft fork, c'est-à-dire une modification des règles du protocole qui reste compatible avec les anciennes versions du logiciel.

Avant d'entrer dans le vif du sujet, il faut comprendre comment fonctionne le langage Script pour saisir ce qu'impliquent les covenants et les opcodes.

Comment fonctionne Script, le langage de programmation de Bitcoin ?

Le mécanisme de transfert des BTC sur Bitcoin est assez différent de celui des blockchains qui utilisent la machine virtuelle d'Ethereum (EVM).

Ces blockchains regroupent les jetons identiques reçus par une même adresse. Bitcoin, lui, n'additionne pas le solde total détenu par le portefeuille. Il enregistre chaque réception de BTC sur une adresse comme une sortie de transaction distincte (output) et chaque envoi vers une adresse externe comme une entrée de transaction distincte (input).

Les BTC que nous détenons dans un portefeuille Bitcoin sont donc stockés sous la forme de sorties de transaction non dépensées, appelées « Unspent Transaction Outputs » ou « UTXO ».

Ces UTXO fonctionnent un peu comme une version numérique des billets ou des pièces de monnaie. Si vous recevez 1 BTC, vous détenez 1 UTXO d'une valeur de 1 BTC. Une fois dépensé, cet UTXO de 1 BTC est consommé comme entrée de la transaction, qui crée à son tour un nouvel UTXO de 1 BTC dans le portefeuille du destinataire.

Avant d'aller plus loin, il faut retenir que pour être dépensés, les UTXO doivent être déverrouillés, puis verrouillés à nouveau, à l'aide d'un langage propre à Bitcoin, appelé « Script ».

Script est un langage de programmation qui sert à écrire les conditions de dépense d'un UTXO. Ces scripts sont exécutés lorsque les nœuds du réseau vérifient la validité d'une transaction.

Si l'on ne peut pas créer sur Bitcoin des applications aussi complexes que sur Ethereum, c'est principalement parce que Script n'est pas Turing-complet, tout comme Solidity d'ailleurs.

Solidity est souvent présenté comme un langage Turing-complet, mais dans les faits, il ne l'est pas. L'exécution d'un smart contract sur Ethereum dépend avant tout des fonds disponibles pour payer les frais de gas des transactions. Sans fonds pour couvrir ces frais, ni Ethereum ni Solidity ne peuvent être considérés comme véritablement Turing-complets.

Qu'est-ce qu'un langage de programmation Turing-complet ?

Un langage de programmation Turing-complet peut effectuer n'importe quel calcul dont une machine de Turing est capable. Il peut donc résoudre n'importe quel problème algorithmique, ce qui offre une grande flexibilité aux développeurs. Sur une blockchain, cette capacité permet de créer des smart contracts complexes, mais elle introduit aussi davantage de risques, comme des boucles infinies ou des failles imprévues, qui peuvent compromettre la sécurité du réseau.

Pour être plus précis, Script est un langage structuré en pile (stack). Des données sont placées sur la pile, et des codes opérationnels, appelés « opcodes », agissent sur ces données. Ces opcodes peuvent par exemple additionner, soustraire, dupliquer ou intervertir les éléments de la pile.

Souvent perçu comme limité face à d'autres langages de programmation, Script est en fait assez puissant, avec plus de 100 opcodes comme OP_RETURN, OP_2DUP, OP_SWAP ou OP_ADD.

Ses opcodes offrent déjà de nombreuses fonctionnalités à Bitcoin. OP_CHECKMULTISIG permet par exemple de créer des adresses contrôlées par plusieurs clés privées, et OP_CHECKSEQUENCEVERIFY impose des contraintes de temps relatives, comme les timelocks (des verrous temporels), qui ont rendu possibles le Lightning Network et les dépôts sous séquestre.

Script n'est donc pas particulièrement flexible, surtout à cause de son nombre limité d'opcodes. Au fil des années, de nombreuses propositions visant à l'enrichir de nouveaux opcodes ont toutefois été discutées.

L'ajout de nouveaux opcodes pourrait rapprocher Script de la Turing-complétude d'Ethereum et ouvrir la porte à des cas d'usage plus complexes.

Certains opcodes pourraient même permettre la création de « covenants », des mécanismes qui imposent des conditions plus précises sur la manière dont les UTXO peuvent être dépensés.

L'avenir de Bitcoin passe-t-il par les covenants ?

Qu'est-ce qu'un covenant ?

Le mot anglais « covenant » désigne un accord formel ou un engagement juridique entre 2 parties ou plus. En finance, il peut renvoyer aux conditions qu'un emprunteur doit respecter dans un contrat de prêt. Dans un registre religieux ou historique, il désigne une alliance ou un pacte sacré. On peut le traduire en français par « convention » ou « alliance ».

Sur Bitcoin, un covenant est un mécanisme qui impose des conditions précises au scriptPubKey utilisé pour verrouiller un UTXO lors de la transaction suivante. Ces conditions sont définies explicitement dans le scriptPubKey de la transaction initiale.

Concrètement, un covenant fixe les règles que devra suivre le script de verrouillage des BTC, et donc la manière dont ces BTC pourront être dépensés, à quel moment et vers quelle destination.

Il existe différents types de covenants :

• Les covenants de hachage de transaction (Transaction Hash Covenants) conditionnent le déverrouillage des UTXO à la validité d'un hash précis présent dans la transaction initiale. Les BTC ne peuvent donc être dépensés que si le hash de la transaction de dépense correspond à celui défini dans la transaction initiale. Ces covenants garantissent qu'une transaction a été créée ou signée d'une certaine manière avant d'autoriser le déverrouillage des BTC ;
• Les covenants d'introspection de transaction (Transaction Introspection Covenants) permettent de vérifier certaines propriétés internes de la transaction, comme ses entrées, ses sorties ou les montants transférés, avant d'autoriser la dépense des UTXO. Contrairement aux covenants de hachage, ils donnent un contrôle sur les composants de la transaction elle-même. Ils pourraient imposer des conditions de dépense plus complexes, par exemple sur les frais de transaction ou sur les sorties ;
• Les covenants de transformation de script (Script Transformation Covenants) modifient le script de déverrouillage des UTXO suivants ou lui imposent des conditions. Le script peut ainsi être transformé lors d'une transaction ultérieure, ce qui détermine non seulement qui peut dépenser les BTC, mais aussi la manière dont ils pourront l'être à l'avenir. Ces covenants pourraient créer des chaînes de conditions sur plusieurs transactions, chacune pouvant changer les règles de la suivante ;
• Les covenants différés (Deferred Covenants) imposent une restriction qui ne s'applique pas immédiatement, mais lors d'une transaction future. Le validateur peut alors examiner l'ensemble du script, au lieu de le parcourir étape par étape depuis le sommet de la pile. Ces covenants retardent l'application d'une condition jusqu'à un moment précis, probablement pour des raisons de confidentialité ou de complexité. Ils pourraient conditionner l'accès aux BTC à des événements ou à des critères futurs, en gardant les conditions cachées ou en suspens jusqu'à ce qu'elles soient nécessaires.

Les différents opcodes et covenants à l'étude pourraient rendre Bitcoin plus scalable, non seulement en matière de vitesse de confirmation des transactions, mais aussi de capacité de calcul et de flexibilité.

Qu'est-ce que les covenants apporteraient à Bitcoin ?

Les covenants pourraient apporter de nombreuses améliorations à Bitcoin et ouvrir la voie à de nouvelles applications, comme :

• la création de mécanismes avancés pour sécuriser ses BTC ;
• l'amélioration des performances du Lightning Network grâce à la mise en place d'Eltoo ;
• le développement de nouvelles infrastructures de layer 2 comme Ark ou les rollups ;
• la mise en place de Payment Pools, des structures proches des mixers, pour renforcer la confidentialité ;
• l'intégration directe de protocoles sur la chaîne principale, qui rendrait possibles sur Bitcoin des applications semblables à celles d'Ethereum ;
• l'amélioration des Discreet Log Contracts (DLC), qui faciliterait notamment la création de marchés de produits dérivés sur Bitcoin ;
• la création de pools de minage plus décentralisées.

Quels sont les risques liés aux covenants ?

Les covenants ne sont toutefois pas une solution sans défaut. L'ajout de nouveaux opcodes pourrait accroître les surfaces d'attaque et le risque de bugs, du fait de la complexité des scripts. Il pourrait aussi permettre la création de covenants qui limiteraient la liberté des utilisateurs dans la dépense de leurs BTC.

Ce risque tient surtout à la nature récursive de certains covenants.

Un covenant récursif est un type de smart contract qui impose des règles non seulement au scriptPubKey initial, mais aussi à tous les suivants. Si un covenant ne s'applique qu'au scriptPubKey initial, ou à une partie seulement des suivants, il n'est pas considéré comme récursif.

En clair, un covenant récursif impose des conditions de dépense à un UTXO et à toutes les transactions qui suivent. Il crée une chaîne dans laquelle chaque transaction reste soumise aux règles fixées par la transaction initiale.

Un covenant récursif trop restrictif pourrait entraîner des pertes pour le détenteur des BTC. Il pourrait aussi nuire à l'ensemble du réseau en créant différentes versions du BTC qui ne peuvent pas être dépensées de la même façon, ce qui affecterait la fongibilité du BTC et réduirait l'offre totale disponible.

De telles restrictions pourraient apparaître de plusieurs façons, à la suite d'erreurs lors de la création d'un smart contract, sous la contrainte d'une réglementation stricte qui interdirait aux entreprises régulées d'envoyer des BTC vers des adresses sur liste noire, ou encore par choix délibéré de l'utilisateur.

Empêcher la dépense de bitcoins vers des adresses sur liste noire, par exemple dès leur sortie des plateformes d'échange, est d'ailleurs déjà possible par la voie d'une réglementation stricte. Cela peut passer par des portefeuilles multisig dont une plateforme régulée détient au moins 1 clé, par exemple dans un portefeuille multisig 2/2, et qui aurait l'interdiction de confirmer les transactions envoyant des BTC vers des adresses non conformes à la réglementation.

À l'image de ceux qui ont adopté la hiérarchie des satoshis issue de la théorie des Ordinals, qui n'existe pas réellement sur le réseau Bitcoin lui-même, certains utilisateurs pourraient créer un covenant « Ordinals » rendant impossible le mélange de satoshis rares avec les autres.

Dans la plupart des cas, l'utilisateur ordinaire garde toutefois le contrôle de ses BTC. Seul le propriétaire peut décider d'utiliser un covenant récursif, et donc de compromettre éventuellement la fongibilité de ses propres BTC.

Plusieurs développeurs Bitcoin soulignent d'ailleurs qu'une censure, comme celle que pourrait imposer un gouvernement, est déjà possible, et que les covenants ne la rendraient pas forcément plus facile à mettre en place.

Lors d'une interview avec Nik Bhatia pour The Bitcoin Layer, le développeur Andrew Poelstra a ainsi souligné que de tels projets se heurteraient à une forte opposition sociale, puisque les utilisateurs devraient mettre à jour leurs portefeuilles pour reconnaître ces BTC restreints.

Il a également évoqué des obstacles économiques, car les opcodes nécessaires à ces covenants rendraient les transactions en BTC plus lourdes, et donc plus chères en frais de transaction. S'y ajoutent des difficultés techniques, liées à la complexité de création de tels covenants.

Parmi les nombreux opcodes envisagés, 2 se distinguent par leur simplicité et leurs capacités techniques, OP_CAT et OP_CHECKTEMPLATEVERIFY.

OP_CAT, l'opcode polyvalent

OP_CAT est un opcode qui pourrait rendre Script, le langage de programmation de Bitcoin, beaucoup plus flexible et ouvrir la voie à de nombreux nouveaux cas d'usage.

Techniquement, OP_CAT sert à concaténer les 2 éléments situés au sommet de la pile du script. La concaténation consiste à mettre bout à bout 2 données pour former 1 seule séquence au lieu de 2 éléments distincts, ce qui réduit la complexité du script.

Cette opération peut sembler simple, mais elle augmente nettement l'expressivité de Script et permet de créer des structures de données plus complexes directement dans les transactions Bitcoin.

Elle permettrait par exemple d'effectuer une multiplication (3 x 4), qui exige sinon une série d'additions successives (3 + 3 + 3 + 3) sans OP_CAT.

OP_CAT rend ainsi possibles des scripts plus sophistiqués, dont les covenants de hachage et d'introspection de transaction. Il pourrait notamment permettre :

• la création de Vaults, des coffres-forts qui renforcent la sécurité des BTC ;
• le développement de smart contracts aussi Turing-complets que ceux d'Ethereum ;
• la mise en place d'Eltoo pour améliorer le Lightning Network ;
• la création d'Ark, un layer 2 de Bitcoin dédié aux transferts de BTC ;
• l'optimisation de BitVM, un paradigme de calcul qui rend possibles les rollups ;
• le développement de nombreuses solutions de layer 2 qui profiteraient réellement de la sécurité de Bitcoin.

OP_CAT faisait partie de Script à la création de Bitcoin, mais il a rapidement été désactivé, en 2010, par Satoshi Nakamoto lui-même. La principale raison de ce retrait était le risque de spam sur le réseau, qui aurait pu compromettre sa sécurité.

OP_CAT n'avait en effet aucune limite de taille, ce qui aurait pu submerger les nœuds en congestionnant la mempool et en faisant grossir la blockchain de manière exponentielle. Ethereum a tenté de résoudre un problème similaire avec son langage Solidity, sans grand succès, puisque son adoption dépend aujourd'hui de ses solutions de layer 2.

Pourquoi envisager de réintroduire OP_CAT dans Script s'il risque de surcharger les nœuds Bitcoin et de réduire la décentralisation à long terme ?

Tout simplement parce que l'introduction de Tapscript en 2021, lors de la mise à jour Taproot, a réduit ce risque en imposant une limite de 520 octets aux éléments de la pile. OP_CAT peut donc être réintégré à Script en toute sécurité, sans compromettre la décentralisation de Bitcoin.

Sa réactivation répond à la volonté d'ajouter des fonctionnalités plus puissantes et plus flexibles au script de Bitcoin, sans toucher aux fondamentaux du réseau ni affecter les utilisateurs que ces fonctionnalités n'intéressent pas.

L'intégration d'OP_CAT pourrait toutefois permettre la création de différents covenants, y compris récursifs, ce qui augmenterait les surfaces d'attaque.

Cet opcode pourrait transformer la manière dont les scripts sont écrits et utilisés, mais il fait aussi peser sur Bitcoin des risques importants, qui doivent être évalués avec soin. Plusieurs développeurs Bitcoin estiment néanmoins que ces risques sont surestimés.

Si OP_CAT devait être réintroduit, cela pourrait se faire d'ici 1 à 5 ans, au terme de longues discussions, de tests rigoureux et d'un vote de la communauté.

OP_CAT est considéré comme le moyen le plus simple et le plus complet d'apporter de la flexibilité à Bitcoin. Si sa réintroduction ne se concrétise pas, d'autres opcodes, moins flexibles pris individuellement, pourraient être ajoutés, à moins qu'OP_CAT ne revienne aux côtés d'autres opcodes.

OP_CHECKTEMPLATEVERIFY (OP_CTV), l'opcode simple mais limité

OP_CHECKTEMPLATEVERIFY, aussi appelé « OP_CTV », est un opcode proposé par Jeremy Rubin en 2019 dans le cadre du BIP 119.

Cet opcode permet de créer des covenants basés sur le hash d'une transaction. Il introduirait sur Bitcoin des covenants non récursifs, capables de définir à l'avance la manière dont la transaction suivante doit être construite.

L'idée d'OP_CTV est née du besoin de rendre les transactions Bitcoin plus sûres et plus efficaces, notamment pour des applications comme les Vaults, les canaux de paiement du Lightning Network, le contrôle de la congestion des transactions, l'amélioration des DLC et la création du layer 2 Ark.

En pratique, une transaction qui utilise OP_CHECKTEMPLATEVERIFY doit placer sur la pile un hash de 32 octets, appelé « commitment hash », qui représente le hash de la transaction suivante. Ce hash engage la structure future de la transaction, y compris la répartition des fonds entre 2 parties ou plus.

Si les parties décident de modifier cette répartition, un nouveau commitment hash est généré pour refléter la nouvelle allocation. OP_CTV permet ainsi de mettre à jour ce hash dans le script, mais seulement si toutes les parties concernées acceptent les nouvelles conditions.

Cette mise à jour garantit que la dépense de l'UTXO respecte les conditions prédéfinies et acceptées par tous les participants. Elle maintient un contrôle strict sur l'évolution des transactions, tout en permettant de modifier la répartition des BTC de manière sûre et consensuelle, même lorsque les conditions changent.

Le code d'OP_CHECKTEMPLATEVERIFY est particulièrement simple comparé à OP_CAT, et il est prêt depuis plusieurs années.

Voici les principales différences entre OP_CTV et OP_CAT :

• Flexibilité : OP_CTV est moins flexible qu'OP_CAT, mais aussi plus prévisible, ce qui réduit les risques de failles lors de son utilisation ;
• Applications possibles : OP_CTV se prête bien au développement de plusieurs applications, tandis qu'OP_CAT permet des applications plus sophistiquées, dont des scripts complexes et des layer 2 comme les rollups ;
• Risque de surcharge : OP_CTV a été conçu pour limiter son impact sur le réseau Bitcoin en restant cantonné à des fonctions limitées, alors qu'OP_CAT exige des précautions supplémentaires pour éviter de surcharger le réseau ;
• Adoption et mise en œuvre : OP_CTV bénéficie d'un soutien important dans la communauté Bitcoin, et sa simplicité pourrait accélérer son adoption ;
• Évolution future : OP_CTV peut répondre à la plupart des besoins actuels des développeurs Bitcoin sans complexifier le protocole à l'excès, tandis qu'OP_CAT offre un potentiel d'évolution plus important.

OP_CTV présente toutefois une limite majeure, soulignée par Peter Todd il y a quelques mois. Selon lui, CheckTemplateVerify (CTV) ne résout pas vraiment les problèmes de scalabilité de Bitcoin, car chaque utilisateur doit disposer d'un UTXO pour payer les frais de transaction, ce qui annule les avantages du partage d'UTXO.

CTV permet en effet de partager un UTXO entre plusieurs personnes, mais son utilisation suppose de posséder un UTXO supplémentaire pour couvrir les frais, ce qui ne répond pas aux défis de scalabilité du Lightning Network.

En revanche, le caractère non récursif d'OP_CHECKTEMPLATEVERIFY lui donne un potentiel d'adoption important face à OP_CAT. Comme expliqué plus haut, la récursivité pourrait permettre à des acteurs malveillants ou à des bugs de développement d'affecter la fongibilité du BTC, voire de rendre possible une forme de censure.

Une telle censure pourrait être mise en place presque aussi facilement par d'autres moyens, et de nombreux développeurs Bitcoin jugent exagérés les risques d'exploitation de cet outil. OP_CAT introduirait malgré tout une nouvelle surface d'attaque contre la souveraineté des utilisateurs.

La flexibilité d'OP_CTV et son impact plus faible sur la blockchain Bitcoin lui donnent donc un avantage important dans les débats de la communauté. Rien n'empêche toutefois d'ajouter les 2 opcodes à Script en même temps.

Les autres opcodes proposés pour permettre les covenants sur Bitcoin

Les propositions d'opcodes destinés à créer différents types de covenants sont nombreuses. Voici une brève description de celles qui ont le plus retenu l'attention de la communauté Bitcoin.

ANYPREVOUT (APO)

SIGHASH_ANYPREVOUT (APO), proposé dans le BIP-118, est une évolution du concept SIGHASH_NOINPUT qui permet de signer une transaction sans faire référence à un UTXO précis en entrée. Cette flexibilité permet de financer plus tard une transaction pré-signée avec différents UTXO, tant que les scripts sont compatibles.

APO est particulièrement utile pour des applications comme Eltoo, qui améliore la gestion des canaux du Lightning Network, et peut aussi servir à des mécanismes comme les Statechains et les Spacechains. Il pose toutefois des défis de sécurité et de complexité, qui exigent une mise en œuvre prudente.

Vaults

OP_VAULT est une proposition qui introduit 2 nouveaux opcodes dans Tapscript, OP_VAULT et OP_VAULT_RECOVER, spécifiés dans le BIP-345.

Combinés à OP_CHECKTEMPLATEVERIFY (CTV), ces opcodes imposent un délai avant que des BTC puissent être dépensés vers une destination arbitraire, sauf s'ils sont envoyés via un chemin de récupération défini à l'avance.

Avant la dépense finale, les BTC peuvent encore être redirigés vers ce chemin de récupération. OP_VAULT vise ainsi à renforcer la sécurité des BTC en offrant une protection supplémentaire contre le vol, puisque l'utilisateur peut intervenir en cas de tentative de vol.

Les opcodes TXHASH et CHECKSIGFROMSTACKVERIFY

Les opcodes TXHASH et CHECKSIGFROMSTACKVERIFY ont été proposés pour décomposer et reproduire les fonctionnalités de CTV et d'ANYPREVOUT de manière plus flexible et plus modulaire. Ensemble, ils pourraient en substance remplacer toutes les autres propositions de covenants.

Plus précisément, TXHASH génère des hash de transaction à partir de paramètres précis, tandis que CHECKSIGFROMSTACKVERIFY vérifie des signatures à partir de ces hash.

ANYPREVOUT peut simuler CTV, mais pour un coût plus élevé. TXHASH et CHECKSIGFROMSTACKVERIFY offrent une alternative qui permet de construire des covenants et d'autres applications avec un ensemble d'opcodes plus simple et plus adaptable, au prix d'une consommation d'espace plus importante.

Quand les covenants arriveront-ils sur Bitcoin ?

Les développeurs et la communauté de Bitcoin sont connus pour prendre plusieurs années avant de déployer une mise à jour. Au cours de son histoire, Bitcoin n'a connu que 2 mises à jour majeures, SegWit et Taproot, contrairement à d'autres blockchains qui font évoluer leurs règles de consensus plus régulièrement.

Pour certains, cette lenteur est un défaut qui empêche Bitcoin de passer à l'échelle plus rapidement. D'autres y voient au contraire une prudence bénéfique, qui laisse à toute la communauté le temps de se forger une opinion éclairée tout en protégeant le réseau contre d'éventuelles attaques.

Imaginons que quelqu'un parvienne à convaincre des membres influents de la communauté de faire passer l'offre totale de BTC de 21 millions à 42 millions. Si les mises à jour étaient déployées rapidement, développeurs, influenceurs et membres de la communauté pourraient accepter ce changement sans avoir eu le temps de le tester techniquement sur un testnet, ni d'évaluer les conséquences d'une telle modification.

L'intégration d'un opcode déjà proposé pourrait donc encore prendre plusieurs années. C'est pourquoi il est essentiel d'approfondir le sujet et de réunir un maximum d'informations sur les risques et les complications que de tels changements pourraient entraîner.

Sources : Covenants, Bitcoin Wiki, Dictionnaire de Bitcoin

Cet article a d'abord été publié en français sur Cryptoast le 24 août 2024.