Le jour où 184 milliards de bitcoins ont été créés

Le message de Garzik était bref et factuel. Il montrait le hash de la transaction et deux sorties gigantesques. Un relevé printblock publié ensuite dans la même discussion en précisait la valeur : chacune contenait 92 233 720 368,54275808 BTC. Le bloc comprenait aussi une transaction coinbase distincte versant 50,51 BTC au mineur. Face à la récompense de base habituelle de cinquante bitcoins, ces deux sorties paraissaient absurdes : quelqu’un venait de créer plus de 184 milliards d’unités.

Derrière la transaction, il n'y avait pas de nom connu ni d'explication publique. La chaîne conservée indique ce qui s'est passé, mais pas qui a exploité la faille et dans quel but. Identifier l'auteur comme un hacker spécifique signifierait ajouter une information que les sources ne possèdent pas. Ce qui est certain, c'est que la transaction a été conçue pour atteindre un point faible de la validation.

Le réseau l'a acceptée car l'ancien code vérifiait les sorties individuelles puis leur somme. Chacune des sorties géantes était contenue dans le type numérique utilisé, mais lors de l'addition, elles dépassaient ensemble sa limite supérieure. Le nombre a débordé dans la zone négative et la vérification ultérieure a incorrectement conclu qu'aucune valeur positive non autorisée n'était créée.

Il ne s'agissait donc pas d'une contrefaçon de signature, d'une modification d'une transaction antérieure ou d'une prise de contrôle de la majorité du hashrate. L'attaquant a exploité la façon dont une implémentation spécifique traitait les nombres entiers. La règle mathématique « ne délivre pas plus que ce qui entre » était correcte ; le programme ne l'a pas exécutée comme ses concepteurs l'avaient prévu en raison du débordement.

Le bloc appartenait déjà à la chaîne suivie par le réseau. Chaque nœud utilisant la version défectueuse le considérait comme valide, et les mineurs pouvaient construire dessus. Rendre le problème public ne suffisait donc pas. Il fallait agir avant que l'historique erroné se propage davantage et que les montants gigantesques commencent à circuler.

La limite de 21 millions est souvent décrite comme une loi immuable de Bitcoin. L'incident a montré une image plus précise. La limite est un ensemble de règles de consensus que chaque programme et chaque nœud complet doit exécuter sans erreur. Si toutes les versions de nœuds couramment utilisées partagent la même implémentation erronée, ils peuvent temporairement accepter un état qui contredit l'intention.

Le débordement d'un nombre entier est un vieux problème de programmation. Un registre informatique n'a pas une portée infinie ; après avoir dépassé la valeur limite, les opérations arithmétiques suivantes peuvent se terminer à un endroit complètement différent de l'axe numérique. Dans un système comptable, un tel détail est crucial. La somme doit être vérifiée non seulement après le calcul, mais aussi pendant celui-ci, et chaque montant doit rester dans la plage autorisée.

Le Bitcoin Core d'aujourd'hui effectue donc plusieurs vérifications distinctes. La sortie ne peut pas être négative, ne peut pas dépasser la réserve monétaire maximale, et la somme en cours est révalidée après chaque ajout. Ces lignes n'ont pas été créées comme une précaution abstraite. Elles portent la mémoire de l'événement au cours duquel une protection manquante a permis au réseau d'enregistrer une transaction économiquement impossible.

L'erreur montre également la différence entre la spécification et l'attente sociale. Personne dans le forum n'a sérieusement affirmé que les grosses pièces étaient légitimes simplement parce que l'ancien logiciel les avait acceptées. Les participants étaient d'accord pour dire qu'il s'agissait d'une violation de la règle intentionnelle. Cet accord nécessitait cependant un moyen technique : une nouvelle version qui rejetterait le bloc défectueux.

C'est ici que le code et les gens se rencontrent. Le code décide de manière déterministe quel bloc un nœud accepte. Les gens décident quel code installer lorsqu'ils découvrent une contradiction avec les règles intentionnelles. L'incident n'a pas été un vote sur une nouvelle émission ; c'était une course pour rétablir la règle que la communauté considérait déjà comme la base du système.

Le dépassement de capacité est traître précisément parce que la machine ne perçoit pas l'absurdité qu'un humain reconnaît instantanément. Le processeur opère sur un nombre stocké dans un espace limité ; si le calcul dépasse sa borne, le résultat peut se replier dans une autre partie de la plage. L'ancien code contrôlait les sorties individuelles, mais lors de l'addition, il ne maintenait pas la somme courante dans des limites sûres. La transaction a donc traversé plusieurs conditions localement raisonnables, et pourtant enfreint leur sens global. La correction devait être concrète : il ne suffisait pas d'écrire dans un commentaire qu'il n'y aurait jamais plus de 21 millions de bitcoins. Chaque nœud avait besoin d'une règle capable d'imposer réellement cette affirmation à chaque calcul.

Après l'annonce, une recommandation est apparue sur le forum invitant à suspendre temporairement la réception des transactions et le minage. Chaque nouveau bloc au-dessus de la transaction défectueuse aurait augmenté la quantité de travail qui devrait être abandonnée. Dans un réseau sans interrupteur central, Satoshi ne pouvait pas arrêter le minage. Il ne pouvait que publier une correction et convaincre les opérateurs de l'exécuter.

La version 0.3.10 a introduit les vérifications de montant correctes et a rejeté le bloc 74 638. Les nœuds corrigés sont revenus au dernier point valide commun et les mineurs ont commencé à construire une branche alternative sans la transaction inflationniste. Les deux historiques ont concouru pendant un certain temps selon le travail accumulé.

Satoshi a ensuite annoncé que la bonne chaîne avait dépassé la mauvaise. Le logiciel mis à jour a effectué une réorganisation de la chaîne et le bloc défectueux a disparu de l'historique actif. Les transactions de la branche qui n'étaient pas elles-mêmes non valides ont pu revenir dans la file d'attente et être réincorporées plus tard ; les sorties géantes, cependant, n'auraient pas pu exister selon les nouvelles vérifications.

Cette correction a eu un coût. Les mineurs sur la branche abandonnée ont perdu des récompenses et les utilisateurs ont dû accepter que plusieurs heures d'historique ne soient pas poursuivies. En 2010, le réseau était petit et la coordination était rapide. La même intervention dans un écosystème beaucoup plus grand aurait signifié plus de participants économiques, de variantes de logiciel et de désaccords sur les limites exactes de la correction.

La rapidité de la réaction est souvent présentée comme une intervention miraculeuse de Satoshi. Elle reposait en réalité sur des étapes observables : Garzik rendit le problème public, d’autres analysèrent le dépassement de capacité, les développeurs préparèrent la modification, les opérateurs installèrent une nouvelle version du client Bitcoin et les mineurs apportèrent du travail à la bonne branche. L’auteur pouvait proposer une correction ; encore fallait-il que le réseau l’adopte réellement.

Après la correction, le nombre de bitcoins valides est revenu dans le cadre intentionnel et les milliards défectueux n'ont pas pu être dépensés dans la chaîne continue. L'incident n'a donc pas abouti à une inflation permanente. Cependant, ce n'est pas seulement une curiosité de la version bêta. C'est un rappel que la sécurité monétaire ne vient pas d'un slogan, mais d'un programme vérifié à plusieurs reprises.

Bitcoin est souvent présenté comme étant opposé aux systèmes dans lesquels une autorité centrale change l'offre par décision. Même ici, cependant, les gens n'ont pas disparu. Les développeurs écrivent des implémentations, les réviseurs recherchent des erreurs, les opérateurs choisissent des versions et les mineurs créent l'ordre des blocs. La différence est que l'intervention est publique et que chaque nœud peut rejeter les règles avec lesquelles il n'est pas d'accord.

L'événement explique également la prudence avec laquelle le code de consensus est modifié aujourd'hui. Une petite optimisation de l'arithmétique peut avoir un impact monétaire. Les tests, les vérifications d'implémentation multiples et la révision lente ne sont pas une bureaucratie supplémentaire ; ils constituent une défense contre la répétition du moment où quelques bits ont transformé des milliards d'un nombre non autorisé en un nombre apparemment valide.

Jeff Garzik n'a pas rendu le réseau sécurisé avec une seule publication sur le forum, mais a montré l'avantage d'un livre comptable public. Chacun pouvait voir le bloc étrange, recalculer ses sorties et vérifier la correction. L'erreur n'était pas cachée dans une base de données interne d'un opérateur. Elle était visible pour toute la communauté, avec la preuve que les anciens nœuds l'avaient acceptée.

La limite de l'offre a donc survécu à l'incident d'une manière différente de ce que suggère le mot « immuable ». Non pas parce que le logiciel ne pouvait pas échouer, mais parce que l'échec était visible, qu'il existait une règle partagée à laquelle on pouvait revenir, et que suffisamment de participants ont effectué la correction. L'histoire des 184 milliards de bitcoins n'est pas une négation de une offre plafonnée. C'est l'histoire de ce qu'il faut vraiment pour la maintenir.

Cet événement rappelle aussi que la nature publique du code ne suffit pas, en soi, à éliminer une erreur. Le code ouvert a permis aux gens de repérer, de comparer et de corriger le problème sans attendre un fournisseur unique, mais ce fut l'attention de participants précis qui fut décisive. Il a fallu que quelqu'un remarque des nombres impossibles, que quelqu'un trouve la condition défectueuse et que les exploitants adoptent la mise à jour. La transparence a créé la possibilité de contrôle ; c'est l'action qui l'a transformée en défense du réseau. C'est pourquoi cette histoire reste importante même après des années : la sécurité de Bitcoin ne réside pas dans l'idée d'un programme originel parfait, mais dans la combinaison de règles précises, de vérification indépendante et de la capacité de réagir à une erreur sans la dissimuler.