Il a fallu 14 ans au #Bitcoin pour atteindre ~80 millions d'UTXOs et moins d'un an pour doubler ce chiffre.
— Nicolas Teterel #FixTheFilters (@NTeterel) January 29, 2024
🥶 pic.twitter.com/JjVu7xKERJ
A
A
Bitcoin frappé durement par une attaque DDoS
mar 30 Jan 2024 ▪
15
min de lecture ▪ par
S'informer
▪
Le Bitcoin subit une attaque par déni de service DDoS qui commence à se faire douloureuse pour les nœuds. Résumé du schmilblick.
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. Des soft forks sont même parfois 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 ?
Les ordinals sont essentiellement des fichiers jpeg/json qui contournent les limitations tolérées en s’incrustant à l’intérieur des scripts de transaction.
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ù s’insèrent 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 par script 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, ‘on’ a fait sauter d’importantes digues en vue d’ajouter des fonctionnalités superflues. Résultat des courses, des shitcoiners tentent aujourd’hui de transformer les transactions bitcoin en jetons de casinos. Littéralement.
Or, plus les ponzis adossés à ces inscriptions grossiront, et plus les transactions 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
La taille de la blockchain est passée de 446 Go à 537 Go en un an seulement (+20 %). Alors qu’elle augmentait en moyenne de 55 Go par an ces dernières années, ce fut 93 Go en 2023, principalement à cause des ordinals.
Nous sommes toujours sur une croissance linéaire diront certains, mais ce n’est pas le cas de l’utxo set. Nous sommes passés d’une moyenne de 7 millions d’utxo supplémentaires par an, à près de 80 millions en 2023 !
La faute revient en bonne partie au protocole stamps qui relève de la même tentative de greffer un casino sur le dos des transactions bitcoin. Sauf que les jpegs se font cette fois-ci passer pour des adresses de scripts multisignatures.
Le protocole stamps est encore plus problématique que le protocole ordinal en ça qu’il impacte tous les types de nœuds.
Rappelons en effet qu’il y a d’une part les « full nodes » qui détiennent l’ensemble de la blockchain. Et d’autre part les « pruned nodes », plus nombreux, qui se contentent de vérifier les blocs avant de les effacer.
Si les pruned nodes ne gardent pas en mémoire les jpegs, ils sont tout de même obligés d’héberger la totalité des utxo (~ 10 Go).
Et alors que les ordinals sont élagués par les pruned nodes, ce n’est pas possible avec le protocole stamps dont les inscriptions se trouvent dans l’utxo set, et non pas dans le witness.
Voici un exemple de transaction stamps :
En plus du besoin de mémoire morte pour les pruned node, la croissance de l’UTXO set augmente le temps d’IBD.
La taille de l’ensemble UTXO a augmenté de 0,61 Go en janvier. Cela correspond à un taux de croissance annualisé de 7,32 Go. À ce rythme, fin de 2024, l’UTXO set aura dépassé les 17 Go, ce qui allongera sérieusement le temps d’IBD.
Une solution : filtrer les transactions
Avant de trouver leur 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 leur mempool. L’exception étant leur insertion directement par une pool.
Afin d’empêcher certaines attaques DDoS, les nœuds Bitcoin Core trient les transactions. Seules les transactions considérées comme « standard » sont relayées.
On parle dans le jargon de « policy rules ». Ces règles sont des filtres. Elles sont différentes des règles de consensus qui déterminent pour leur part si un bloc est valide ou non. Par exemple, la règle de 1 Mo (4vMo) par bloc. Ces règles sont vérifiées par les nœuds lorsqu’un mineur propage son bloc.
A contrario, les filtres s’appliquent en amont, au niveau du mempool. Bitcoin Core considère par exemple non standard 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). Ne sont pas non plus relayées les transactions pesant plus de 100 000 voctets ou encore celles payant moins de 1 sat/voctet en frais de transaction.
Bref, face à la prolifération des inscriptions, le développeur Bitcoin Core Luke Dash propose d’étendre la portée du -datacarriersize via des filtres. Le but étant de limiter la quantité de données pouvant être insérée dans les transactions.
Bitcoin -Datacarriersize
-Datacarriersize fait référence à « Op_Return » (créé en 2014). Cet opcode offre une alternative aux techniques plus nocives d’insertion de données arbitraires dans la blockchain, lorsque ne pas encrasser la blockchain était encore une évidence…
On décida donc de limiter la quantité de données arbitraires des transactions standards à 40 octets. C’est-à-dire de quoi entrer un hash SHA-256 (32 octets), plus quelques octets pour une balise d’identification, conformément à une suggestion de Satoshi :
« Je soutiens également un troisième type de transaction pour les données arbitraires de la taille d’un hachage d’horodatage. »
Le développeur Bitcoin Core Luke Dash considère comme un bug le fait que -datacarriersize n’ait pas été appliqué à toutes les données de transaction lors des soft forks Segwit et Taproot. Il a depuis développé le patch ordirespector sur son client Bitcoin Knot.
Le protocole stamps peut quant à lui ê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 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.
Ceux qui orchestrent cette attaque DDos devront alors recourir à des moyens laborieux nécessitant de s’allier directement avec les pools qui s’exposeront alors à la vindicte populaire.
Évidemment, la question d’une soft fork changeant les règles de consensus pourrait se poser si les choses empirent. Mais personne ne souhaite vraiment en arriver là.
Florilège de déclarations appelant à endiguer les inscriptions
Voici une liste de déclarations de développeurs sur Github allant dans le sens de la proposition de Luke Dash (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 arbitraires 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. »
« Nous avons déjà eu un débat à ce sujet et la communauté est parvenue à un consensus sur le fait que le seul schéma d’inscription légitime était op_return et qu’il devrait être limité à 40 (ou 80) octets. L’exploitation de méthodes d’inscription de données en dehors de op_return est un comportement antisocial en violation d’un large accord que nous avions et qui n’a jamais changé. L’exploitation de failles dans les script ne devrait pas être tolérée dans cette communauté, et surtout pas toléré dans le code source. »
-« 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 80 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 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 ? »
« Je pense fermement que le -datacarriersize devrait être mis à jour pour faire ce qu’il était réellement censé faire à l’origine (et non pas selon la documentation qui a été modifiée après que le spam ait commencé). »
Florilège de déclarations appelant à la passivité
Voici quelques arguments de la part 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 les nœuds déploient 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. »
« 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. »
« Même si Bitcoin Core modifiait sa politique par défaut, l’effet sur la propagation des transactions serait négligeable pendant longtemps. Certaines simulations de réseau que j’ai effectuées à propos de Full-RBF il y a quelques années ont indiqué qu’une minorité de 10 % de nœuds est déjà suffisante pour la propagation de transactions non standard avec une probabilité > 95 % (en supposant que l’expéditeur et le pool gèrent tous deux des nœuds joignables bien connectés). Le réseau a tendance à évoluer lentement vers des versions plus récentes, de sorte qu’il faudrait plusieurs années pour approcher le seuil clé de 10 %. »
-« 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 ses bitcoins comme il l’entend, même si le cas d’utilisation est déplaisant (pour quelque raison que ce soit). »
Voici l’un des nombreux ennemis du bitcoin avouant ses sombres desseins :
Pour votre serviteur, nous sommes en présence d’une attaque DDoS sophistiquée. Il est temps de se défendre avant que la mayonnaise ponzienne des ordinals, SRC-20 et autres ersatz de shitcoins ne prenne et ne provoque une hausse prématurée des frais de transaction.
Il en va par ailleurs de la décentralisation du réseau. Il n’y a pas péril en la demeure, mais une vulnérabilité est une vulnérabilité. S’en occuper ne devrait même pas prêter à débat.
Maximisez votre expérience Cointribune avec notre programme 'Read to Earn' ! Pour chaque article que vous lisez, gagnez des points et accédez à des récompenses exclusives. Inscrivez-vous dès maintenant et commencez à cumuler des avantages.
A
A
Reporting on Bitcoin, "the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy".
DISCLAIMER
Les propos et opinions exprimés dans cet article n'engagent que leur auteur, et ne doivent pas être considérés comme des conseils en investissement. Effectuez vos propres recherches avant toute décision d'investissement.