Bitcoin Knots n’est rien de plus qu’une attaque par déni de service contre Bitcoin

En informatique, un attaque par déni de service (Attaque DoS; Royaume-Uni : /dɒs/ dos États-Unis : /dɑːs/ Daas^[1]) est une cyberattaque dans laquelle l’auteur cherche à rendre une machine ou une ressource réseau indisponible à ses utilisateurs prévus en perturbant temporairement ou indéfiniment les services d’un hôte connecté à un réseau. -La définition Wikipédia de l’attaque par déni de service.

C’est un concept très basique. Quelqu’un utilise ses propres ressources pour perturber le fonctionnement d’autres machines sur un réseau.

Les attaques DoS constituent un problème depuis aussi longtemps qu’Internet existe. L’une des « premières attaques par déni de service distribué (DDoS) » communément évoquée a eu lieu contre le fournisseur d’accès Internet (FAI) Panix au milieu des années 90. Il existait bien sûr de nombreux exemples techniques antérieurs sur des services Internet plus anciens, mais il s’agissait de l’un des premiers exemples majeurs, sinon du premier, d’une telle attaque contre le World Wide Web moderne.

Cette attaque a amené de nombreux ordinateurs à initier une connexion TCP (Transmission Control Protocol) avec les serveurs des FAI, mais sans jamais terminer le protocole de prise de contact qui a finalisé la connexion. Cela consomme les ressources du serveur pour gérer les connexions réseau et empêche les utilisateurs honnêtes d’accéder à Internet via les serveurs du FAI.

Depuis cette « première » attaque DDoS, elles sont aussi courantes sur Internet que les tempêtes le sont dans la nature, un phénomène régulier contre lequel d’énormes infrastructures Internet ont été construites pour se défendre.

La blockchain

La blockchain est l’un des composants essentiels de Bitcoin et une dépendance requise pour la fonctionnalité de Bitcoin en tant que grand livre distribué. Je suis sûr que de nombreuses personnes dans cet espace qualifieraient les transactions dites de « spam » d’attaque DoS sur la blockchain Bitcoin. Pour l’appeler ainsi, vous devez définir le « service » offert par la blockchain en tant que système et expliquer comment les transactions de spam refusent ce service à d’autres d’une manière qui n’est pas prévue par la conception du système.

Je parierais que la plupart des gens qui pensent que le spam est une attaque DoS diraient quelque chose comme « le service offert par la blockchain traite les transactions financières, et le spam enlève de l’espace aux personnes qui essaient de le faire ». Le problème est que ce n’est pas spécifiquement le service offert par la blockchain.

Le service qu’il propose réellement est la confirmation de n’importe lequel transaction valide par consensus via une vente aux enchères en temps réel qui se règle périodiquement chaque fois qu’un mineur trouve un bloc. Si votre transaction est valide par consensus et que vous avez proposé des frais suffisamment élevés pour qu’un mineur inclue votre transaction dans un bloc, vous utilisez le service fourni par la blockchain exactement comme prévu.

Il s’agit d’une décision de conception consciente prise au fil des années pendant la « guerre de la taille des blocs » et finalisée par l’activation de Segregated Witness et le rejet de l’augmentation de la taille des blocs Segwit2x via un hard fork poussé par les grandes entreprises de l’époque. La blockchain fonctionnerait en donnant la priorité aux transactions avec les frais d’enchères les plus élevés, et les utilisateurs seraient libres de participer à ces enchères. C’est ainsi que l’espace de blocs serait attribué, avec une restriction globale pour protéger la vérifiabilité et un mécanisme de tarification libre du marché.

Rien dans une transaction que certains définissent arbitrairement comme du « spam » gagnant dans cette enchère ouverte n’est un DoS de la blockchain. Il s’agit d’un utilisateur qui utilise cette ressource comme il est censé le faire, en participant à l’enchère avec tout le monde.

Le réseau relais

De nombreux nœuds Bitcoin, sinon la plupart, proposent le relais de transactions en tant que service vers le reste du réseau. Si vous diffusez vos transactions à vos pairs sur le réseau, ils les transmettront à leurs pairs, et ainsi de suite. Étant donné que la logique de peering qui décide avec quels nœuds peerer maintient une large connectivité, ce service permet aux transactions de se propager très rapidement sur le réseau, et leur permet spécifiquement de se propager à tous les nœuds miniers.

Un autre service est le relais de blocs, propageant les blocs valides au fur et à mesure qu’ils sont trouvés de la même manière. Cela a été hautement optimisé au fil des années, au point que la plupart du temps, un bloc entier n’est jamais réellement relayé, juste un « croquis » abrégé de l’en-tête du bloc et des transactions qu’il contient afin que vous puissiez les reconstruire à partir de votre propre pool de mémoire. En d’autres termes, les optimisations en relais de blocs dépendent d’un relais de transactions fonctionnant correctement et propageant toutes les transactions valides et susceptibles d’être minées.

Lorsque les nœuds n’ont pas déjà de transactions dans un bloc dans leur pool de mémoire, ils doivent les demander aux nœuds voisins, ce qui prend plus de temps pour valider le bloc dans le processus. Ils transmettent également explicitement ces transactions ainsi que l’esquisse de bloc à d’autres pairs au cas où ils les manqueraient, gaspillant ainsi la bande passante. Plus les nœuds classant les transactions comme spam sont nombreux, plus les blocs, y compris les transactions filtrées, mettent du temps à se propager sur le réseau.

Le filtrage des transactions cherche activement à perturber ces deux services, dans le cas où le relais des transactions échoue lamentablement à les empêcher de se propager aux mineurs, et dans le cas d’une propagation par blocs présentant une dégradation des performances marginale mais notable, plus les nœuds du réseau filtrent les transactions.

Ces politiques de nœuds ont pour objectif explicite de dégrader le service réseau de propagation des transactions vers les mineurs et le reste du réseau, et considèrent la dégradation de la propagation des blocs comme une pénalité pour les mineurs qui choisissent d’inclure les transactions valides qu’ils filtrent. Ils cherchent à créer une dégradation du service comme objectif et considèrent la dégradation d’un autre service résultant de cette tentative comme un résultat positif.

Il s’agit en fait d’une attaque DoS, dans le sens où elle dégrade un service réseau contrairement à la conception du système.

D’où vient-il d’ici ?

Toute la saga Knotz contre Core, ou « Spammeurs » contre « Filtreurs », n’a été rien de plus qu’une attaque DoS lamentablement inefficace et ratée sur le réseau Bitcoin. Les filtres ne font absolument rien pour empêcher les transactions filtrées d’être incluses dans les blocs. L’objectif consistant à perturber la propagation des transactions vers les mineurs n’a eu aucun succès, et la dégradation du relais de bloc a été suffisamment marginale pour ne pas dissuader les mineurs.

Je considère cela comme une énorme démonstration de la robustesse et de la résilience du Bitcoin face aux tentatives de censure et aux perturbations au niveau du réseau Bitcoin lui-même.

Et maintenant ?

Un BIP d’un auteur anonyme a été proposé pour adopter un softfork temporaire qui expirerait après environ un an, rendant invalides de nombreuses façons d’inclure le « spam » dans le consensus des transactions Bitcoin pendant cette période. Après avoir réalisé que l’attaque DoS sur le réseau peer-to-peer était un échec total, les partisans du filtre se sont tournés vers des changements consensuels, comme on l’avait dit à beaucoup d’entre eux il y a plus de deux ans.

Est-ce que cela résoudra réellement le problème ? Non, ce ne sera pas le cas. Cela obligera simplement les personnes qui souhaitent soumettre du « spam » à ce réseau dérivé, si elles le mettent réellement en œuvre, à utiliser de fausses ScriptPubKeys pour coder leurs données dans des sorties non utilisables qui gonfleront l’ensemble UTXO.

Ainsi, même si ce fork rencontrait un soutien retentissant, s’activait avec succès et n’entraînait pas de scission de chaîne, il n’atteindrait toujours pas l’objectif déclaré et ne laisserait aux « spammeurs » d’autre choix que de « spammer » de la manière la plus dommageable possible pour le réseau.