Il veut modifier Bitcoin radicalement : La mise à jour qui fait polémique

Le 19 avril dernier, le développeur Jeremy Rubin a dévoilé les paramètres d’activation pour une mise à niveau de Bitcoin appelée OP_CTV. Le problème est que cette mise à niveau n’avait pas été suffisamment discutée et que cette activation, reposant sur le signalement des mineurs, ressemblait à un passage en force, ce qui n’a pas manqué de créer la polémique. Revenons sur cette controverse qui a affecté la communauté ces dernières semaines.

Qu’est-ce que OP_CHECKTEMPLATEVERIFY ?

On ne le répète peut-être jamais assez : Bitcoin est un système de monnaie programmable. Si sa machine virtuelle est plus restreinte que celle d’Ethereum, elle permet tout de même d’exécuter une grande variété de smart contracts, qu’on appelle des scripts. Ces scripts sont écrits grâce à un langage composé de plus d’une centaine de codes opération (opcodes).

Néanmoins, contrairement à Ethereum, le langage de script de Bitcoin est limité (à dessein), interdisant à l’utilisateur de réaliser des choses jugées trop complexes comme les boucles. En particulier, il est impossible de mettre en place des covenants, qui imposent des restrictions sur les transactions futures.

Un covenant (terme qu’on peut traduire en français par « pacte » ou « convention ») est un mécanisme permettant de faire appliquer des conditions sur la manière dont une pièce (UTXO) peut être utilisée par la suite, comme par exemple une restriction sur les adresses de réception. Plus précisément, il s’agit de restreindre les sorties transactionnelles de la transaction dépensant la pièce qui contient le pacte.

En termes techniques, comme l’explique Anthony Towns :

« Dans le contexte de Bitcoin, la définition la plus utile du covenant est qu’il s’agit du cas où le scriptPubKey d’un UTXO restreint le scriptPubKey de la ou des sorties d’une transaction dépensant cet UTXO. »

La première proposition de covenant pour Bitcoin a été faite par Malte Möser, Ittay Eyal et Emin Gün Sirer en février 2016. Depuis, plusieurs propositions se sont succédées.

La plus concrète d’entre elles est aujourd’hui le BIP-119, qui décrit une mise en œuvre simple de ce mécanisme par l’ajout d’un nouveau code opération : OP_CHECKTEMPLATEVERIFY (OP_CTV). Cette solution est portée par le développeur qui l’a présenté pour la première fois le 17 mai 2019 sous la forme du code opération OP_CHECKOUTPUTSHASHVERIFY. Il a renommé cet opcode en OP_SECURETHEBAG en juin de la même année, pour finalement choisir le nom actuel en novembre.

OP_CTV est un code opération qui se place dans le script de verrouillage d’une sortie transactionnelle et qui, lors de son exécution, a pour effet d’exiger que la transaction dépensant cette sortie satisfasse un modèle joint (template). Ce modèle est fourni sous la forme d’une empreinte d’engagement (commitment hash) qui oblige la transaction suivante à contenir des données précises. Les champs fixés par OP_CTV sont (dans l’ordre) : la version de la transaction, le temps de verrouillage, les scripts des entrées, le nombre d’entrées, les numéros de séquences des entrées, le nombre de sorties, les montants et scripts des sorties, et l’index d’entrée de la pièce dans la transaction. De ce fait, l’engagement ne prend pas en compte la sélection des entrées transactionnelles (points de sortie) et les signatures SegWit (témoin), ce qui fait que l’utilisateur peut modifier les entrées de sa transaction comme il le souhaite.

L’implémentation est donc à la fois très simple et particulièrement restrictive : il ne s’agit pas seulement d’imposer une ou plusieurs adresses données vers lesquelles les fonds peuvent être envoyés, mais également les montants, ainsi que d’autres informations présentes dans la transaction.

Cela a l’avantage de faire en sorte que la transaction qui inclut le covenant soit non malléable au prix d’un manque de flexibilité. De plus, OP_CTV ne peut en pratique être utilisé que sous forme brute (à condition de présigner toutes les entrées) ou par le biais des adresses SegWit P2WSH. De surcroît, il est absent du système de scripts de Taproot (Tapscript).

La mise en œuvre autorise la récursivité (on peut utiliser OP_CTV pour imposer d’autres OP_CTV) sans pour autant que cette dernière soit infinie (toutes les conditions doivent tous être définies préalablement). Il peut également y avoir plusieurs OP_CTV dans un même script, ce qui permet d’avoir un covenant autorisant de multiples possibilités pour la dépense de la pièce.

OP_CTV constitue ainsi une brique de base qui pourrait faciliter, voire rendre possible, un certain nombre de cas d’usage.

Tout d’abord, il peut offrir un meilleur contrôle de congestion de la chaîne en permettant aux plateformes d’échange de réduire leurs frais sur leurs paiements par lots, en réalisant ces paiements en plusieurs temps. Il s’agirait de placer le pacte dans la première transaction (très petite en taille) qui autoriserait un certain nombre de transactions suivantes pour distribuer les fonds aux utilisateurs. Le taux des frais payés par la première transaction serait assez élevé pour qu’elle soit confirmée rapidement, tandis que celui des transactions suivantes le serait beaucoup moins, si bien que cela réduirait sensiblement les frais totaux.

Ensuite, ce nouveau code opération pourrait également faciliter la mise en place de coffres-forts, chose qui est au demeurant déjà possible sur Bitcoin. Enfin, OP_CTV pourrait améliorer la création de canaux pour Lightning ainsi que la construction des transactions de mélange dans les portefeuilles confidentiels comme Samourai.

>> Jouez la sécurité, inscrivez-vous sur Binance LA référence des exchanges crypto (lien commercial) <<

Une activation brutale ?

Depuis l’activation de Taproot en novembre 2021, quatre propositions principales se concurrencent pour constituer le prochain changement technique du protocole BTC :

• L’agrégation des signatures entre entrées transactionnelles (CISA), qui permettrait de réduire de 25% en moyenne la taille des transactions ;
• SIGHASH_ANYPREVOUT (BIP-118) qui rendrait possible Eltoo, une amélioration du réseau Lightning ;
• Les BIP 300 et 301, qui permettrait l’utilisation de Drivechain, un modèle de chaînes latérales décentralisées gérées par les mineurs ;
• Et bien sûr, OP_CTV (BIP-119) qui autoriserait les covenants.

Conformément à la philosophie de la communauté, il s’agit de soft forks : ces changements sont des restrictions des règles de consensus, qui ont le mérite d’être « rétrocompatibles » et de ne pas créer deux chaînes distinctes dans le cas d’un soutien par la majorité de la puissance de calcul du réseau. En particulier, OP_CTV serait implémenté en redéfinissant le code opération OP_NOP4 (l’une des instructions sans effet du système ajoutées par Satoshi Nakamoto en 2010) et son intégration constituerait donc un soft fork.

Bien que ces propositions soient des soft forks, il s’agit tout de même de modifications du protocole. Elles ont par conséquent un coût d’intégration, notamment en matière de complexité, et il est naturel que le processus prenne du temps. Mais cela peut frustrer les développeurs qui travaillent sur ces propositions.

Ainsi, Jeremy Rubin a récemment décidé de passer à l’action. Le 19 avril dernier, il a partagé un article sur la liste de diffusion bitcoin-dev, qui annonçait la sortie imminente d’une nouvelle implémentation logicielle contenant les paramètres d’activation pour OP_CTV. Il reposait son argumentaire sur le fait que son concept avait passé l’épreuve de temps (plus de 2 ans sans changement majeur) et que les gens y étaient globalement favorables, les oppositions étant rares (comme indiqué sur utxos.org).

Jeremy Rubin a choisi de mettre en place un Speedy Trial (« procès expéditif »), le mécanisme ayant servi à activer Taproot l’année dernière. Il s’agissait de faire en sorte que les mineurs signalent leur intention d’activer le soft fork très rapidement afin de voir si celui-ci pouvait se faire dans de bonnes conditions. Si 90 % des blocs minés lors d’une période de 2016 blocs signalaient le soft fork, celui-ci aurait été verrouillé et activé ultérieurement.

Les paramètres proposés par Jeremy Rubin étaient les suivants :

• Un début de signalement fixé au 5 mai 2022 à minuit (MTP) ;
• Une fin de signalement fixée au 12 août 2022 à minuit (MTP), soit environ 3 mois plus tard (6 périodes de 2016 blocs) ;
• Une activation de OP_CTV fixée au bloc de hauteur 762 048 (soit approximativement le 9 novembre) dans le cas où d’un signalement positif.

Cette démarche audacieuse a immédiatement provoqué une levée de boucliers. Mis devant le fait accompli, les gens ont réagi. Les critiques, qui s’étaient faites jusqu’alors très rares, ont commencé à affluer. En particulier :

• Anthony Towns a remarqué un manque d’« exploration pratique » de OP_CTV en analysant l’activité du réseau de test (signet) ;
• Matt Corallo a reproché à la mise en œuvre OP_CTV son manque de flexibilité, souhaitant implémenter un concept de covenant qui soit « le plus flexible, le plus utile et, espérons-le, le plus confidentiel possible » ;
• David Harding a mis en avant la possibilité que OP_CTV pourrait ne pas avoir un « usage significatif dans le monde réel » qui justifie la « charge de maintenance » et la « surface de sécurité » associées ;
• Antoine Poinsot a suggéré qu’une activation d’une version légèrement modifiée de SIGHASH_ANYPREVOUT pourrait « très bien émuler CTV » (bien que la construction serait alors plus compliquée pour l’utilisateur) et qu’une activation du BIP-118 serait donc plus bénéfique, celui-ci apportant d’autres avantages comme Eltoo.

En définitive, il semblait que les implications et les alternatives à OP_CTV n’avaient pas été suffisamment évaluées. Suite à ces remarques et après une période de réflexion, Jeremy Rubin a fini par revenir sur sa décision et n’a pas publié le code d’activation. Dans un courriel du 2 mai adressé à la liste bitcoin-dev, il a ainsi indiqué ne pas « promouvoir une activation de Speedy Trial (ST) de la proposition d’amélioration de Bitcoin 119 (BIP-119) CheckTemplateVerify (CTV) pour le moment ».

>> Une plateforme crypto solide même quand le marché flanche ? Inscrivez-vous sur Binance et économisez 10% de frais (lien commercial) <<

Était-ce une attaque ? Que pouvait-il se passer ?

On ne peut que le remarquer : la démarche de Jeremy Rubin a suscité la polémique et a fait ressurgir les vieux démons du débat sur la scalabilité. Certaines personnes ont été jusqu’à qualifier l’annonce d’« attaque contre Bitcoin ». En quelques jours, la controverse a pris une ampleur telle que beaucoup de personnalités impliquées dans Bitcoin se sont prononcées sur le sujet en s’y opposant, comme Adam Back ou Andreas Antonopoulos, notamment en raison de l’absence de consensus approximatif (rough consensus) sur la question.

Il est néanmoins difficile de qualifier cette démarche d’« attaque » contre Bitcoin : OP_CTV ne viole pas les principes fondamentaux de Bitcoin et Speedy Trial n’est qu’un moyen d’activation parmi d’autres, qui a été précédemment utilisé par Taproot. Cependant, cette activation aurait bel et bien pu provoquer une attaque sur le réseau.

Comme on l’a dit, OP_CTV est un soft fork, une restriction des règles de consensus. De ce fait, si le signalement des mineurs s’était avéré suffisant et si OP_CTV avait été appliqué par une majorité de la puissance de calcul du réseau en novembre, les utilisateurs n’ayant pas accepté ce changement auraient considéré la chaîne appliquant le soft fork comme la plus longue chaîne valide, c’est-à-dire la chaîne à suivre. Ils auraient alors pu constater que des transactions valides selon leurs règles auraient été refusées et que les blocs tentant de les confirmer auraient été ignorés. En d’autres termes, leur chaîne aurait subi une censure active par attaque des 51 %. Car un soft fork pour les uns est une attaque des 51 % pour les autres, et inversement.

Cette attaque aurait pu s’accompagner d’une communication pernicieuse qui aurait insisté sur le fait que le nouveau protocole (incluant OP_CTV) aurait désormais constitué le vrai protocole Bitcoin, illustrant le concept de « soft fork forcé » articulé par Peter Todd en 2016, et négligeant le fait que ce sont les commerçants et utilisateurs qui choisissent en dernier lieu les règles de consensus.

Ainsi, devant le risque d’activation qui pouvait sévèrement impacter l’image de Bitcoin, le développeur Michael Folkson (opposant à OP_CTV depuis longtemps) a proposé le 21 avril un mécanisme concurrent pour contrebalancer le Speedy Trial, qu’il a baptisé l’User Resisted Soft Fork (URSF) en référence à l’User Activated Soft Fork. Ce nouveau soft fork aurait eu pour effet d’invalider automatiquement les blocs signalant le BIP-119 à partir d’un certain seuil de signalement, dans le but d’« empêcher l’activation du soft fork tenté ».

Cette méthode, pour le moins controversée, aurait pu créer une scission (au moins temporaire) de la chaîne : en effet, il est à peu près certain que les mineurs signalant majoritairement une approbation de OP_CTV n’auraient pas appliqué l’URSF, ce qui aurait eu pour effet de créer une nouvelle chaîne (soft fork minoritaire). L’idée semblait donc être de scinder la chaîne temporairement pour échapper à ce qui s’apparentait à de la censure, puis de faire en sorte que la chaîne nouvellement créée devienne économiquement majoritaire et qu’elle invalide l’autre au bout d’un certain temps.

Cependant, cela avait peu de sens si l’on part du principe qu’une une large majorité économique rejetait déjà ce changement. Les mineurs ne sont pas intrinsèquement hostiles à Bitcoin : sauf dans le cas d’intérêts externes (subventions), ils ne cherchent pas à détruire Bitcoin, mais souhaitent à l’inverse préserver leur relation économique avec les utilisateurs, qui valorisent l’unité de compte et qui paient des frais. Une activation de OP_CTV qui n’aurait pas été largement consentie aurait mené à une grande instabilité et donc probablement à une baisse des revenus miniers. Ainsi, au vu de la controverse, il était très peu probable que les mineurs prennent le risque d’activer OP_CTV.

Était-ce un coup de publicité ?

Dès lors qu’on réfléchit un peu à cette polémique, on comprend que les chances de Jeremy Rubin d’intégrer OP_CTV au protocole Bitcoin étaient très minces. Alors pourquoi avoir entrepris cette démarche controversée ?

Jeremy Rubin l’évoque dans la dernière section de son article où il nous explique que Bitcoin Core (l’implémentation logicielle principale) « n’est pas Bitcoin ». Il s’en prend aux mainteneurs du logiciel, c’est-à-dire les quelques personnes ayant le pouvoir d’approuver et de refuser les modifications du logiciel, qui ont bloqué l’intégration d’OP_CTV au logiciel. D’après Rubin, ces derniers n’ont pas à « décider de ce qui se fait en ce qui concerne les mises à niveau du consensus » et que « tous les acteurs doivent décider s’il est dans leur intérêt rationnel de procéder au soft fork ».

Il faut en convenir : les mainteneurs de Bitcoin Core possèdent effectivement une grande influence sur les règles de consensus de BTC, étant vus comme les gardiens du protocole. Cette situation a l’avantage d’apporter une grande stabilité en décourageant les dissidences au sein de Bitcoin et les scissions de chaîne qui pourraient en résulter (comme on l’a vu avec Bitcoin Cash et ses dérivés).

Toutefois, cette situation a aussi des mauvais côtés, car elle interdit aux changements ayant un grand potentiel d’être intégrés au protocole, pourvu qu’un mainteneur s’y oppose. On peut citer l’exemple des BIP 300 et 301 (Drivechain) qui ont été proposés il y a plus de cinq ans par Paul Sztorc et qui n’ont jamais été intégrés au code. De manière générale, on assiste ainsi depuis des années à une ossification du protocole, protocole qui est de facto de plus en plus dur à faire évoluer, y compris sous la forme d’un soft fork.

Bien entendu, cela frustre énormément les développeurs qui voudraient contribuer. Chaque proposition possède ses propres compromis (SegWit et Taproot étaient loin d’être des mises à niveau parfaites par exemple) et il peut sembler arbitraire que tel ou tel compromis soit privilégié par une équipe unique. D’où la défiance à l’égard de Bitcoin Core.

Il semble donc que le but premier de cette démarche osée de Jeremy Rubin a été de faire parler de sa proposition OP_CTV en dehors du cercle restreint des développeurs du protocole, pour atteindre les personnes qui possèdent réellement le pouvoir de décision, c’est-à-dire les utilisateurs de Bitcoin. Et force est de reconnaître que cela a fonctionné.

Pour écrire cet article, je me suis basé sur les différentes informations compilées par Bitcoin Optech, dont notamment la page sur OP_CHECKTEMPLATEVERIFY.

Bitcoin est résistant et résilient. Demain ou dans quelque temps, vous serez content d’en avoir acheté pendant la crise. Ne tardez pas trop pour profiter des conditions d’achat actuelles, et économisez encore 10% sur vos frais de trading en suivant ce lien ! Courez vous inscrire sur Binance, LA référence absolue des exchanges cryptos (lien commercial).