Bitcoin – La Soft Fork de la discorde

Certains développeurs poussent de nouveau pour une soft fork qui fait beaucoup moins consensus que les précédentes.

Bitcoin Soft Fork

Il n’est pas aisé d’altérer le code du bitcoin. Nous sommes incités à ne jamais modifier la partie du code correspondant à la limite des 21 millions.

Certaines évolutions sont toutefois nécessaires, d’autres beaucoup moins. Il se trouvera malheureusement toujours des développeurs qui voudront apporter leur mauvais grain de sel.

Les évolutions du code sont proposées via des « Pull Requests ». La plupart sont mineures, mais certaines sont majeures. Elles deviennent alors des BIP (Bitcoin Improvement Proposals) qui sont parfois des « soft forks ».

Pour rappel, un hard fork est une évolution du code incompatible avec l’ancien. L’exemple typique est BCH (Bitcoin Cash). Les nœuds du réseau BTC ne valident pas les blocs BCH du fait qu’ils peuvent dépasser la limite de 1 Mo par bloc. Une telle modification déclenche un hard fork.

Dans le cas d’une soft fork, les deux codes cohabitent sur la même blockchain. On parle de rétrocompatibilité. Par exemple, nous pourrions modifier la taille des blocs à 0.3 Mo. C’est moins que la limite de 1 Mo et donc rétrocompatible avec le protocole originel.

Les dernières soft forks en date furent SegWit (2016) et Taproot (2021). Certains développeurs poussent actuellement pour une nouvelle fork afin de permettre la création de « covenants » via l’ajout de nouveaux OP_codes.

Blockstream Research a récemment publié un résumé assez pointu sur le sujet :

Is OP_CAT happening?

The covenants proposal was recently assigned BIP 347, and now it's up to the community to decide.

Blockstreamer @kiarabickers breaks down the pros and cons and attempts to answer the question on most Bitcoiners' minds: Is it safe?https://t.co/2nSj6JQ7ja pic.twitter.com/uxiAz0zx1H

— Blockstream (@Blockstream) July 2, 2024

Hop Hop

Il est essentiel de comprendre la mécanique des transactions bitcoin pour comprendre ce que sont les covenants. La magie s’opère grâce à un langage d’exécution informatique appelé « script ». Il s’agit d’un langage très simple comprenant un nombre limité d’instructions.

Ces instructions sont appelées des OP_codes. Voyez-les comme des petits rouages numériques qui se mettent en branle au moment de la validation d’une transaction.

Concrètement, réaliser une transaction bitcoin signifie créer un « utxo » à partir d’un (ou plusieurs) autre « utxo » qui est détruit dans le processus. Un utxo est un bout de code (un script) qui lie mathématiquement une quantité de bitcoins à une adresse bitcoin (une clé publique).

En somme, réaliser une transaction signifie changer la clé publique (l’adresse bitcoin) à laquelle est liée la quantité de bitcoins.

Lors d’une transaction, l’OP_code star est OP_CHECKSIG. Ce dernier vérifie que la signature correspond bien à la clé publique de l’utxo qui est dépensé. Si tout est en ordre, un nouvel utxo comportant la clé publique du receveur est créé.

Dans l’ensemble, Bitcoin Script est un langage de programmation « stacked based » plutôt simple qui limite le champ des possibles.

Blockstream écrit à ce propos :

« En l’état actuel des choses, il n’est pas possible de préconfigurer la façon dont des bitcoins d’un utxo peuvent être dépensés ou la vitesse à laquelle ils peuvent être dépensés. La seule solution est de bricoler en utilisant des PSBT (transactions bitcoin partiellement signées) qui ne peuvent notamment pas inclure correctement les frais de transaction […].

La simplicité du langage de programmation Script, bien qu’elle soit au cœur du modèle de sécurité de Bitcoin, introduit des limitations importantes dans sa capacité à prendre en charge les smart contracts les plus élémentaires. »

Plus d’arithmétique dans le stack

« Stack based » signifie que les données nécessaires à la mécanique des transactions sont placées dans un « stack » où des opérations logiques sont réalisées.

Exemple du mécanisme de vérification d’une transaction :

L’OP_code OP_DUP va DUPliquer la clé publique d’un utxo et la mettre dans le stack.

L’OP_code OP_HASH va hacher cette clé (ce qui la transforme en adresse à laquelle les bitcoins ont été mathématiquement liés dans l’utxo)

L’OP_EQUALVERIFY vérifie que le hash résultant appartient bien à l’utxo en question.

L’OP_CHECKSIG vérifie que la signature fournie correspond bien à la clé publique de l’utxo.

Bitcoin Script possède un peu moins de 100 OP_codes non triviaux. Mais le fait est qu’il n’est pas possible de multiplier, de diviser ou de concaténer (combiner) des données se trouvant dans le stack.

Satoshi a désactivé plusieurs OP_codes en 2010 (OP_OR, OP_MUL [multiplier], OP_DIV [diviser] et OP_CAT [concaténer]). Ces OP_codes ont été supprimés parce que leurs implémentations originales présentaient des vulnérabilités exploitables susceptibles de compromettre la sécurité du réseau.

Leur absence rend toutefois difficile la création de certaines conditions de dépense exotiques (smart contracts). Notamment l’impossibilité de définir dans l’utxo des conditions de dépenses basées sur les données de transaction.

Blockstream explique :

« Si le script avait la capacité d’interpréter plus de détails se trouvant à l’intérieur des données de transaction, nous pourrions construire des contrats beaucoup plus robustes permettant d’appliquer des conditions de dépense spécifiques ».

Covenants

Actuellement, le seul « smart contract » possible avec le bitcoin est tout simplement l’acte classique de verrouiller et de déverrouiller des bitcoins liés à une clé publique. Réaliser une transaction en somme.

Les covenants visent à créer un nouveau type d’utxo permettant à l’émetteur d’une transaction d’imposer certaines conditions sur la manière dont le destinataire pourra dépenser les bitcoins par la suite.

Voici deux OP_codes que l’on regroupe sous le terme « covenants » aux capacités limitées qui reviennent souvent dans le débat :

OP_CHECKTEMPLATEVERIFY (CTV) : La principale utilité mise en avant est la possibilité pour plusieurs personnes de partager un même utxo (BIP119 proposée par Jeremy Rubin) en cas de frais de transaction trop élevés. C’est une sCaLing sOluTIon qui n’en est pas vraiment une, entre autres possibilités plus ou moins intéressantes.

OP_VAULT : Ce covenant permet à un utilisateur de déterminer quand et où les bitcoins peuvent être déplacés, y compris dans des transactions ultérieures.

Si un employé ayant accès aux clés privés tente de voler des bitcoins, la compagnie pourra transférer les fonds vers une adresse de récupération prédéterminée avant que les bitcoins ne soient transférés vers une adresse appartenant au voleur.

OP_CAT : Cet OP_code est encore plus controversé puisqu’il peut être « récursif ». C’est-à-dire qu’il s’applique non seulement à la prochaine transaction, mais aussi à toutes les transactions ultérieures qui dépenseront les bitcoins concernés. Des conditions de dépense peuvent donc être appliquées de manière récurrente / perpétuelle.

Le Bitcoin a-t-il vraiment besoin de ces OP_codes ?

Les covenants récursifs posent la question de l’unicité de la monnaie. Un bitcoin dont la dépense est conditionnée vaut nécessairement moins qu’un bitcoin dont la dépense est conditionnée. Un billet de 100 euros vaut davantage qu’un bon d’achat de 100 euros valide dans un seul magasin…

Par ailleurs, OP_CAT est supporté par Taproot Wizards, une clique trouble de développeurs emmenée par l’intriguant Udi Wertheimer. Leur efforts pour ruiner la décentralisation du bitcoin en popularisant les inscriptions (Ordinals, stamps, etc) devrait allumer des voyants rouges…

Enfin, l’utilité réelle de ces OP_codes reste à démontrer. Mis à part les exchange, quelles compagnies ont besoin d’OP_Vault ? Concernant CTV, quel problème cherche-t-on à résoudre ? APrès 15 ans d’existence, il n’y a que 16 millions d’utxo contenant plus de 2600 dollars, en sachant que qu’environ 150 millions d’utxo peuvent être créés chaque année.

Toutes ces propositions ont en commun de parier sur le fait que le bitcoin deviendra un moyen de paiement populaire. Nous en sommes encore loin. Il n’y a donc pas le feu.

Est-ce que ces « solutions » de plus en plus complexes ne seraient pas l’expression d’une certaine forme de déni ? Il faudra bien se résoudre à admettre que le bitcoin ne peut pas rivaliser avec Mastercard (frais de conversion et de transaction trop élevés).

Blasphème ou analyse objective ? Peut-être ne devrions-nous pas trop en demander au bitcoin dont l’offre principale est d’être une réserve de valeur absolue, et non pas une alternative au système fiat. Peut-être est-il préférable de ne pas intégrer des gadgets inutiles qui introduiront de nouvelles vulnérabilités pour rien. Une dizaine de vulnérabilités ont été tout récemment dévoilées…

Si cet article vous a plu, vous apprécierez celui-ci sur l’attaque DoS des inscriptions.