Identifiez une éventuelle panne de bitcoin liée aux transactions en double

Alors que la communauté des collaborateurs de Bitcoin (BTC) débat des changements dans le client Bitcoin Core et l’élimination de la limite des transactions OP_return, le développeur Ruben Somsen a indiqué une défaillance potentielle du protocole.

Le problème détecté et lié à la proposition d’amélioration de Bitcoin 30 (BIP-30) sur sa règle de transactions en double, pourrait générer des risques dans un scénario improbable de réorganisation du réseau.

Un échec présumé, selon Somsen

Ruben Somsen, connu pour ses contributions à des propositions telles que Silent Payments, a publié le 27 avril 2025 une analyse de la liste de courrier de Bitcoindev, où identifié une défaillance dans BIP-30une proposition créée par Pieter Wuille et mise en œuvre en 2012 pour empêcher les transactions en double dans Bitcoin.

L’échec possible, bien que de faible probabilité, pourrait provoquer une bifurcation dans le réseau S’il y avait une réorganisation de blocs de l’année 2010, un scénario que les points de contrôle actuels (points de contrôle) atténuer. Cette bifurcation impliquerait un changement dans les règles qui nécessitent que tous les nœuds mettent à jour leur logiciel, également connu sous le nom de “fourchette».

Une réorganisation, quant à elle, se produit lorsque les nœuds bitcoins remplacent une chaîne de blocs par une chaîne plus longue, ce qui nécessite un immense effort de calcul pour les blocs de 2010.

Le BIP-30, actif du bloc Genèse jusqu’en mars 2013 (bloc 227 931, lorsque le BIP-34) a été activé, cherche à éviter cela Deux transactions avec le même identifiant (TXID) coexistent Dans le fichier si vos sorties n’ont pas été dépensées. Dans Bitcoin, chaque transaction génère des sorties non-SPENS (UTXO), qui sont les fonds disponibles à dépenser pour les transactions futures. Le BIP-30 vérifie qu’une nouvelle transaction ne croit pas une sortie existante Dans l’ensemble UTXO, qui pourrait provoquer une “confusion” dans les nœuds et permettre des dépenses doubles.

Somsen explique que le problème réside dans deux exceptions historiques des transactions Coinbase (qui génèrent de nouveaux Bitcoins dans chaque bloc) en 2010, situé dans les blocs 9172/91880 et 91812/91842.

Dans le bloc 91880, la transaction Coinbase a surmonté celle du bloc 91722, l’éliminant de l’ensemble UTXO. Si une réorganisation entre ces blocs se produit, les nœuds qui traitent la réorganisation élimineraient la sortie globale, tandis que les nœuds qui ne le témoigneraient pas le garderaient. Si cette sortie sera dépensée plus tard, Les nœuds auraient des ensembles UTXO incohérents, ce qui entraînerait une bifurcation.

«Le problème se produit lorsque nous réorganisons la blockchain à un point entre les blocs 91880 et 91722. La sortie globale disparaît complètement de l’ensemble UTXO. Cependant, un nœud qui n’a pas assisté à la réorganisation aura toujours cet UTXO dans son ensemble. Si cet UTXO est dépensé, cela entraînerait une bifurcation », explique Somsen.

Dans quelle mesure le risque est-il réel?

Le risque indiqué par Somsen est théorique, car il nécessite une réorganisation du réseau Bitcoin jusqu’en 2010, quelque chose pratiquement impossible En raison de l’énorme quantité de travail accumulée dans la chaîne et des points de contrôle qui, jusqu’en 2013, empêchent cette réorganisation. Cependant, la communauté envisage d’éliminer ces points de contrôlece que ferait l’échec “théoriquement exploitable”, mais pas pratique, selon le développeur.

Somsen ne préconise pas une action immédiate, car “le statu quo semble assez durable”. Cependant, il propose deux solutions pour atténuer le problème. La première consiste à interdire les réorganisations partielles entre les blocs 91722 et 91880, forçant les nœuds à réorganiser les 160 blocs complets ou aucun. “Étant donné qu’ils ne sont que 160 blocs avec la faible difficulté minière de 2010, ce ne serait pas une grande restriction”, explique-t-il.

La deuxième solution, suggérée après des discussions avec le développeur Sjors Provoost, profite de l’élimination possible de points de contrôleconsidéré comme un fourchette (changer incompatible avec les versions précédentes). Ce permettrait de modifier les règles de consensus d’avant 2013 Pour empêcher l’élimination des transactions Coinbase des blocs 91880 et 91842 lors de la réorganisation, ce qui corrigerait l’échec.

Bip-30 Inefficacité: analyse de Somsen

Au-delà de l’insuffisance consensuelle, Somsen met en évidence l’inefficacité du BIP-30, ce qui nécessite Vérifiez l’intégralité de l’ensemble UTXO pour chaque transactionun processus coûteux en termes de calcul. Cette vérification compliquerait des méthodes de validation alternatives exposées par Somsen, comme UtreeExo, qui réduirait la taille de l’ensemble UTXO, SwiftTSync, qui accélère la synchronisation des nœuds, et le zérosync, basé sur des tests de connaissances zéro (zéro connaissance).

Le développeur propose de remplacer cette vérification par un cache de transactions Coinbase (TXIDS), qui occuperait environ 7 Mo pour bloquer 227931, garantissant que Il n’y a pas de doublons. En outre, cela suggère de vérifier que les transactions Coinbase n’influent pas avec les règles BIP-34, ce qui garantit le caractère unique de ces transactions, même en cas de réorganisation. “Nous pouvons remplacer la vérification inefficace de l’ensemble BIP-30 UTXO par une vérification de l’unicité Coinbase”, explique Somsen.

La réponse de Luke Dashjr

Le développeur Luke Dashjr, CTO et co-fondateur du bassin minier de Bitcoin Ocean, ont répondu à la proposition de Somsen avec deux solutions supplémentaires.

Le premier suggère de traiter l’écrasement d’une transaction comme une dépense, restaurant l’UTXO d’origine. Le second propose de ne pas créer l’UTXO qui sera écrasé lorsqu’il est détecté pour la première fois.

Cependant, DashJr remet en question la proposition de SOMSE d’utiliser un cache TXID, faisant valoir que la vérification de 7 Mo de données par transaction C’est moins efficace que de comparer 64 octets. “Cela semble strictement pire que la façon dont nous le gérons aujourd’hui”, a-t-il déclaré.

Dans Bitcoin, la méthode actuelle pour identifier une transaction est basée sur la comparaison du TXID, qui est le hachage de transaction. Ce hachage est généré à l’aide de SHA-256 et sa taille est de 32 octets.

DashJR pourrait penser à un contexte où deux hachages de 32 octets sont comparés (par exemple, un TXID et un autre identifiant), qui ajouteraient 64 octets. Cependant, dans la vérification BIP-30, seul un TXID de 32 octets est utilisé par transaction.

Un débat pour l’avenir du bitcoin

L’analyse de Somsen, soutenue par des discussions avec des experts tels que Antoine Poinsot, Pieter Wuille et Sjors Provoost, met sur le tableau un échec qui, bien que distant, souligne l’importance de revoir les règles de consensus de Bitcoin.

L’échec du BIP-30 ne représente pas une menace immédiate pour les utilisateurs de Bitcoin, mais son identification reflète l’engagement des développeurs envers la sécurité du réseau créé par Satoshi Nakamoto.