Récemment, une proposition visant à supprimer la limitation de la taille des sorties OP_Return dans la bibliothèque logicielle Bitcoin Core a suscité des discussions sur ce qui constitue des transactions indésirables sur la blockchain Bitcoin et comment les gérer. Cet article revient sur l'attaque par des transactions indésirables subie par le réseau Bitcoin à l'été 2015, compare la situation d'alors et celle d'aujourd'hui, et explore les leçons à en tirer.
L'attaque de transactions indésirables de l'été 2015 a été l'un des premiers affrontements dans la bataille sur la taille des blocs. Les partisans des grands blocs estiment que la limite de 1 Mo est trop petite, ce qui rend les blocs facilement remplissables par des transactions indésirables, et espèrent augmenter la limite pour rendre le remplissage des blocs plus coûteux. Les partisans des petits blocs pensent que cette idée est un pas en arrière, car permettre aux transactions indésirables d'entrer rapidement en chaîne revient à donner la victoire aux attaquants.
attaque de transaction par déni de service
Première ronde
Le 20 juin 2015, un échange de portefeuille Bitcoin nommé CoinWallet.eu a annoncé qu'il procéderait à un "test de résistance Bitcoin". Ils ont clairement indiqué que c'était pour prouver la nécessité d'augmenter la limite de taille des blocs. L'attaque est prévue pour le 22 juin, avec un plan de générer 1 Mo de données de transaction toutes les 5 minutes, ce qui entraînera un retard de 241 blocs.
Le 24 juin, les attaquants ont annoncé que leur attaque n'avait pas réussi comme prévu, car le serveur s'est effondré après que le mempool ait atteint environ 12 Mo. Ils ont dépensé environ 2 bitcoins en frais pour cette attaque ratée.
Deuxième tour
Le même jour, CoinWallet.EU a annoncé que la deuxième attaque aurait lieu le 29 juin. Cette attaque semble être plus efficace, certains utilisateurs signalant que le Bitcoin est devenu difficile à utiliser. Le pool minier Eligius de Luke-Jr a réussi à filtrer les transactions indésirables, produisant des blocs beaucoup plus petits que ceux des autres pools miniers. Cela a soulevé un débat sur la question de savoir si le filtrage des transactions affecte la fongibilité du Bitcoin.
troisième round
Le 7 juillet, une troisième attaque a eu lieu, bien qu'elle n'ait pas été officiellement annoncée, son impact est le plus important. Selon les rapports, il y avait entre 27 000 et 80 000 transactions dans le pool de mémoire. Les attaquants ont utilisé diverses stratégies pour générer des transactions de spam, telles que l'envoi de transactions de poussière à des portefeuilles publics et l'envoi de petites quantités de Bitcoin à des adresses de clés privées connues. Cette attaque a coûté plus de 8 000 dollars de frais.
F2Pool a aidé à nettoyer le désordre en intégrant les sorties de transactions indésirables de 1 Mo. Gregory Maxwell a ensuite aidé F2Pool à améliorer la méthode d'intégration, rendant les transactions plus faciles à vérifier.
quatrième tour
En septembre 2015, CoinWallet a effectué sa dernière série de tests de pression. Ils ont utilisé différentes méthodes, publiant directement des clés privées avec des soldes sur le forum. Cela a entraîné la génération de plus de 90 000 transactions, mais comme beaucoup étaient des transactions conflictuelles, l'impact n'était pas aussi grave que lors de la troisième série.
Quant aux cerveaux derrière CoinWallet.EU, il n'y a actuellement aucune preuve concluante pour tirer des conclusions.
Analyse académique
Un article académique a analysé les attaques de transactions indésirables de 2015. Les données montrent que la taille du pool de mémoire a connu deux pics majeurs, atteignant environ 175 000 transactions. L'étude a révélé que, pendant les 10 jours de pointe, 23,41 % des transactions étaient des transactions indésirables, ce qui a eu un impact négatif sur les transactions normales, augmentant les frais de 51 % en moyenne et multipliant par 7 les délais de traitement.
Conclusion
L'attaque de spam sur Bitcoin en 2015 a eu un impact considérable, non seulement sur la stratégie de relais sur le plan technique, mais aussi sur la perception des transactions de spam sur Bitcoin. Le réseau a ensuite subi quelques changements :
Les mineurs ont augmenté la stratégie de limitation de la taille des blocs de 250 Ko ou 750 Ko à 1 Mo.
Les frais de relais minimum dans Bitcoin Core ont augmenté de 5 fois.
Introduction d'une limitation de la mémoire pool et d'une taille de mémoire pool par défaut de 300 Mo.
A intensifié les tensions et la polarisation dans le débat sur la limite de taille des Blocs.
Les partisans des petits blocs ont finalement gagné ce débat. Les blocs pleins sont désormais la norme, et l'idée d'augmenter la limite de taille des blocs pour permettre plus de transactions indésirables sur la chaîne a été rejetée. Cependant, le débat sur ce qui constitue une transaction indésirable et comment les traiter se poursuit.
En comparant la situation de 2015 avec celle récente, nous pouvons voir que les attaques de transactions indésirables ne sont pas une nouveauté. Les intentions malveillantes des attaquants en 2015 étaient peut-être plus claires que les actions récentes générant des transactions liées à JPEG. Une autre comparaison intéressante est la dépense des frais, en 2015 environ 10 000 dollars causaient un impact significatif, tandis que récemment plusieurs centaines de millions de dollars ont été dépensés dans des transactions "indésirables".
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
8 J'aime
Récompense
8
5
Partager
Commentaire
0/400
rug_connoisseur
· 07-28 00:32
Je veux frapper mon clavier en le voyant, même les vieux déchets de 2015 sont remis au goût du jour.
Voir l'originalRépondre0
ContractCollector
· 07-27 20:51
Bloc taille débat sujet éternel ah
Voir l'originalRépondre0
MEVSandwichMaker
· 07-26 19:43
Que signifie un bloc explosé, ce n'est pas comme si nous ne l'avions jamais vu.
Voir l'originalRépondre0
MetaverseHobo
· 07-26 19:34
Les leçons ont été données aux chiens, le petit Bloc PI fait toujours semblant de dormir.
Voir l'originalRépondre0
ponzi_poet
· 07-26 19:28
Héhé, encore un test nul. C'est clairement pour créer des problèmes.
Retour sur l'attaque de trading de déchets Bitcoin de 2015 : un point de vue historique sur les controverses actuelles
Récemment, une proposition visant à supprimer la limitation de la taille des sorties OP_Return dans la bibliothèque logicielle Bitcoin Core a suscité des discussions sur ce qui constitue des transactions indésirables sur la blockchain Bitcoin et comment les gérer. Cet article revient sur l'attaque par des transactions indésirables subie par le réseau Bitcoin à l'été 2015, compare la situation d'alors et celle d'aujourd'hui, et explore les leçons à en tirer.
L'attaque de transactions indésirables de l'été 2015 a été l'un des premiers affrontements dans la bataille sur la taille des blocs. Les partisans des grands blocs estiment que la limite de 1 Mo est trop petite, ce qui rend les blocs facilement remplissables par des transactions indésirables, et espèrent augmenter la limite pour rendre le remplissage des blocs plus coûteux. Les partisans des petits blocs pensent que cette idée est un pas en arrière, car permettre aux transactions indésirables d'entrer rapidement en chaîne revient à donner la victoire aux attaquants.
attaque de transaction par déni de service
Première ronde
Le 20 juin 2015, un échange de portefeuille Bitcoin nommé CoinWallet.eu a annoncé qu'il procéderait à un "test de résistance Bitcoin". Ils ont clairement indiqué que c'était pour prouver la nécessité d'augmenter la limite de taille des blocs. L'attaque est prévue pour le 22 juin, avec un plan de générer 1 Mo de données de transaction toutes les 5 minutes, ce qui entraînera un retard de 241 blocs.
Le 24 juin, les attaquants ont annoncé que leur attaque n'avait pas réussi comme prévu, car le serveur s'est effondré après que le mempool ait atteint environ 12 Mo. Ils ont dépensé environ 2 bitcoins en frais pour cette attaque ratée.
Deuxième tour
Le même jour, CoinWallet.EU a annoncé que la deuxième attaque aurait lieu le 29 juin. Cette attaque semble être plus efficace, certains utilisateurs signalant que le Bitcoin est devenu difficile à utiliser. Le pool minier Eligius de Luke-Jr a réussi à filtrer les transactions indésirables, produisant des blocs beaucoup plus petits que ceux des autres pools miniers. Cela a soulevé un débat sur la question de savoir si le filtrage des transactions affecte la fongibilité du Bitcoin.
troisième round
Le 7 juillet, une troisième attaque a eu lieu, bien qu'elle n'ait pas été officiellement annoncée, son impact est le plus important. Selon les rapports, il y avait entre 27 000 et 80 000 transactions dans le pool de mémoire. Les attaquants ont utilisé diverses stratégies pour générer des transactions de spam, telles que l'envoi de transactions de poussière à des portefeuilles publics et l'envoi de petites quantités de Bitcoin à des adresses de clés privées connues. Cette attaque a coûté plus de 8 000 dollars de frais.
F2Pool a aidé à nettoyer le désordre en intégrant les sorties de transactions indésirables de 1 Mo. Gregory Maxwell a ensuite aidé F2Pool à améliorer la méthode d'intégration, rendant les transactions plus faciles à vérifier.
quatrième tour
En septembre 2015, CoinWallet a effectué sa dernière série de tests de pression. Ils ont utilisé différentes méthodes, publiant directement des clés privées avec des soldes sur le forum. Cela a entraîné la génération de plus de 90 000 transactions, mais comme beaucoup étaient des transactions conflictuelles, l'impact n'était pas aussi grave que lors de la troisième série.
Quant aux cerveaux derrière CoinWallet.EU, il n'y a actuellement aucune preuve concluante pour tirer des conclusions.
Analyse académique
Un article académique a analysé les attaques de transactions indésirables de 2015. Les données montrent que la taille du pool de mémoire a connu deux pics majeurs, atteignant environ 175 000 transactions. L'étude a révélé que, pendant les 10 jours de pointe, 23,41 % des transactions étaient des transactions indésirables, ce qui a eu un impact négatif sur les transactions normales, augmentant les frais de 51 % en moyenne et multipliant par 7 les délais de traitement.
Conclusion
L'attaque de spam sur Bitcoin en 2015 a eu un impact considérable, non seulement sur la stratégie de relais sur le plan technique, mais aussi sur la perception des transactions de spam sur Bitcoin. Le réseau a ensuite subi quelques changements :
Les partisans des petits blocs ont finalement gagné ce débat. Les blocs pleins sont désormais la norme, et l'idée d'augmenter la limite de taille des blocs pour permettre plus de transactions indésirables sur la chaîne a été rejetée. Cependant, le débat sur ce qui constitue une transaction indésirable et comment les traiter se poursuit.
En comparant la situation de 2015 avec celle récente, nous pouvons voir que les attaques de transactions indésirables ne sont pas une nouveauté. Les intentions malveillantes des attaquants en 2015 étaient peut-être plus claires que les actions récentes générant des transactions liées à JPEG. Une autre comparaison intéressante est la dépense des frais, en 2015 environ 10 000 dollars causaient un impact significatif, tandis que récemment plusieurs centaines de millions de dollars ont été dépensés dans des transactions "indésirables".