La faille se trouvait dans l’implémentation d’une règle de validation, pas dans la cryptographie ni dans le calendrier d’émission. Chaque sortie était positive, mais leur somme débordait vers une valeur négative. La différence entre l’entrée et ce total négatif apparaissait alors comme des frais. La version 0.3.10 a ajouté des plafonds pour chaque sortie et pour le total cumulé ; après la réorganisation vers la branche corrigée, le bloc fautif a quitté l’historique actif.
Le 15 août 2010, le développeur Jeff Garzik a signalé l’étrange bloc 74 638. La transaction 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9 dépensait une seule entrée de 0,50 BTC et créait deux sorties énormes. Le relevé printblock de l’époque indique 92 233 720 368,54275808 BTC pour chacune. L’auteur de la transaction exploitant la faille n’a pas été identifié de façon fiable : le registre public documente ses données, pas l’identité ni le motif de son créateur. [1]
Bitcoin représentait alors les montants par des entiers signés sur 64 bits en satoshis. La valeur entière de chaque sortie, également documentée en hexadécimal sous la forme 0x7ffffffffff85ee0, était positive et juste inférieure au maximum int64. Leur somme de 18 446 744 073 708 551 616 satoshis dépassait toutefois la plage et revenait à −1 000 000 satoshis. L’ancienne validation acceptait ce total négatif en le comparant à l’entrée. Il s’agissait d’une erreur arithmétique, pas d’une rupture des signatures. Le premier relevé JSON de la discussion comporte des derniers chiffres décimaux différents ; pour le calcul exact, nous retenons ici la valeur entière confirmée par printblock et par la notation hexadécimale. [1]
Le total négatif des sorties, −0,01 BTC, comparé à l’entrée de 0,50 BTC faisait apparaître des frais de 0,51 BTC. Le mineur a donc reçu 50,51 BTC dans la coinbase au lieu de la récompense de base de 50 BTC. Après déduction de l’entrée dépensée et prise en compte de l’excès de coinbase, les deux sorties géantes ont accru l’offre de la branche fautive d’exactement 18 446 744 073 709 551 616 satoshis : 2^64 satoshis, soit 184 467 440 737,09551616 BTC. Ce chiffre n’est donc pas la simple somme des deux sorties. [2]
La communauté réagit publiquement sous pression. Lfm qualifia le bug de grave, Gavin Andresen proposa de comparer rapidement chaque sortie à 21 millions de BTC et Satoshi Nakamoto publia une solution plus large : refuser toute sortie négative ou excessive et tout total progressif excessif après chaque addition. Satoshi demanda aussi aux mineurs de s’arrêter temporairement, afin qu’une nouvelle branche valide puisse rattraper et remplacer plus vite la branche fautive. [2]
Satoshi annonça la version 0.3.10 le 15 août 2010 à 23:48, heure du forum, environ cinq heures et quarante minutes après le signalement de Garzik. Les nœuds mis à jour considérèrent la transaction exploitant la faille et le bloc 74 638 comme invalides et construisirent sur le dernier bloc valide commun. L’annonce indiqua ensuite que la bonne branche avait dépassé la mauvaise, permettant au client mis à jour de se réorganiser sans supprimer manuellement les fichiers de blockchain. [3]
Aucun ancien bloc ne fut modifié dans une base centrale. Deux historiques concurrents existaient : les anciens nœuds acceptaient le bloc selon les règles initiales, tandis que les nœuds corrigés le refusaient et n’acceptaient que le travail au-dessus de l’ancêtre valide. Quand la branche réparée accumula davantage de Proof of Work, le réseau la suivit et le bloc inflationniste quitta l’historique actif ; l’installation des nouvelles règles par les utilisateurs et les mineurs, puis le travail ultérieur, furent décisifs, pas l’ordre d’un administrateur. [3]
La protection ajoutée alors reste visible dans Bitcoin Core. CheckTransaction refuse une sortie négative, une sortie supérieure à MAX_MONEY et un total progressif hors de MoneyRange ; vérifier après chaque addition empêche une somme dangereuse de déborder avant la comparaison. Un commentaire du code cite explicitement CVE-2010-5139, tandis que le contrôle distinct des entrées dupliquées rappelle l’autre incident CVE-2018-17144. [4]
L’incident montre que la limite de 21 millions n’est pas une constante magique protégée par le seul hachage : des règles précises de validation et leur implémentation correcte l’imposent. Un audit doit couvrir plages individuelles, addition sûre, coinbase et frais, ordre des contrôles, vecteurs de test aux limites et accord entre implémentations indépendantes. L’histoire montre aussi la rapidité de la communauté naissante et sa forte dépendance d’alors envers quelques développeurs, mineurs et une coordination manuelle. [5]
Pour une vision complète, lisez aussi Bitcoin Core, Règles de consensus, Transaction, UTXO, Reorg, Soft Fork.
01Y a-t-il déjà eu 184 milliards de BTC dans un Bitcoin valide ?+
Ils ont brièvement existé sur la branche fautive alors minée à cause du bloc d’exploitation. Les nœuds corrigés refusèrent cette branche et la branche valide la réorganisa ; les sorties géantes ne font donc partie ni de la blockchain active ni de l’ensemble UTXO actuels. L’incident historique reste attesté par le bloc et la réaction contemporaine.
02L’incident a-t-il brisé définitivement la limite de 21 millions ?+
Pas dans l’historique accepté aujourd’hui, car les règles corrigées rejetèrent le bloc fautif et ses sorties disparurent lors de la réorganisation. L’événement montra toutefois que la limite dépend d’une validation correcte et du logiciel réellement exécuté ; une phrase dans la documentation ne suffit pas à imposer l’offre.