Bitcoin répétition des transactions : une faille intéressante mais à très faible risque
Les transactions Bitcoin sont généralement effectuées en référant l'ID d'une transaction précédente pour utiliser des sorties non dépensées. Ces sorties ne peuvent être utilisées qu'une seule fois, sinon cela entraînera un double paiement, faisant perdre de la valeur au Bitcoin. Cependant, dans l'histoire du Bitcoin, il y a eu deux ensembles de transactions complètement identiques. Cette situation est possible car les transactions coinbase n'ont pas d'entrées de transaction, mais génèrent de nouveaux jetons. Ainsi, deux transactions coinbase différentes peuvent envoyer le même montant de jetons à la même adresse, de manière entièrement identique, produisant ainsi le même ID de transaction.
Ces deux séries de transactions répétées ont eu lieu du 14 au 15 novembre 2010, avec une durée d'environ 16 heures. La première série de transactions répétées est coincée entre la deuxième série. Nous classons les identifiants de transaction commençant par d5d2 comme la première transaction répétée, bien qu'elle soit apparue pour la première fois sur la blockchain après une autre transaction répétée.
L'apparition de transactions répétées a causé de la confusion pour les portefeuilles et les explorateurs de blocs, rendant difficile de déterminer l'origine des Bitcoins. Cela pourrait également entraîner des risques d'attaques et de vulnérabilités. Par exemple, il est possible de payer quelqu'un deux fois avec deux transactions répétées, alors qu'en réalité, seule la moitié des fonds est disponible.
Pour résoudre ce problème, un soft fork BIP30 a été mis en œuvre en mars 2012, interdisant l'utilisation d'ID de transaction dupliqués, sauf si le précédent a été dépensé. En septembre de la même année, cette règle a été modifiée pour s'appliquer à tous les blocs, à l'exception des deux premiers ensembles de transactions dupliquées. En mars 2013, le soft fork BIP34 exigeait que les transactions coinbase incluent la hauteur du bloc, ce qui semblait résoudre complètement le problème des transactions dupliquées.
Cependant, dans certains blocs avant l'activation de BIP34, le premier octet de scriptSig de la transaction coinbase correspond exactement à la hauteur de bloc qui sera valide à l'avenir. Cela signifie que dans certaines très rares circonstances, des transactions répétées peuvent encore se produire. Le prochain bloc où une transaction répétée pourrait apparaître est le 1,983,702, qui devrait être produit vers janvier 2046. Mais exploiter cette vulnérabilité est très coûteux, nécessitant de brûler une grande quantité de Bitcoin, ce qui est presque inutile pour l'attaquant.
Compte tenu de la difficulté et du coût de la copie des transactions, ainsi que de la rareté des opportunités d'en profiter, cette vulnérabilité ne constitue pas une menace majeure pour la sécurité du Bitcoin. Cependant, à long terme, les développeurs pourraient chercher à résoudre ce problème de manière définitive avant 2046, ce qui pourrait nécessiter une mise à niveau par soft fork. Une méthode possible de correction serait d'appliquer strictement l'engagement SegWit.
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.
Vulnérabilité de transactions répétées de Bitcoin : cas historiques rares et risques potentiels futurs
Bitcoin répétition des transactions : une faille intéressante mais à très faible risque
Les transactions Bitcoin sont généralement effectuées en référant l'ID d'une transaction précédente pour utiliser des sorties non dépensées. Ces sorties ne peuvent être utilisées qu'une seule fois, sinon cela entraînera un double paiement, faisant perdre de la valeur au Bitcoin. Cependant, dans l'histoire du Bitcoin, il y a eu deux ensembles de transactions complètement identiques. Cette situation est possible car les transactions coinbase n'ont pas d'entrées de transaction, mais génèrent de nouveaux jetons. Ainsi, deux transactions coinbase différentes peuvent envoyer le même montant de jetons à la même adresse, de manière entièrement identique, produisant ainsi le même ID de transaction.
Ces deux séries de transactions répétées ont eu lieu du 14 au 15 novembre 2010, avec une durée d'environ 16 heures. La première série de transactions répétées est coincée entre la deuxième série. Nous classons les identifiants de transaction commençant par d5d2 comme la première transaction répétée, bien qu'elle soit apparue pour la première fois sur la blockchain après une autre transaction répétée.
L'apparition de transactions répétées a causé de la confusion pour les portefeuilles et les explorateurs de blocs, rendant difficile de déterminer l'origine des Bitcoins. Cela pourrait également entraîner des risques d'attaques et de vulnérabilités. Par exemple, il est possible de payer quelqu'un deux fois avec deux transactions répétées, alors qu'en réalité, seule la moitié des fonds est disponible.
Pour résoudre ce problème, un soft fork BIP30 a été mis en œuvre en mars 2012, interdisant l'utilisation d'ID de transaction dupliqués, sauf si le précédent a été dépensé. En septembre de la même année, cette règle a été modifiée pour s'appliquer à tous les blocs, à l'exception des deux premiers ensembles de transactions dupliquées. En mars 2013, le soft fork BIP34 exigeait que les transactions coinbase incluent la hauteur du bloc, ce qui semblait résoudre complètement le problème des transactions dupliquées.
Cependant, dans certains blocs avant l'activation de BIP34, le premier octet de scriptSig de la transaction coinbase correspond exactement à la hauteur de bloc qui sera valide à l'avenir. Cela signifie que dans certaines très rares circonstances, des transactions répétées peuvent encore se produire. Le prochain bloc où une transaction répétée pourrait apparaître est le 1,983,702, qui devrait être produit vers janvier 2046. Mais exploiter cette vulnérabilité est très coûteux, nécessitant de brûler une grande quantité de Bitcoin, ce qui est presque inutile pour l'attaquant.
Compte tenu de la difficulté et du coût de la copie des transactions, ainsi que de la rareté des opportunités d'en profiter, cette vulnérabilité ne constitue pas une menace majeure pour la sécurité du Bitcoin. Cependant, à long terme, les développeurs pourraient chercher à résoudre ce problème de manière définitive avant 2046, ce qui pourrait nécessiter une mise à niveau par soft fork. Une méthode possible de correction serait d'appliquer strictement l'engagement SegWit.