Les Devs de Bitcoin Core sous le feu des critiques

Un changement de philosophie inquiétant est à l’œuvre chez les développeurs de Bitcoin Core.

No_Return

Bitcoin Core est à nouveau sous le feu des critiques. Le développeur français Antoine Poinsot a jeté un pavé dans la mare en proposant de supprimer la limite quant à la quantité de données arbitraires (spam) pouvant être insérée « légalement » dans les transactions.

Voici en essence sa proposition (version tronquée) qu’il détaille plus en longueur sur son blog :

Par défaut, Bitcoin Core ne propage et ne mine que les transactions contenant au maximum un OP_RETURN ne dépassant pas 83 octets. […] Cependant, certains parviennent à contourner cette limite. Je propose donc de la supprimer pour cesser d’encourager des techniques d’insertion de données plus nuisibles […].

Antoine Poinsot

Commençons par expliquer ce qu’est « OP_RETURN ». Il s’agit d’un opcode permettant d’insérer proprement des données arbitraires dans une transaction. Cette méthode « officielle » offre un espace limité de 83 octets pour ce faire.

Les transactions utilisant l’opcode OP_RETURN ont ça de particulier qu’elles génèrent des UTxO ne pouvant plus être dépensées (unspendable output). Utiliser OP_RETURN sert à signaler aux nœuds qu’ils n’ont pas besoin de mémoriser l’UTxO de la transaction en question.

[On appelle UTxO les petits bouts de code (les « scripts ») qui lient mathématiquement les bitcoins à des adresses BTC (les adresses étant des encodages de clés publiques).]

Le vase a débordé lorsque le développeur Peter Todd a proposé de carrément supprimer la possibilité qu’ont les nœuds de configurer eux-mêmes la limite OP_RETURN :

Supprimons également l’option de configuration -datacarriersize […]. Cette limite est de toute façon facilement contournée via des soumissions directes aux mempools des mineurs (par exemple, MARA Slipstream) ou certaines techniques d’insertion.

Peter Todd

Nous allons tout expliquer, pas de panique.

Data non grata

De quoi parle-t-on exactement ? Que sont ces « données arbitraires » qui font couler tant d’encre ?

On parle communément « d’inscriptions ». Les plus connues sont les « ordinals ». Il s’agit généralement d’images Jpeg qui squattent à l’intérieur des scripts de transactions (P2TR). Il y a aussi les STAMPS, encore plus nuisibles. Ceux-ci stockent la donnée sous forme de fausses clés publiques et génèrent d’énormes quantités d’UTxO (Baremultisig).

Ces inscriptions ont toutes en commun de contourner OP_RETURN afin d’échapper à ses limites, ce qui n’est pas sans conséquences. Alors que l’UTxO set ne pesait que 4 Go avant la mode des inscriptions, nous en sommes aujourd’hui à 12 Go. La moitié des UTxO contiennent moins de 1000 sats, c’est-à-dire du spam.

Cette croissance menace la décentralisation puisqu’il devient plus cher d’installer un nœud (mémoire, ram, IBD, etc). Un autre inconvénient est d’empiéter sur l’usage légitime du réseau, à savoir réaliser des transactions monétaires.

Clarifions à présent l’expression -datacarriersize. Il s’agit du nom du paramètre de configuration définissant la limite d’OP_RETURN. Par défaut, cette limite est fixée à 83 octets dans les versions récentes de Bitcoin Core.

Peter Todd touche ici à ce que l’on appelle les « policy rules ». Ces règles permettent de filtrer les transactions pour empêcher leur propagation jusqu’aux mempools des mineurs afin d’être ajoutées dans un bloc. Le but est d’empêcher certaines attaques par déni de service (DoS). Par exemple, Bitcoin Core ne propage pas les transactions pesant plus de 100 000 voctets.

[Le mempool (contraction de memory pool) contient les transactions valides en attente d’être incluses dans un bloc. Chaque nœud à son propre mempool et ses propres configurations de filtre.]

Maintenant que les bases sont posées, entrons dans le vif du sujet. Cela fait maintenant deux ans que le développeur Luke Dashjr conseille de filtrer les transactions contenant des inscriptions.

Problème, le petit conclave de développeurs à la tête de Bitcoin Core s’y refuse.

Savoir limiter la casse

Bitcoin Core a justifié sa passivité en avançant que des filtres allant à l’encontre des intérêts financiers des mineurs finiront par être contournés. C’est d’ailleurs chose faite avec le système « slipstream » du mineur Marathon.

Slipstream permet de contourner les nœuds du réseau en envoyant les transactions (qui seraient autrement filtrées) directement dans le mempool de Marathon.

Certes, mais ce service n’est pas gratuit. Plus les inscriptions seront chères à produire, moins il y en aura. Tout est bon à prendre pour limiter la casse. Sans parler du fait que Marathon mine moins de 5 % des blocs.

C’est bien simple, seulement 30 transactions OP_RETURN sur 7 millions ont dépassé la limite de 83 octets depuis le début de l’année. Cela représente un taux de réussite de 99,9957 % pour le filtre anti-spam limité à 83 octets.

Revenons-en maintenant à Peter Todd. Sa proposition dérange vu qu’elle ressemble à une capitulation face à l’industrie du spam. D’autant plus que lever les limites d’OP_RETURN n’aura très probablement aucun impact positif en ce qui concerne le spam.

Pourquoi ? Pour la bonne et simple raison que les nouvelles techniques d’insertion sont quatre fois moins chères qu’avec OP_RETURN du fait qu’elles tirent profit du « witness ».

Cette énorme ristourne est liée à la soft fork SegWit qui a fait passer la taille des blocs de 1 Mo à 1 vMo. Le « v » signifie « virtuel ».

Segwit, à l’origine du mal

SegWit est le fruit d’un compromis issu de la « Blocksize war », un épisode qui vaut la peine d’être exploré. Pour être clair, SegWit a permis d’augmenter la taille des blocs de 1 Mo à 4 Mo.

Cela tient au fait que les transactions SegWit sont divisées en deux sections différentes. Les octets de la première section sont comptés comme pesant 4 Voctets, tandis que les octets de la section witness pèsent un seul Voctet.

Ainsi, un bloc contenant 1 Mo de transactions classiques (sans SegWit) pèse 4 VMo. Un bloc de 4 Mo contenant une seule transaction transportant une image de 4 Mo dans le witness pèse 4 VMo.

Le problème, c’est que personne ne pouvait prédire (à vrai dire, si…) que le witness serait exploité par des spammeurs. Les créateurs de SegWit pensaient que la section witness ne contiendrait que des signatures ECDSA légitimes et que les blocs atteindraient au maximum 1,5 à 2 Mo.

Aujourd’hui, la majorité du spam se loge dans le witness de scripts de transactions P2TR. Ces scripts ne sont pas destinés à être exécutés : ils servent uniquement de stockage pour des données arbitraires (images, textes, JSON, etc.), jusqu’à 4 Mo par bloc.

À qui profite le crime ?

Un début de réponse tient peut-être au fait que les filtres ralentissent la propagation des blocs contenant des OP_RETURN dépassant la limite des 83 octets. Le mineur Marathon a donc un intérêt financier à ce que l’on supprime cette limite.

Le projet Citrea de Jameson Lopp en bénéficierait aussi. Le cypherpunk fut d’ailleurs parmi les premiers à soutenir la proposition de Peter Todd. À ce propos, notons que Bitcoin Mechanic (CTO de la pool Ocean) a été banni du Github Bitcoin pour avoir souligné ce conflit d’intérêt. Ironique censure…

Terminons en martelant que Bitcoin est un système de paiement. Faciliter d’autres usages nuisibles à la décentralisation du réseau est une pilule difficile à avaler. Face au dialogue de sourd qui s’est installé avec Bitcoin Core, de plus en plus de monde migre vers d’autres implémentations comme Bitcoin Knots.

Bitcoin Knots est une version modifiée de Bitcoin Core maintenue par Luke Dashjr. Il s’agit d’un client alternatif pour le réseau Bitcoin. Il offre des fonctionnalités supplémentaires et des corrections de bugs que les développeurs de Core se refusent à faire.

L’étape suivante consiste à couper les vivres à des organisations comme @OpenSats, @bitcoinbrink, @HRF, ainsi qu’à retirer ses fonds des ETF qui sponsorisent des développeurs dictateurs. Espérons que la controverse suffira à convaincre Bitcoin Core de ne rien faire.

Voici pour les anglophones une longue tirade de la part de Bitcoin Mechanic pour bien comprendre où nous en sommes :

Si vous êtes encore là, vous apprécierez certainement cet article sur Bitcoin et la Menace Quantique.