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 ?

Au sein de la communauté des cryptomonnaies, la blockchain Bitcoin est réputée pour être un réseau lent, coûteux à utiliser, ainsi que disposant d'une faible capacité de calcul rendant la création de smart contracts plus complexe qu'avec d'autres blockchains.

Cependant, sa lenteur, son petit espace de bloc et sa faible capacité de calcul sont des caractéristiques qui permettent à Bitcoin d'être le réseau le plus sécurisé, décentralisé et résistant à la censure qui existe. Augmenter la taille de ses blocs, par exemple, ferait augmenter la taille de la blockchain trop rapidement faisant augmenter les coûts de maintenance d'un nœud trop rapidement.

👉 Retrouvez notre guide pour acheter du Bitcoin facilement

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

C'est sur cette loi, la loi de Moore, que la décentralisation des blockchains se base. Elle explique notamment le trilemme de la blockchain, qui affirme qu'une blockchain qui veut être scalable doit faire des compromis sur sa sécurité et sa décentralisation.

⛓️Qu’est-ce que le trilemme des blockchains et pourquoi les altcoins essaient tous de le résoudre ?

En comparaison, Ethereum est plus scalable que Bitcoin, mais la taille de sa blockchain augmente très rapidement, un effet qui centralise son réseau au fil du temps. De manière similaire, le réseau Kaspa est plus scalable que Bitcoin, a également le potentiel de devenir plus décentralisé, mais fait un compromis sur la sécurité en utilisant des nœuds « élagués ».

Pour rendre Bitcoin plus rapide, de nombreux types d'infrastructures ont été imaginées :

• Les sidechains, des chaînes alternatives fonctionnant étroitement avec Bitcoin sans réellement en dépendre ni bénéficier de sa sécurité, comme la blockchain Liquid (L-BTC) ou Stacks (STX) ;
• Les layer 2, des infrastructures qui réalisent les calculs en dehors du réseau principal pour finalement y inscrire seulement une empreinte, comme BitVM et RGB qui sont encore en construction ;
• Le Lightning Network, un réseau de canaux de liquidités permettant des transferts de BTC quasiment instantanés et à moindres frais.

Parmi toutes les solutions envisagées, il y a aussi des modifications de la blockchain Bitcoin en elle-même, comme les mises à jour Segwit, effectuée en 2017 et Taproot, implémentée depuis 2021.

Plus récemment, le sujet des « covenants » gagne en visibilité, suscitant de nombreux débats autour d'une potentielle mise à jour et d'un nouveau soft fork de Bitcoin.

Avant d’entrer dans le vif du sujet, il est nécessaire de comprendre le fonctionnement du 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 bien différent de celui utilisé par les blockchains utilisant la machine virtuelle d'Ethereum (EVM).

En effet, alors que ces blockchains mélangent les mêmes tokens reçus par une adresse, Bitcoin va quant à lui enregistrer chaque arrivée de BTC sur une adresse comme une sortie de transaction (output) et chaque envoi vers une adresse extérieure comme une entrée de transaction (input) bien distincte de la somme totale détenue par le portefeuille.

Ainsi, les unités de BTC que nous possédons dans notre portefeuille Bitcoin sont en réalité gardées sous forme de sorties non dépensées, appelées « Unspent Transaction Output » en anglais, souvent abrégé « UTXO ».

Ces UTXO fonctionnent un peu à la manière d'un billet ou d'une pièce de monnaie, mais de manière numérique. Par exemple, si vous recevez 1 Bitcoin, alors vous aurez en votre possession 1 UTXO d'une valeur de 1 BTC. Une fois dépensé, votre UTXO de 1 BTC est consommé en input de la transaction, et permet de créer en contrepartie un nouvel UTXO de 1 BTC dans le portefeuille qui reçoit les fonds.

🪙 En savoir plus sur le fonctionnement des UTXO de Bitcoin

Avant d'aller plus loin, il est important de comprendre que pour que des UTXO soient dépensés, ils doivent être déverrouillés puis verrouillés par un langage propre à Bitcoin, appelé « Script ».

Le langage de programmation Script est littéralement un script qui vient spécifier les conditions de dépenses d'un UTXO. Et ce sont ces scripts qui sont exécutés lors de la vérification de la validité d'une transaction par les nœuds du réseau.

La principale raison pour laquelle il est impossible de créer des applications sur Bitcoin aussi complexes que celles sur Ethereum vient du fait que le langage Script n'est pas Turing-complet, tout comme Solidity d'ailleurs.

Bien que Solidity soit souvent présenté comme Turing-complet, en réalité, il ne l'est pas vraiment. L'exécution d'un smart contract sur Ethereum dépend principalement de la disponibilité de frais de gas pour payer les transactions. Sans fonds pour couvrir ces frais, ni Ethereum ni Solidity ne peuvent être considérés comme Turing-complets.

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

Un langage de programmation Turing-complet est un langage capable de réaliser tout type de calcul qu'une machine de Turing pourrait effectuer, ce qui signifie qu'il peut résoudre n'importe quel problème algorithmique, offrant ainsi une grande flexibilité dans la programmation. Dans le contexte des blockchains, cette capacité permet la création de smart contracts complexes, mais elle introduit également des risques accrus, tels que des boucles infinies ou des vulnérabilités imprévues, qui peuvent compromettre la sécurité du système.

Pour être plus précis, le langage Script de Bitcoin est construit comme une pile, ou « stack » en anglais. Les données sont placées sur la pile et des codes opératoires, appelés aussi « opcodes » agissent sur ces données, ils peuvent entre autres additionner, soustraire, dupliquer, ou encore échanger les données de la pile.

Bien qu'il est perçu comme limité en comparaison à d'autres langages, Script est en réalité très riche et dispose de plus d'une centaine d'opcodes, tels que OP_RETURN, OP_2DUP, OP_SWAP, OP_ADD, etc.

De plus, les opcodes du langage Script permettent dès aujourd'hui de créer de nombreuses choses pour Bitcoin, tels que OP_CHECKMULTISIG qui permet les adresses gérées par plusieurs clés privées, OP_CHECKSEQUENCEVERIFY qui impose une contrainte de temps relative, le timelock, permettent notamment la création du Lightning Network et de dépôts fiduciaires (escrow).

Vous l'avez compris, le langage Script n'est pas très flexible, principalement parce que ses opcodes sont limités. En revanche, de nombreuses propositions d'ajouts d’opcodes à Script sont envisagées depuis plusieurs années.

Les ajouts d’opcodes envisagés par la communauté pourraient rapprocher Bitcoin et son langage de programmation Script de la Turing-complétude d'Ethereum, ouvrant ainsi la voie à des cas d'utilisation plus complexes.

Certains opcodes permettraient même de créer des « covenants », des mécanismes qui imposent des conditions de dépenses des UTXO plus spécifiques.

L'avenir de Bitcoin se trouve-t-il dans les covenants ?

Que sont les covenants ?

Le mot anglais « covenant » désigne un accord formel ou un engagement juridique entre 2 ou plusieurs parties. En finance, il peut s'agir de conditions que les emprunteurs doivent respecter dans un contrat de prêt. Dans un contexte religieux ou historique, il peut se référer à une alliance ou un pacte sacré. Il peut se traduire en français par « convention » ou « alliance ».

Dans le cas de Bitcoin, un covenant est un mécanisme qui impose des conditions spécifiques sur le scriptPubKey utilisé pour verrouiller un UTXO dans la transaction suivante, ces conditions étant spécifiquement définies dans le scriptPubKey de la transaction initiale.

En d’autres termes, un covenant précise les règles que doit suivre le script de verrouillage des BTC, dictant comment, quand et où ces BTC peuvent être dépensés.

Il existe différents types de covenants :

• Les covenants de hash de transaction : Ce type de covenant permet de conditionner le déblocage des UTXO en fonction de la validité d'un hash spécifique présent dans la transaction initiale. Cela signifie que les BTC ne peuvent être dépensés que si le hash de la transaction de dépense respecte le hash défini dans la transaction initiale. Les covenants de hash de transaction permettraient de s'assurer qu'une transaction particulière a été créée ou signée d'une manière spécifique avant de permettre le déverrouillage des BTC ;
• Les covenants d'introspection de transaction : Ce type de covenant permet de vérifier certaines propriétés internes de la transaction, comme ses entrées, sorties, ou même les montants transférés, avant de permettre la dépense des UTXO. Contrairement aux covenants de hash de transaction, ils offrent un contrôle sur les composants de la transaction elle-même. Les covenants d'introspection de transaction permettraient d'imposer des conditions de dépense plus complexes, pouvant s'appliquer sur les frais ou les sorties de la transaction par exemple ;
• Les covenants de transformation du script : Ce type de covenant modifie ou impose des conditions sur le script de déverrouillage des UTXO suivants. Il permet de transformer le script dans une transaction ultérieure, conditionnant ainsi non seulement qui peut dépenser les BTC, mais également comment ils peuvent être dépensés dans le futur. Les covenants de transformation du script permettraient de créer des chaînes de conditions sur plusieurs transactions, où chaque transaction pourrait changer les règles de la suivante ;
• Les covenants différés : Ce type de covenant impose une restriction qui n'est pas immédiatement appliquée, mais qui le sera dans une transaction future. Ils permettent au validateur de regarder l'ensemble du script plutôt qu'étape par étape en commençant par le haut de la pile. Ce type de covenant permet de différer l'application d'une condition jusqu'à un moment précis, probablement pour des raisons de confidentialité ou de complexité. Les covenants différés permettraient de conditionner l'accès aux BTC en fonction d'événements ou de 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 envisagés pourraient rendre Bitcoin plus scalable, non seulement en termes de rapidité de confirmation des transactions, mais également en termes de capacité et de flexibilité de calcul.

Qu'apportent les covenants à Bitcoin ?

Les covenants pourraient apporter de nombreuses améliorations à Bitcoin et ouvrir la voie au développement de nouvelles applications, telles que :

• La création de mécanismes avancés pour sécuriser les BTC;
• L'amélioration des performances du Lightning Network grâce à l'implémentation d'Eltoo ;
• Le développement de nouvelles infrastructures de layer 2 comme Ark ou des rollups ;
• La mise en place de Payment Pools, structures similaires aux mixeurs, pour renforcer la confidentialité ;
• L'intégration directe de protocoles sur la chaîne principale, permettant des applications comparables à celles d'Ethereum sur Bitcoin ;
• L'amélioration des Discreet Log Contracts (DLC), facilitant notamment la création de marchés dérivés sur Bitcoin ;
• La création de pools de minage plus décentralisés.

Quels sont les risques portés par les covenants ?

En revanche, les covenants ne sont pas une solution sans faille. En effet, l'implémentation de nouveaux opcodes pourrait non seulement accroître les surfaces d'attaque et les possibilités de bugs en raison de la complexité des scripts, mais également permettre la création de covenants qui limitent la liberté des utilisateurs dans l'utilisation de leurs BTC.

Cela est principalement dû à 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 ceux qui le suivent. Si un covenant ne s'applique pas à tous les scriptPubKey suivants ou seulement à certains, il n'est pas considéré comme récursif.

En d'autres termes, un covenant récursif est un smart contract qui impose des conditions de dépense à un UTXO, ainsi qu'à toutes les transactions suivantes, créant une chaîne où chaque transaction est soumise aux règles établies lors de la transaction initiale.

Un covenant récursif trop restrictif pourrait causer des pertes pour le propriétaire des BTC, nuire à l'ensemble du réseau en créant différentes versions de la cryptomonnaie BTC, qui ne pourraient pas être dépensées de la même manière, affectant ainsi la fongibilité des BTC et réduisant l'offre totale disponible.

De telles restrictions pourraient être mises en place de diverses manières : par erreur lors de la création d'un smart contract, par contrainte si une réglementation stricte empêchait la dépense des BTC provenant d'entreprises réglementées vers des adresses blacklistées, ou encore par choix délibéré de l'utilisateur.

À titre indicatif, interdire la dépense de Bitcoins vers des adresses blacklistées, dès leurs sorties des plateformes d'échange par exemple, est déjà imposable par une réglementation stricte avec la création de multisig, où une plateforme régulée garderait au moins une clé, d'un portefeuille multisig 2/2 par exemple, et aurait interdiction de confirmer une transaction transférant les BTC à une adresse non conforme aux réglementations.

À l'instar de ceux qui ont adopté la hiérarchie des satoshis de la théorie Ordinals (qui n'existe pourtant pas sur le réseau Bitcoin en lui-même), ces utilisateurs pourraient créer un covenant « Ordinals » rendant impossible le mélange des satoshis rares avec d'autres.

Cependant, il est important de rappeler que, dans la plupart des cas, l'utilisateur ordinaire conserve le contrôle sur ses BTC, et seul le propriétaire peut décider d'utiliser un covenant récursif et ainsi potentiellement compromettre la fongibilité de ses BTC.

Plusieurs développeurs Bitcoin rappellent que la censure, comme celle imposée par des gouvernements, est déjà possible et que les covenants ne faciliteraient pas nécessairement sa mise en place.

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

Il a également mentionné des obstacles économiques, car l'ajout d'opcodes pour créer ces covenants rendrait les transactions de BTC plus volumineuses et donc plus coûteuses en frais de transaction, ainsi que des défis techniques liés à la complexité de la création de tels covenants.

Parmi les nombreux opcodes envisagés, deux se distinguent particulièrement par leur simplicité et leurs capacités techniques : OP_CAT et OP_CHECKTEMPLATEVERIFY.

OP_CAT, l'opcode à tout faire

OP_CAT est un opcode qui pourrait permettre à Script, le langage de programmation de Bitcoin, de devenir bien plus flexible et ouvrir la voie à de nombreux nouveaux cas d'utilisation.

Techniquement, OP_CAT est conçu pour concaténer 2 éléments situés en haut de la pile du script. La concaténation consiste à assembler 2 données en les reliant bout à bout, formant ainsi une seule séquence de données au lieu de 2 distinctes, ce qui réduit la complexité du script.

Bien que cette opération semble simple, elle accroît considérablement l'expressivité du langage de Script, permettant de créer des structures de données plus complexes directement au sein des transactions Bitcoin.

Par exemple, elle permettrait d'effectuer des opérations telles que la multiplication (3 x 4), qui nécessiteraient autrement une série d'additions successives (3 + 3 + 3 + 3) sans OP_CAT.

Ainsi, OP_CAT rend possible la mise en place de scripts plus sophistiqués dont des covenants de hash de transaction et d'introspection de transaction. Par exemple, il pourrait permettre :

• la création de Vaults, des systèmes augmentant la sécurité des BTC ;
• la création de smart contracts aussi Turing-complets que sur Ethereum ;
• l'implémentation de Eltoo pour améliorer le Lightning Network ;
• la création de Ark, un layer 2 de Bitcoin dédié au transfert de BTC ;
• l'optimisation de BitVM, un paradigme de calcul permettant la création de rollups ;
• ou encore la création de nombreux layer 2 bénéficiant réellement de la sécurité de Bitcoin.

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

En effet, OP_CAT n'avait pas de limite de taille, ce qui pouvait potentiellement surcharger les nœuds en congestionnant la mempool et augmenter la taille de la blockchain de manière exponentielle. Ethereum a essayé de résoudre un problème similaire avec son langage Solidity, sans grand succès, l'adoption d'Ethereum dépend désormais de ses layer 2.

Alors, pourquoi réintégrer OP_CAT dans le langage Script si cela risque de surcharger les nœuds Bitcoin et de réduire sa décentralisation à long terme ?

Tout simplement parce que l'introduction de Tapscript en 2021 lors de la mise à jour Taproot a permis de mitiger ce risque en imposant une limite de 520 octets sur la taille des éléments de la pile. Ainsi, OP_CAT peut être réintégré dans le langage Script sans compromettre la décentralisation de Bitcoin.

La réactivation d'OP_CAT est motivée par le désir d'ajouter des fonctionnalités plus puissantes et flexibles au script de Bitcoin, sans altérer les fondamentaux du réseau ni impacter les utilisateurs qui ne s'y intéressent pas.

Toutefois, l'intégration d'OP_CAT permettrait de créer divers covenants, y compris des covenants récursifs, ce qui augmenterait les surfaces d'attaque.

Bien que cet opcode puisse potentiellement transformer la manière dont les scripts sont rédigés et utilisés, il présente des risques significatifs pour Bitcoin qui doivent être soigneusement évalués. Plusieurs développeurs de Bitcoin estiment néanmoins que ces risques sont surestimés.

Si OP_CAT devait être réintroduit, cela pourrait se faire dans un délai de 1 à 5 ans, après des discussions approfondies, des tests rigoureux, et un vote de la communauté.

Enfin, OP_CAT est considéré comme le moyen le plus simple et complet d'ajouter de la flexibilité à Bitcoin, mais si sa réintroduction ne se concrétise pas, d'autres opcodes, offrant individuellement moins de flexibilité, pourraient être ajoutés, ou OP_CAT pourrait être réintroduit en même temps que 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.

📜 Pour aller plus loin – Qu'est-ce qu'un BIP ou Bitcoin Improvement Proposal ?

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

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

En pratique, une transaction utilisant OP_CHECKTEMPLATEVERIFY doit inclure un hash de 32 octets sur la pile, appelé « hash d'engagement » ou « commitment hash » en anglais, qui représente le hash de la transaction suivante. Ce hash engage la structure future de la transaction, incluant notamment la répartition des fonds entre 2 parties ou plus.

Si les parties décident de modifier cette répartition, un nouveau hash d'engagement est généré pour refléter la nouvelle distribution. OP_CTV permet donc de mettre à jour ce hash dans le script, mais seulement si toutes les parties concernées sont d'accord sur les nouvelles conditions.

Cette mise à jour garantit que la dépense de l'UTXO respecte les conditions prédéfinies et validées par l'ensemble des participants, tout en assurant un contrôle strict sur l'évolution des transactions et permettant des modifications sécurisées et consensuelles de la distribution des BTC, même si ces conditions évoluent.

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

Voici les principales différences entre OP_CTV et OP_CAT :

• Flexibilité : OP_CTV est moins flexible, mais également plus prévisible que OP_CAT réduisant les risques de failles dans son utilisation ;
• Applications potentielles : OP_CTV est idéal pour le développement de plusieurs applications, mais OP_CAT permet de créer des applications plus sophistiquées notamment par la création de scripts complexes, et de layer 2 comme des rollups ;
• Risques de surcharge : OP_CTV a été conçu pour minimiser l'impact sur le réseau Bitcoin en restant limité dans ses fonctions, tandis que OP_CAT nécessite des précautions supplémentaires pour éviter la surcharge du réseau ;
• Adoption et implémentation : OP_CTV bénéficie d'un soutien important de la communauté Bitcoin permettant une potentielle adoption plus rapide en raison de sa simplicité ;
• Évolution future : OP_CTV peut satisfaire la majorité des besoins actuels des développeurs Bitcoin sans trop complexifier le système, tandis que OP_CAT offrirait un potentiel d'évolution plus grand.

OP_CTV présente tout de même une limitation importante, relevée par Peter Todd il y a quelques mois. Il souligne que l'implémentation de CheckTemplateVerify (CTV) ne résout pas vraiment les problèmes de scalabilité de Bitcoin, car elle exige que chaque utilisateur dispose d'un UTXO pour payer les frais, ce qui annule les avantages du partage d'UTXO.

En effet, bien que CTV permette de partager un UTXO entre différentes personnes, son utilisation nécessite la possession d'un UTXO supplémentaire pour payer les frais de transaction, ce qui ne résout pas le problème de scalabilité auquel le Lightning Network est confronté pour passer à l'échelle.

En revanche, le fait que OP_CHECKTEMPLATEVERIFY ne soit pas récursif lui offre un potentiel d'adoption important comparé à OP_CAT. Comme expliqué plus tôt, la récursivité permettrait à des entités malveillantes ou à des bugs de développement de toucher à la fongibilité des BTC, pouvant même servir de censure.

Bien que cette censure puisse être instaurée par d'autres moyens presque aussi simplement et que plusieurs développeurs Bitcoin jugent que l'exploitation de cet outil est surestimée, OP_CAT introduirait tout de même une nouvelle surface d'attaque contre la souveraineté des utilisateurs.

La flexibilité et l'impact plus faible sur la blockchain Bitcoin donnent à OP_CTV un avantage considérable dans les débats au sein de la communauté. Rappelons tout de même que ces 2 opcodes peuvent être ajoutés à Script en même temps.

Les autres propositions d'opcodes permettant des covenants sur Bitcoin

Il existe de nombreuses propositions d'ajouts d'opcodes pour créer différents covenants. Voici une brève description des propositions les plus suivies par la communauté Bitcoin.

ANYPREVOUT (APO)

SIGHASH_ANYPREVOUT (APO), proposé dans le BIP-118, est une mise à jour du concept SIGHASH_NOINPUT qui permet de signer une transaction sans référencer un UTXO spécifique en input. Cette flexibilité permet à une transaction présignée d'être financée ultérieurement par différents UTXO, à condition que les scripts soient compatibles.

APO est particulièrement utile pour des applications comme Eltoo, qui améliore la gestion des canaux Lightning Network, et peut aussi être utilisé pour des mécanismes comme les Statechains et Spacechains. Cependant, APO présente des défis en termes de sécurité et de complexité, nécessitant une gestion prudente lors de son implémentation.

Les 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.

Ces opcodes, en combinaison avec OP_CHECKTEMPLATEVERIFY (CTV), permettent d'imposer un délai avant que les BTC puissent être dépensés vers une destination arbitraire, sauf s'ils sont envoyés via un chemin de récupération pré-spécifié.

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

Les opcodes TXHASH et CHECKSIGFROMSTACKVERIFY

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

Plus précisément, TXHASH permet de générer des hashs de transactions basés sur des paramètres spécifiques, tandis que CHECKSIGFROMSTACKVERIFY vérifie les signatures à partir de ces hashs.

Bien que ANYPREVOUT puisse simuler CTV, il le fait à un coût plus élevé. TXHASH et CHECKSIGFROMSTACKVERIFY offrent une alternative permettant de construire des covenants et d'autres applications avec un ensemble plus simple et adaptable d'opcodes, bien qu'ils consomment plus d'espace.

Quand les Covenants arriveront-ils sur Bitcoin ?

Les développeurs et la communauté Bitcoin sont réputés pour prendre plusieurs années avant de mettre en œuvre des mises à 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 les règles de consensus plus régulièrement.

Certains estiment que cette lenteur est un défaut, car elle empêche Bitcoin de passer à l'échelle plus rapidement. D'autres, en revanche, considèrent que cette lenteur est bénéfique, permettant à toute la communauté de prendre le temps de se forger un avis éclairé, tout en protégeant le réseau contre d'éventuelles attaques.

Par exemple, si un individu parvenait à persuader des membres influents de la communauté d'augmenter la limite totale de BTC en circulation à 42 millions au lieu de 21, et que les mises à jour se faisaient rapidement, les développeurs, influenceurs et membres de la communauté pourraient accepter ce changement sans avoir eu le temps de réaliser des tests techniques sur un testnet ni de mesurer les implications d'une telle modification.

Ainsi, l'implémentation d'un opcode précédemment présenté pourrait encore prendre plusieurs années. C'est pourquoi il est crucial d'approfondir le sujet et de se renseigner au maximum sur les risques et les complications potentiels liés à de tels changements.

Sources : Covenants, Bitcoin Wiki, Dictionnaire de Bitcoin

D'abord attiré par l'appât du gain, je suis maintenant piégé deep into the rabbit hole. Sans porte de sortie, je n'ai plus qu'à partager mes connaissances et transmettre la passion que j'ai pour Bitcoin. Je suis également le créateur d'Adopt a Block, un site éducatif dédié à Bitcoin.

Marius Farashi Tasooji

302 articles

Tous ses articles