20h00 ▪
13
min de lecture ▪ par
Quel est le problème ?
Sans la limite des 21M, le bitcoin n’aurait aucune raison d’être. La beauté du système est que nous sommes naturellement incités à refuser toute augmentation de ce plafond. Ce serait se tirer une balle dans le pied en dévaluant nos propres bitcoins.
Toutefois, le code n’est pas complètement figé. Bitcoin Core est bichonné de temps à autres. Parfois, des soft forks sont proposées, non sans controverse. Les dernières en date furent SegWit et Taproot.
Malheureusement, chaque altération du protocole apporte forcément son lot de bugs inattendus. Les ordinals en sont la parfaite illustration. Ceux pour qui la chose est encore floue peuvent lire cet article : Ordinals, amélioration ou attaque ?
En résumé, les ordinals sont de la donnée arbitraire se faisant passer pour de l’art. Il s’agit essentiellement de fichiers jpeg/json incrustés à l’intérieur des scripts de transaction en contournant les limitations tolérées.
Ces inscriptions profitent par ailleurs d’une réduction de frais de transaction. La donnée coûte en effet quatre fois moins cher dans le « witness » introduit par SegWit, là où sont précisément insérés les ordinals.
Bugs (im)prévus
Jaqen Hash’ghar nous avait mis en garde contre le risque d’attaque DDoS qu’enfanterait SegWit. Il écrivait dans cet article publié en 2016 :
« La limite théorique de 4 Mo crée un problème majeur. […] Il existe une incitation financière pour des acteurs malveillants à concevoir des transactions comportant des données lourdes et complexes dans le witness [ordinals…]. Ce problème est exacerbé par le fait que les scripts liés au witness (P2SH-P2WSH) pourront être plus gros que la normale. »
Le problème a depuis empiré. Bitcoin Magazine écrivait en effet en 2021 à propos de la soft fork Taproot :
« La limite de 10 000 octets pour les scripts sera supprimée […]. La limite est également supprimée pour les ‘opcodes’, ce qui permettra davantage de fonctionnalités ouvrant la voie aux smart contracts. »
Dit autrement, certains développeurs ont fait sauter d’importantes digues pour doter le bitcoin de fonctionnalités superflues. Résultat des courses, des shitcoiners tentent de transformer les transactions bitcoin en jetons de casinos.
En sachant que plus le ponzi adossé à ces inscriptions sera gros, et plus les transactions légitimes deviendront chères.
Sans oublier qu’à l’explosion prématurée des frais de transaction s’ajoute l’explosion du coût d’un nœud et du temps d’IBD (Initial Blockchain Download) qui varie aujourd’hui entre 3 jours et 3 semaines…
Centralisation du bitcoin
Le bitcoin existe depuis 15 ans, mais sa blockchain est passée de 446 Go à 537 Go en un an seulement (+20 %).
Entre 2016 et 2023, elle augmentait en moyenne de 55 Go par an. En 2023, ce fut 93 Go, principalement à cause des ordinals.
Pire, au cours de la même période, nous avions seulement 7 millions d’utxo supplémentaires par an. Ce fut plus près de 80 millions en 2023 !!
Comprendre en quoi stamps est encore plus problématique que le protocole ordinal nécessite de rappeler qu’il existe deux types de nœuds.
Il y a d’une part les « full nodes » qui détiennent l’ensemble de la blockchain. Et d’autre part les « pruned nodes » qui se contentent de vérifier les blocs avant de les effacer. Ces derniers doivent toutefois détenir l’ensemble des utxo (une poignée de Go).
Alors que les ordinals peuvent être élagués par les pruned nodes, le protocole stamps génère pour sa part des inscriptions impossibles à élaguer puisque présentes dans l’UTXO set, et non pas dans le witness.
Voici le résultat :
Il s’agit probablement du bug le plus évident depuis le bug « infinite money ». Le corriger ne devrait même pas faire l’objet d’une quelconque controverse.
La solution : Filtrer les transactions
Avant de trouver son chemin jusque dans un bloc, les transactions sont relayées entre les nœuds du réseau P2P Bitcoin qui les mettent en cache dans leurs mempools. Les exceptions étant les transactions insérées d’office par une pool.
Afin d’atténuer certaines attaques DDoS, les nœuds Bitcoin Core trient les transactions pouvant être relayées. Celles considérées comme « standard » sont relayées, tandis que les transactions « non standard » ne le sont pas.
Des transactions non standard trop fréquentes – ce qui est le cas avec les inscriptions – signifient que les « policy rules » (les filtres) doivent être adaptés pour stopper l’attaque DDoS. On parle dans le jargon de « policy check », par opposition aux « consensus check ».
Les règles de consensus déterminent si un bloc est valide. Par exemple, la règle de 1 Mo par bloc. Les règles de consensus sont vérifiées par les nœuds lorsqu’ils reçoivent un bloc propagé par les mineurs. A contrario, le « policy check » s’applique en amont, au niveau du mempool.
De nombreux filtres sont apparus au cours du temps. Bitcoin Core considère par exemple non valide une transaction dont le montant est inférieur à ce qu’il en coûtera pour la créer et la dépenser (bitcoin dust limit).
Le mempool n’accepte pas non plus les transactions pesant plus de 100 000 voctets ou celles payant moins de 1 sat/voctet en frais de transaction.
Bref, la solution proposée par le développeur Bitcoin Core Luke Dash est d’étendre la portée du filtre -datacarriersize. Le but étant de limiter la quantité de données pouvant être insérée dans les transactions.
Bitcoin -Datacarriersize
-Ddatacarriersize fait référence à la quantité de données des transactions dites « Op_Return« . Ce type d’utxo fut introduit pour offrir une alternative aux techniques plus nocives d’insertion de données arbitraires dans la blockchain.
A cette époque (2014), ne pas encrasser la blockchain était encore une évidence… On décida donc de limiter la quantité de données arbitraires des transactions standards à 83 voctets. En somme, de quoi entrer un simple hash.
Luke Dash jr considère comme un bug le fait que -datacarriersize n’ait pas été appliqué à toutes les données de transactions lors des soft forks Segwit et Taproot. Il a depuis développé le patch ordirespector sur son client Bitcoin Knot.
Le protocole stamps peut également être stoppé en changeant la valeur par défaut de -permitbaremultisig à 0.
De nombreux défaitistes (corrompus ?) voudraient nous faire croire que les filtres ne fonctionnent pas. Ils avancent crapuleusement qu’un « filtre efficace doit empêcher 100 % du spam, pour toujours ».
En réalité, la menace de filtrer les inscriptions de manière systématique serait suffisante pour décourager toute tentative. Une petite majorité de nœuds suffirait même à bloquer la propagation de ces transactions toxiques.
Ceux qui orchestrent cette attaque DDos devront alors recourir à des moyens laborieux nécessitant de s’allier directement avec les pools. Nous pourrions alors inciter les mineurs à quitter ces pools puisque les frais de transactions seront payés de manière opaque en dehors du réseau.
Florilège de déclarations appelant à endiguer les inscriptions
Voici une liste de déclarations collectées par glozow allant dans le sens de la proposition du développeur Luke Dash (et fondateur de la pool Ocean) d’étendre le -datacarriersize à toutes les données de transaction :
-« Il faut stopper les inscriptions, c’est du spam »
« L’insertion de données est un abus du script taproot. »
« La possibilité d’intégrer des données arbitraires est une vulnérabilité. »
« Si le bitcoin est une monnaie (il l’est !)… alors les transactions non monétaires devraient être réduites autant que possible. »
« Il s’agit d’une mauvaise utilisation du réseau. Le Bitcoin était destiné aux transactions financières (le white paper, son titre et le code l’indiquent)… Le stockage de données n’était pas un cas d’utilisation prévu. »
-« Les inscriptions abiment le réseau »
« Cela provoque une congestion du réseau, des frais de transaction plus élevés ou des temps de traitement plus lents. C’est une attaque DDoS. »
« Le problème ne vient pas des inscriptions, mais des frais de transaction astronomiques qui en résultent. »
« Ces transactions affectent la décentralisation du réseau en augmentant le coût d’exploitation d’un nœud. »
-« Les nœuds veulent une option pour filtrer les inscriptions »
« Les opérateurs de nœuds ont besoin d’une option pour ignorer toutes les formes modernes d’insertion de données afin qu’ils n’aient pas à patcher manuellement leurs nœuds. »
« Je veux être responsable du ‘policy check’ du mempool de mon nœud. Je veux décider de ce qui est du spam et de ce qui ne l’est pas. »
-« Corrigeons simplement le -Datacarriersize pour qu’il fonctionne comme prévu »
« Bitcoin Core interdit déjà l’insertion de données arbitraires au-dessus de 83 octets (Op_Return). Les inscriptions sont un moyen de contourner cette limite. Il s’agit donc d’un bug à corriger. »
« Le spam est déjà filtré à différents niveaux du code, et ce, depuis plus d’une décennie. Nous devons appliquer une limite existante partout où il existe des vulnérabilités permettant d’insérer du spam dans la blockchain. »
« Quel est l’objectif de la limite -datacarriersize (Op-Return) si ce n’est d’imposer une limite aux données arbitraires ? »
Florilège de déclarations appelant à la passivité
Voici quelques arguments (parfois de mauvaise foi) de ceux qui refusent de filtrer les inscriptions :
-« Ça n’empêchera pas les inscriptions »
« Si seule la pool Ocean utilise ces filtres, et qu’elle demeure une pool relativement petite, cela n’aura aucun effet. Et même si l’on déploie largement ces filtres, il sera facile de les contourner. »
« Il est évident qu’un bloc construit à partir d’un mempool filtré offrira des frais de transaction inférieurs à ceux d’un bloc construit à partir de toutes les transactions. Cela signifie que les mineurs qui filtrent les inscriptions réduisent leurs propres revenus au profit des mineurs qui ne filtrent pas. »
« Il est très peu probable que les mineurs renoncent à cette source de revenus. La censure de ces transactions ne ferait qu’encourager le développement de mempools privés. »
« Ceux qui réalisent ces inscriptions pourraient maintenir le relais des inscriptions sur le réseau en s’assurant qu’une petite fraction des nœuds ne filtre pas les inscriptions. »
« Les transactions d’ordinals finiront de toute façon dans la blockchain, en contournant le mempool [en contactant directement des pools], donc ces filtres ne feraient rien pour résoudre/atténuer le problème. »
-« Nous ne pouvons pas écrire un code permettant de détecter toutes les données arbitraires »
« Il n’y a pas de moyen universel de filtrer tous les styles d’insertion de données arbitraires actuels et futurs. Cela invite à un jeu du chat et de la souris sans fin […]. »
« Essayer d’empêcher tous les types d’insertion de données entraînera une complexification du code. Et chaque fois que cela se produira, il y aura une forte pression sur les mainteneurs de Bitcoin Core pour qu’ils le fassent passer rapidement afin d’arrêter le spam. »
« Pour autant que je puisse en juger, il n’existe aucun moyen raisonnable d’empêcher les gens de stocker des données arbitraires dans le witness sans encourager un comportement encore pire [stamps] et/ou briser des cas d’utilisation légitimes. »
« -Freeee market »
« Ce n’est pas à nous de dire comment les gens doivent utiliser le bitcoin. »
« Bitcoin est un réseau décentralisé permissionless… chacun peut utiliser son bitcoin de la manière qu’il souhaite, même si le cas d’utilisation est déplaisant (pour quelque raison que ce soit). »
Que d’excuses pour ne rien faire. Nous sommes en présence d’une attaque DDoS extrêmement sophistiquée. Il est grand temps de se défendre avant que la mayonnaise ponzienne des ordinals, SRC-20 et autres ersatz de shitcoins ne prenne. Il en va de la décentralisation du réseau.
Le Bitcoin est une éruption d’énergie chiffrée incensurable se diffractant aux quatre coins d’un monde en ébullitions géopolitique et inflationniste. Je vous tiens au courant.
Source
#Bitcoin #frappé #durement #par #une #attaque #DDoS
