Bitcoin : un phénomène de transactions répétées : un défaut système rare
Aperçu
Les transactions Bitcoin utilisent généralement des sorties non dépensées en se référant à l'ID de la transaction précédente. Ces sorties ne peuvent être dépensées qu'une seule fois, sinon un problème de double dépense se produira. Cependant, il existe effectivement deux ensembles de transactions complètement identiques dans le système Bitcoin. Cette situation se produit parce que les transactions coinbase n'ont pas d'entrées, mais génèrent directement de nouveaux jetons. Par conséquent, deux transactions coinbase différentes peuvent envoyer le même montant à la même adresse, de manière entièrement identique, produisant ainsi le même ID de transaction. En dehors de cela, la seule possibilité de répétition de l'ID de transaction est une collision de hachage, mais cela est presque impossible avec la technologie cryptographique actuelle.
Ces deux ensembles de transactions répétées ont eu lieu entre le 14 et le 15 novembre 2010, sur une période d'environ 16 heures. Le premier ensemble de transactions répétées (d5d2....8599) est intercalé entre le second, bien qu'il soit apparu plus tard sur la blockchain.
Détails des transactions répétées
Le navigateur de blockchain indique que la première transaction répétée apparaît dans deux blocs différents. Les différents navigateurs de blockchain présentent certaines différences dans l'affichage de ces transactions répétées, certains affichant par défaut le bloc le plus ancien, tandis que d'autres affichent le bloc le plus récent.
Dans les quatre blocs concernés, seul un bloc (,812) contient d'autres transactions, fusionnant 1 Bitcoin et 19 Bitcoin en 20 Bitcoin.
Traitement des sorties répétées
En raison de l'existence de deux ensembles d'ID de transaction identiques, ces transactions dupliquées impliquent au total 200 BTC, ou peuvent être comprises comme 100 BTC. À ce jour, ces 200 BTC n'ont pas été dépensés. Théoriquement, la personne possédant les clés privées associées peut dépenser ces Bitcoins, mais une fois dépensés, les 50 BTC en double ne pourront plus être utilisés et seront perdus, donc en réalité, seuls 100 BTC peuvent être récupérés. Quant à partir de quel bloc ces jetons seront déduits après avoir été dépensés, cela reste encore indéterminé.
Problème de transactions répétées
Les transactions répétées peuvent causer de la confusion pour les portefeuilles et les explorateurs de blocs, et brouiller l'origine du Bitcoin. Cela peut également être utilisé pour des attaques, par exemple en payant quelqu'un deux fois avec deux transactions répétées, alors qu'en réalité, seule la moitié des fonds est disponible. Cela peut être utilisé pour attaquer des échanges, en essayant de provoquer des erreurs dans leurs fonds.
Solution
Pour résoudre le problème des transactions en double, un soft fork BIP30 a été mis en œuvre en mars 2012, interdisant l'utilisation d'ID de transaction en double, sauf si la transaction précédente a été dépensée. En septembre de la même année, cette règle a été modifiée pour s'appliquer à tous les blocs.
En mars 2013, le BIP34 a exigé que les transactions coinbase contiennent la hauteur du bloc, ce qui a essentiellement résolu le problème des transactions en double. Par la suite, les nœuds ont cessé de vérifier le BIP30, car cette vérification coûteuse n'était plus nécessaire.
Problèmes potentiels futurs
Bien que le BIP34 ait résolu la plupart des problèmes, dans certains blocs avant son activation, le premier octet du scriptSig de la transaction coinbase correspondait exactement à la hauteur de bloc qui sera valide dans le futur. Cela signifie qu'il est toujours possible d'avoir des transactions en double à certaines hauteurs de blocs spécifiques dans le futur.
Le prochain bloc susceptible de provoquer des transactions répétées est le 1,983,702, qui devrait être produit vers janvier 2046. Exploiter cette vulnérabilité nécessiterait que les mineurs dépensent une somme considérable, qui pourrait dépasser 15 millions de dollars selon le prix actuel du Bitcoin, avec presque aucun bénéfice réel.
Le bloc de risque potentiel suivant est 169985, qui pourrait être copié en 2078. De même, le coût d'exploitation de cette vulnérabilité pourrait également être très élevé.
Conclusion
Compte tenu de la difficulté de copier les transactions, des coûts et de la rareté des opportunités, cette vulnérabilité ne constitue pas une menace majeure pour la sécurité de Bitcoin. Néanmoins, les développeurs continuent de travailler à des solutions et il pourrait être nécessaire d'utiliser un soft fork pour résoudre ce problème. Une méthode possible serait d'imposer l'engagement SegWit.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
15 J'aime
Récompense
15
5
Partager
Commentaire
0/400
rugpull_survivor
· Il y a 11h
Regardez ce bug, pas mal ! Pour nous, les pauvres, c'est à peu près tout ce qu'on peut se permettre comme divertissement.
Voir l'originalRépondre0
ZenChainWalker
· Il y a 11h
Ce bug de Mining dure depuis 13 ans. Je me souviens que je ne dormais pas en regardant cela.
Voir l'originalRépondre0
ImpermanentPhilosopher
· Il y a 11h
Ce bug est un peu trop tôt, n'est-ce pas ?
Voir l'originalRépondre0
ser_we_are_ngmi
· Il y a 11h
Le bug de 2010... C'est vraiment l'histoire sombre de l'univers de la cryptomonnaie.
Analyse des vulnérabilités de transactions répétées du Bitcoin : causes historiques, risques potentiels et défis futurs
Bitcoin : un phénomène de transactions répétées : un défaut système rare
Aperçu
Les transactions Bitcoin utilisent généralement des sorties non dépensées en se référant à l'ID de la transaction précédente. Ces sorties ne peuvent être dépensées qu'une seule fois, sinon un problème de double dépense se produira. Cependant, il existe effectivement deux ensembles de transactions complètement identiques dans le système Bitcoin. Cette situation se produit parce que les transactions coinbase n'ont pas d'entrées, mais génèrent directement de nouveaux jetons. Par conséquent, deux transactions coinbase différentes peuvent envoyer le même montant à la même adresse, de manière entièrement identique, produisant ainsi le même ID de transaction. En dehors de cela, la seule possibilité de répétition de l'ID de transaction est une collision de hachage, mais cela est presque impossible avec la technologie cryptographique actuelle.
Ces deux ensembles de transactions répétées ont eu lieu entre le 14 et le 15 novembre 2010, sur une période d'environ 16 heures. Le premier ensemble de transactions répétées (d5d2....8599) est intercalé entre le second, bien qu'il soit apparu plus tard sur la blockchain.
Détails des transactions répétées
Le navigateur de blockchain indique que la première transaction répétée apparaît dans deux blocs différents. Les différents navigateurs de blockchain présentent certaines différences dans l'affichage de ces transactions répétées, certains affichant par défaut le bloc le plus ancien, tandis que d'autres affichent le bloc le plus récent.
Dans les quatre blocs concernés, seul un bloc (,812) contient d'autres transactions, fusionnant 1 Bitcoin et 19 Bitcoin en 20 Bitcoin.
Traitement des sorties répétées
En raison de l'existence de deux ensembles d'ID de transaction identiques, ces transactions dupliquées impliquent au total 200 BTC, ou peuvent être comprises comme 100 BTC. À ce jour, ces 200 BTC n'ont pas été dépensés. Théoriquement, la personne possédant les clés privées associées peut dépenser ces Bitcoins, mais une fois dépensés, les 50 BTC en double ne pourront plus être utilisés et seront perdus, donc en réalité, seuls 100 BTC peuvent être récupérés. Quant à partir de quel bloc ces jetons seront déduits après avoir été dépensés, cela reste encore indéterminé.
Problème de transactions répétées
Les transactions répétées peuvent causer de la confusion pour les portefeuilles et les explorateurs de blocs, et brouiller l'origine du Bitcoin. Cela peut également être utilisé pour des attaques, par exemple en payant quelqu'un deux fois avec deux transactions répétées, alors qu'en réalité, seule la moitié des fonds est disponible. Cela peut être utilisé pour attaquer des échanges, en essayant de provoquer des erreurs dans leurs fonds.
Solution
Pour résoudre le problème des transactions en double, un soft fork BIP30 a été mis en œuvre en mars 2012, interdisant l'utilisation d'ID de transaction en double, sauf si la transaction précédente a été dépensée. En septembre de la même année, cette règle a été modifiée pour s'appliquer à tous les blocs.
En mars 2013, le BIP34 a exigé que les transactions coinbase contiennent la hauteur du bloc, ce qui a essentiellement résolu le problème des transactions en double. Par la suite, les nœuds ont cessé de vérifier le BIP30, car cette vérification coûteuse n'était plus nécessaire.
Problèmes potentiels futurs
Bien que le BIP34 ait résolu la plupart des problèmes, dans certains blocs avant son activation, le premier octet du scriptSig de la transaction coinbase correspondait exactement à la hauteur de bloc qui sera valide dans le futur. Cela signifie qu'il est toujours possible d'avoir des transactions en double à certaines hauteurs de blocs spécifiques dans le futur.
Le prochain bloc susceptible de provoquer des transactions répétées est le 1,983,702, qui devrait être produit vers janvier 2046. Exploiter cette vulnérabilité nécessiterait que les mineurs dépensent une somme considérable, qui pourrait dépasser 15 millions de dollars selon le prix actuel du Bitcoin, avec presque aucun bénéfice réel.
Le bloc de risque potentiel suivant est 169985, qui pourrait être copié en 2078. De même, le coût d'exploitation de cette vulnérabilité pourrait également être très élevé.
Conclusion
Compte tenu de la difficulté de copier les transactions, des coûts et de la rareté des opportunités, cette vulnérabilité ne constitue pas une menace majeure pour la sécurité de Bitcoin. Néanmoins, les développeurs continuent de travailler à des solutions et il pourrait être nécessaire d'utiliser un soft fork pour résoudre ce problème. Une méthode possible serait d'imposer l'engagement SegWit.