Les transactions doubles du Bitcoin : un bogue intrigant avec des risques minimes
TechFlow SélectionTechFlow Sélection
Les transactions doubles du Bitcoin : un bogue intrigant avec des risques minimes
Les transactions en double peuvent entraîner de la confusion, et les développeurs de Bitcoin se sont battus contre ce problème de diverses manières au fil des années.
Dédié à des analyses Web3 approfondies
Synthèse
Une transaction Bitcoin normale utilise au moins une sortie d'une transaction précédente en référençant l'identifiant de cette transaction (TXID). Ces sorties non dépensées ne peuvent être utilisées qu'une seule fois ; si elles pouvaient être dépensées deux fois, cela permettrait le double spending, rendant ainsi Bitcoin sans valeur. Cependant, il existe effectivement dans Bitcoin deux paires exactement identiques de transactions. Ce phénomène est possible parce que les transactions coinbase n'ont pas d'entrées, mais génèrent de nouvelles unités monétaires. Ainsi, deux transactions coinbase différentes peuvent envoyer le même montant vers la même adresse et être construites de manière identique, produisant alors des transactions totalement identiques. Étant donné que ces transactions sont identiques, leurs TXID coïncident également, car le TXID est le hachage (hash) des données de la transaction. La seule autre façon d'obtenir un TXID dupliqué serait une collision de hachage, ce qui est considéré comme hautement improbable et irréalisable pour une fonction cryptographique sécurisée. Aucune collision de hachage avec SHA256 n’a jamais été observée, ni dans Bitcoin ni ailleurs.
Ces deux paires de transactions dupliquées ont eu lieu à peu près simultanément, entre le 14 novembre 2010 à 08h37 UTC et le 15 novembre 2010 à 00h38 UTC, soit une période d'environ 16 heures. La première paire de doublons est encadrée par la seconde. Nous classons la transaction d5d2….8599 comme étant le premier doublon car elle est apparue en premier dans l'historique des duplications, bien qu’étrangement, sa première occurrence sur la blockchain intervienne après celle de l'autre transaction dupliquée, e3bf….b468.
Détails des transactions dupliquées
Dans les images ci-dessous, deux captures d'écran du navigateur de blocs mempool.space montrent la première transaction dupliquée apparaissant dans deux blocs différents.
Fait intéressant, lorsque l'on saisit les URL correspondantes dans un navigateur web, le navigateur de blocs mempool.space affiche par défaut, pour d5d2….8599, le bloc le plus ancien, tandis que pour e3bf….b468, il affiche par défaut le bloc le plus récent. Blockstream.info et Btcscan.org présentent le même comportement que mempool.space. En revanche, selon nos tests basiques, Blockchain.com et Blockchair.com adoptent un comportement différent : lorsqu’on saisit l’URL dans le navigateur, ils affichent toujours la version la plus récente de la transaction dupliquée.
Sur les quatre blocs concernés, un seul bloc (le bloc 91 812) contient d'autres transactions. Cette transaction fusionne une sortie de 1 BTC et une autre de 19 BTC en une seule sortie de 20 BTC.
Ces sorties peuvent-elles être dépensées ?
La présence de deux paires de TXID identiques crée un problème de référence pour les transactions ultérieures. Chaque transaction dupliquée vaut 50 BTC. Par conséquent, ces transactions impliquent au total 4 × 50 BTC = 200 BTC, ou selon une autre interprétation, potentiellement 2 × 50 BTC = 100 BTC. En réalité, 100 BTC n'existent pas véritablement. À ce jour, tous les 200 BTC restent non dépensés. Selon nos connaissances (nous pourrions nous tromper ici), si quelqu’un possédait les clés privées associées à ces sorties, il pourrait dépenser ces bitcoins. Toutefois, une fois dépensés, l’UTXO serait supprimé de la base de données, rendant ainsi les 50 BTC dupliqués indisponibles et perdus à jamais — seulement 100 BTC pourraient donc être récupérés. Quant à savoir si les pièces dépensées proviendraient du bloc le plus ancien ou du plus récent, cela pourrait être indéfini ou impossible à déterminer.
Une personne aurait pu dépenser tous les bitcoins avant la création des transactions dupliquées, puis créer des sorties dupliquées, ajoutant ainsi de nouvelles entrées dans la base de données des UTXO. Cela signifierait non seulement avoir des transactions dupliquées, mais aussi potentiellement des transactions dupliquant des sorties déjà dépensées. Si cela s’était produit, le dépensement de ces sorties aurait pu engendrer davantage de transactions dupliquées, créant ainsi une chaîne de doublons. Il aurait fallu faire très attention à l’ordre des événements, en dépensant toujours avant de créer des doublons, sinon des bitcoins auraient pu être perdus à jamais. Ces nouvelles transactions dupliquées n’auraient pas été des transactions coinbase, mais des transactions « normales ». Heureusement, cela ne s’est jamais produit.
Problèmes liés aux transactions dupliquées
Les transactions dupliquées sont clairement problématiques. Elles causent de la confusion pour les portefeuilles et les explorateurs de blocs, et rendent incertaine l’origine des bitcoins. Elles ouvrent aussi la porte à diverses attaques et vulnérabilités. Par exemple, vous pourriez payer quelqu’un deux fois avec deux transactions identiques. Lorsque le destinataire tenterait ensuite d’utiliser ces fonds, il pourrait découvrir que seulement la moitié des fonds est récupérable. Cela pourrait constituer une attaque contre une bourse visant à la ruiner, sans aucune perte pour l’attaquant, qui pourrait retirer les fonds immédiatement après un dépôt.
Interdire les transactions avec des TXID dupliqués
Pour atténuer ce problème, en février 2012, le développeur Bitcoin Pieter Wuille a proposé le fork souple BIP30, interdisant les transactions avec des TXID dupliqués, sauf si le TXID précédent a déjà été dépensé. Ce fork souple s'applique à tous les blocs postérieurs au 15 mars 2012.
En septembre 2012, le développeur Bitcoin Greg Maxwell a modifié cette règle afin que la vérification BIP30 s'applique désormais à tous les blocs, et non seulement à ceux postérieurs au 15 mars 2012, à l'exception notable des deux transactions dupliquées mentionnées plus haut. Cette mise à jour corrige certaines vulnérabilités de type attaque par déni de service (DOS). Techniquement, il s'agit d'un nouveau fork souple, bien que le changement de règle ne concerne que des blocs datant de plus de six mois, éliminant ainsi tout risque associé aux modifications habituelles du protocole.
La vérification BIP30 est coûteuse en calcul. Les nœuds doivent examiner toutes les sorties des transactions dans un nouveau bloc et vérifier si ces sorties existent déjà dans l'ensemble des UTXO. C’est probablement la raison pour laquelle Wuille n’avait initialement appliqué la vérification qu’aux sorties non utilisées. Une vérification complète sur toutes les sorties aurait été encore plus coûteuse et empêcherait toute forme d’élagage (pruning).
BIP34
En juillet 2012, le développeur Bitcoin Gavin Andresen a proposé le fork souple BIP34, activé en mars 2013. Ce changement de protocole exige que les transactions coinbase incluent la hauteur du bloc, permettant également une meilleure gestion des versions de blocs. La hauteur du bloc est ajoutée comme premier élément du scriptSig de la transaction coinbase. Le premier octet du scriptSig coinbase indique le nombre d’octets utilisés pour représenter la hauteur du bloc, suivis directement par la valeur de cette hauteur. Pour les 160 premières années (223 / (144 blocs par jour × 365 jours par an)), le premier octet devrait être 0x03. C’est pourquoi aujourd’hui, le scriptSig coinbase (en HEX) commence toujours par 03. Ce fork souple semble avoir résolu définitivement le problème des transactions dupliquées, rendant désormais toutes les transactions uniques.
Étant donné que BIP34 a été adopté, en novembre 2015, le développeur Bitcoin Alex Morcos a soumis une demande de fusion (pull request) au dépôt Bitcoin Core, modifiant le logiciel de sorte que les nœuds cessent d'effectuer la vérification BIP30. Après tout, puisque BIP34 avait corrigé le problème, cette vérification coûteuse n'était plus nécessaire. Bien que cela n’ait pas été reconnu à l’époque, techniquement, cela constituait un fork dur pour quelques blocs extrêmement rares à venir. Aujourd'hui, ce fork dur potentiel n'a plus d'importance, car presque personne n'utilise de logiciels de nœud antérieurs à novembre 2015. Sur forkmonitor.info, nous exécutons Bitcoin Core 0.10.3, publié en octobre 2015. Il s'agit donc d'une règle pré-fork dur, et le client continue d'effectuer la coûteuse vérification BIP30.
Le problème du bloc 983 702
Il s'avère que certains blocs antérieurs à l'activation de BIP34 contiennent des transactions coinbase dont le scriptSig commence par un octet correspondant par hasard à une hauteur de bloc future valide. Ainsi, bien que BIP34 ait corrigé le problème dans presque tous les cas, ce n’était pas une solution complète à 100 %. En 2018, le développeur Bitcoin John Newbery a publié la liste complète de ces cas potentiellement sujets à duplication, comme indiqué dans le tableau ci-dessous.
*Note : Les transactions coinbase de ces blocs n’ont pas été dupliquées en 2012 et 2017. Le bloc 209 921 (à seulement 79 blocs de la première halving) ne peut pas être dupliqué car BIP30 était alors appliqué.
Source : https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd
Nombre annuel de transactions coinbase potentiellement dupliquables
Source : https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd
Ainsi, le prochain bloc susceptible de produire une transaction dupliquée sera le bloc 1 983 702, qui devrait être miné vers janvier 2046. La transaction coinbase du bloc 164 384, miné en janvier 2012, envoie 170 BTC vers sept adresses de sortie différentes. Par conséquent, pour mener cette attaque en 2046, un mineur devrait non seulement avoir la chance de trouver précisément ce bloc, mais aussi brûler plus de 170 BTC en frais, avec un coût total légèrement supérieur à 170 BTC, incluant le coût d’opportunité de la subvention de bloc (0,09765625 BTC). Au prix actuel du bitcoin (88 500 USD), cela représenterait plus de 15 millions de dollars. On ignore à qui appartiennent les sept adresses de la transaction coinbase de 2012, et il est fort probable que les clés soient perdues. Actuellement, les sept sorties de cette transaction coinbase ont déjà été utilisées, dont trois dans une même transaction. Nous pensons que ces fonds pourraient être liés au système de Ponzi Pirate40, mais ceci reste pure spéculation. En somme, cette attaque semblerait non seulement extrêmement coûteuse, mais aussi presque inutile pour l’attaquant. Dépenser des millions simplement pour exclure d’un hard fork des nœuds datant de novembre 2015, vieux de 31 ans, paraît disproportionné.
Le prochain bloc vulnérable à la duplication est le bloc 169 985, miné en mars 2012. Sa transaction coinbase dépense légèrement plus de 50 BTC, bien moins que les 170 BTC du cas précédent. Bien sûr, 50 BTC était la subvention à l’époque, mais quand ce bloc deviendra vulnérable à la duplication en 2078, la subvention sera beaucoup plus faible. Pour exploiter cela, un mineur devrait brûler environ 50 BTC en frais, qu’il ne récupérerait jamais, car ces frais devraient être envoyés vers les sorties anciennes de 2012. Nul ne sait combien vaudra le bitcoin en 2078, mais le coût de cette attaque pourrait aussi être prohibitif. Par conséquent, ce problème n’est probablement pas un risque majeur pour Bitcoin, mais il reste néanmoins préoccupant.
Depuis la mise à jour SegWit en 2017, les transactions coinbase peuvent également inclure un engagement (commitment) vers toutes les transactions d’un bloc. Ces blocs antérieurs à BIP34 ne contiennent pas d’engagement witness. Ainsi, pour produire une transaction coinbase dupliquée, un mineur devrait omettre toute transaction de récupération d’une sortie SegWit dans le bloc, augmentant encore le coût d’opportunité, car le bloc ne pourrait alors inclure de nombreuses autres transactions génératrices de frais.
Conclusion
Compte tenu de la difficulté et du coût élevés requis pour dupliquer une transaction, ainsi que la rareté des opportunités d’exploitation, cette vulnérabilité des doublons de transactions ne semble pas constituer un problème de sécurité majeur pour Bitcoin. Toutefois, au vu des échelles temporelles impliquées et du caractère inhabituel de ces doublons, cela reste un sujet fascinant. Malgré tout, les développeurs y ont consacré beaucoup de temps au fil des ans, et la date de 2046 pourrait bien figurer dans l’esprit de certains développeurs comme une échéance ultime pour corriger ce bug. Plusieurs solutions sont envisageables, probablement via un fork souple. L'une des options possibles serait d'imposer systématiquement l'engagement SegWit.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@BitMEX
