Der Tag, an dem 184 Milliarden Bitcoin entstanden

Garziks Beitrag war kurz und sachlich. Er zeigte den Transaktionshash und zwei gewaltige Outputs. Ein späterer printblock-Auszug in derselben Diskussion nannte ihren genauen Wert: Jeder enthielt 92.233.720.368,54275808 BTC. Zum Block gehörte außerdem eine separate Coinbase-Transaktion mit einer Auszahlung von 50,51 BTC an den Miner. Neben der üblichen Grundbelohnung von fünfzig Bitcoin wirkten die beiden Outputs absurd: Jemand hatte gerade mehr als 184 Milliarden Einheiten erzeugt.

Hinter der Transaktion stand weder ein bekannter Name noch eine öffentliche Erklärung. Die erhaltene Blockchain zeigt, was passiert ist, aber nicht, wer den Fehler ausnutzte und mit welchem Ziel. Einen bestimmten Hacker als Urheber zu nennen, würde der Geschichte eine Behauptung hinzufügen, die von den Quellen nicht gedeckt ist. Fest steht, dass die Transaktion gezielt eine Schwachstelle der Validierung ausnutzte.

Das Netzwerk akzeptierte die Transaktion, weil der alte Code zunächst die einzelnen Outputs und dann ihre Summe prüfte. Jeder der riesigen Beträge passte für sich in den verwendeten Zahlentyp. Zusammen überschritten sie jedoch dessen Obergrenze. Die Summe lief in den negativen Bereich über, und die anschließende Prüfung kam fälschlich zu dem Ergebnis, dass kein unzulässiger positiver Betrag erzeugt wurde.

Es handelte sich also nicht um eine Fälschung der Signatur, eine Änderung einer älteren Transaktion oder die Übernahme der Mehrheit der Hashrate. Der Angreifer nutzte die Art und Weise, wie eine bestimmte Implementierung mit ganzen Zahlen umging. Die mathematische Regel „erstelle nicht mehr, als hereinkommt“ war korrekt; das Programm führte sie aufgrund des Überlaufs nicht so durch, wie die Menschen es beabsichtigt hatten.

Der Block gehörte bereits zu der Kette, der das Netzwerk folgte. Jeder Knoten mit der fehlerhaften Version hielt ihn für gültig, und weitere Miner konnten darauf aufbauen. Die öffentliche Warnung allein reichte deshalb nicht. Die Community musste handeln, bevor sich die fehlerhafte Historie weiter verbreitete und die riesigen Outputs ausgegeben wurden.

Die Grenze von 21 Millionen wird oft als unveränderliches Gesetz von Bitcoin beschrieben. Der Vorfall zeigte genauer, was dahintersteht: Konsensregeln, die jedes Programm und jeder Full Node korrekt ausführen muss. Enthalten alle verbreiteten Knotenversionen dieselbe fehlerhafte Implementierung, können sie vorübergehend einen Zustand akzeptieren, der dem beabsichtigten Regelwerk widerspricht.

Ein Ganzzahlüberlauf ist ein seit Langem bekanntes Programmierproblem. Ein Computerregister hat einen begrenzten Wertebereich. Wird dessen Grenze überschritten, kann die Rechnung auf der anderen Seite der Zahlengeraden landen. Für ein Buchhaltungssystem ist dieses Detail entscheidend: Die Summe muss schon während der Berechnung geprüft werden, nicht erst danach, und jeder Betrag muss im zulässigen Bereich bleiben.

Bitcoin Core führt daher mehrere separate Kontrollen durch. Ein Output darf nicht negativ sein, darf die maximale Geldmenge nicht überschreiten und die laufende Summe wird nach jedem Hinzufügen erneut überprüft. Diese Zeilen entstanden nicht als abstrakte Vorsichtsmaßnahme. Sie tragen die Erinnerung an das Ereignis, bei dem eine fehlende Absicherung es dem Netzwerk ermöglichte, eine wirtschaftlich unmögliche Transaktion aufzuzeichnen.

Der Fehler zeigt auch den Unterschied zwischen Spezifikation und gesellschaftlicher Erwartung. Niemand im Forum behauptete ernsthaft, dass die riesigen Münzen legitim seien, nur weil sie von der alten Software akzeptiert wurden. Die Teilnehmer stimmten darin überein, dass es sich um eine Verletzung der beabsichtigten Regel handelte. Diese Übereinstimmung benötigte jedoch ein technisches Mittel: eine neue Version, die den fehlerhaften Block ablehnt.

Genau hier treffen sich Code und Menschen. Der Code entscheidet deterministisch, welchen Block ein Knoten akzeptiert. Die Menschen entscheiden, welchen Code sie installieren, wenn sie einen Widerspruch zu den beabsichtigten Regeln entdecken. Der Vorfall war kein Votum über eine neue Emission; es war ein Wettlauf um die Wiederherstellung der Regel, die die Community bereits als Grundlage des Systems betrachtete.

Überlauf ist gerade deshalb tückisch, weil die Maschine die Absurdität nicht erkennt, die ein Mensch sofort bemerkt. Der Prozessor arbeitet mit einer Zahl, die in einem begrenzten Speicherplatz abgelegt ist; überschreitet die Berechnung dessen Grenze, kann das Ergebnis in einen anderen Bereich des Wertebereichs umrollen. Der alte Code prüfte einzelne Ausgaben, hielt aber beim Addieren die Zwischensumme nicht innerhalb sicherer Grenzen. Die Transaktion erfüllte daher mehrere lokal sinnvolle Bedingungen und verletzte dennoch deren Gesamtbedeutung. Die Behebung musste konkret sein: Es reichte nicht, in einem Kommentar zu schreiben, dass es nie mehr als 21 Millionen geben werde. Jeder Knoten brauchte eine Regel, die diesen Satz in jeder Berechnung tatsächlich durchsetzen konnte.

Nach der Meldung erschien im Forum die Empfehlung, Transaktionen vorübergehend nicht zu akzeptieren und nicht zu minen. Jeder neue Block über der fehlerhaften Transaktion würde die Menge an Arbeit, die aufgegeben werden muss, vergrößern. In einem Netzwerk ohne zentralen Ausschalter konnte Satoshi den Mining-Prozess nicht stoppen. Er konnte nur eine Korrektur veröffentlichen und die Betreiber überzeugen, sie zu starten.

Die Version 0.3.10 führte die richtigen Kontrollen der Beträge ein und lehnte den Block 74.638 ab. Die korrigierten Knoten kehrten zum letzten gemeinsamen gültigen Punkt zurück und die Miner begannen, eine alternative Verzweigung ohne die inflatorische Transaktion zu bauen. Die beiden Historien konkurrierten für eine bestimmte Zeit anhand ihrer angesammelten Rechenarbeit.

Satoshi meldete anschließend, dass die korrekte Kette die fehlerhafte überholt hatte. Die aktualisierte Software führte eine Reorganisation der Kette durch, und der fehlerhafte Block verschwand aus der aktiven Historie. Transaktionen aus dem verworfenen Zweig konnten in die Warteschlange zurückkehren und später erneut aufgenommen werden, sofern sie selbst gültig waren. Die riesigen Outputs bestanden die neuen Prüfungen dagegen nicht.

Diese Korrektur hatte einen Preis. Die Miner auf der aufgegebenen Verzweigung verloren ihre Belohnungen und die Benutzer mussten akzeptieren, dass einige Stunden der Historie nicht fortgesetzt werden würden. Im Jahr 2010 war das Netzwerk klein und die Koordination schnell. Ein gleicher Eingriff in einem viel größeren Ökosystem würde mehr wirtschaftliche Teilnehmer, Software-Varianten und Streitigkeiten über die genaue Grenze der Korrektur bedeuten.

Die schnelle Reaktion wird oft als wundersames Eingreifen Satoshis dargestellt. Tatsächlich bestand sie aus nachvollziehbaren Schritten: Garzik veröffentlichte das Problem, andere untersuchten den Überlauf, Entwickler bereiteten die Änderung vor, Betreiber installierten eine neue Version des Bitcoin-Clients, und Miner lieferten die Arbeit für den richtigen Zweig. Der Autor konnte eine Reparatur vorschlagen; das Netzwerk musste sie aber tatsächlich übernehmen.

Nach der Korrektur kehrte die Anzahl der gültigen Bitcoin in den beabsichtigten Rahmen zurück und die fehlerhaften Milliarden konnten nicht in der fortgesetzten Kette ausgegeben werden. Der Vorfall endete also nicht mit einer dauerhaften Inflation. Er ist jedoch nicht nur eine Kuriosität aus der Beta-Version. Er ist eine Erinnerung daran, dass die finanzielle Sicherheit nicht aus einem Slogan, sondern aus einem wiederholt überprüften Programm resultiert.

Bitcoin wird oft gegen Systeme gestellt, in denen eine zentrale Autorität die Angebotsmenge durch Entscheidungen ändert. Auch hier sind die Menschen jedoch nicht verschwunden. Die Entwickler schreiben Implementierungen, die Rezensenten suchen nach Fehlern, die Betreiber wählen Versionen und die Miner erstellen die Reihenfolge der Blöcke. Der Unterschied liegt darin, dass der Eingriff öffentlich ist und jeder Knoten die Regeln ablehnen kann, mit denen er nicht einverstanden ist.

Das Ereignis erklärt auch die Vorsicht, mit der der Konsens-Code heute geändert wird. Eine kleine Optimierung der Arithmetik kann eine finanzielle Konsequenz haben. Tests, mehr Implementierungskontrollen und eine langsame Überprüfung sind keine zusätzliche Bürokratie; sie sind eine Verteidigung gegen die Wiederholung des Moments, in dem einige Bits Milliarden von einer unzulässigen Zahl in eine scheinbar gültige umgewandelt haben.

Jeff Garzik hat das Netzwerk nicht durch einen einzigen Forenbeitrag sicher gemacht, sondern die Vorteile einer öffentlichen Buchhaltung gezeigt. Jeder konnte den ungewöhnlichen Block sehen, seine Ausgaben erneut berechnen und die Korrektur überprüfen. Der Fehler war nicht in einer internen Datenbank des Betreibers verborgen. Er lag vor der gesamten Community, zusammen mit dem Beweis, dass die alten Knoten ihn akzeptiert hatten.

Die Angebotsbegrenzung hat den Vorfall also auf eine andere Weise überlebt, als das Wort „unveränderlich“ nahelegt. Nicht, weil die Software nicht fehlerhaft sein konnte, sondern weil das Versagen sichtbar war, es ein gemeinsames Regelwerk gab, zu dem man zurückkehren konnte, und genügend Teilnehmer die Korrektur durchführten. Die Geschichte von 184 Milliarden Bitcoin ist keine Verneinung der festen Angebotsbegrenzung. Sie ist die Geschichte dessen, was ihre Aufrechterhaltung tatsächlich erfordert.

Der Vorfall erinnert auch daran, dass die öffentliche Zugänglichkeit des Codes den Fehler an sich nicht beseitigt. Der offene Quellcode ermöglichte es Menschen, das Problem nachzuspüren, zu vergleichen und zu beheben, ohne auf einen einzelnen Anbieter warten zu müssen, aber entscheidend war die Aufmerksamkeit konkreter Beteiligter. Jemand musste die unmöglichen Zahlen bemerken, jemand die fehlerhafte Bedingung finden, und die Betreiber mussten das Update annehmen. Die Transparenz schuf die Möglichkeit der Kontrolle; erst das Handeln verwandelte sie in einen Schutz des Netzwerks. Deshalb ist die Geschichte auch nach Jahren noch wichtig: Die Sicherheit von Bitcoin beruht nicht auf der Vorstellung eines perfekten Originalprogramms, sondern auf der Kombination aus präzisen Regeln, unabhängiger Überprüfung und der Fähigkeit, auf einen Fehler zu reagieren, ohne ihn zu verschleiern.