Der Fehler lag in der Umsetzung einer Validierungsregel, nicht in der Kryptografie oder im Ausgabeplan. Jeder Output war positiv, doch ihre Summe lief in einen negativen Wert über. Die Differenz zwischen Input und negativer Summe erschien dann als Gebühr. Version 0.3.10 ergänzte Obergrenzen für einzelne Outputs und die laufende Summe; nach der Reorganisation auf den korrigierten Zweig gehörte der fehlerhafte Block nicht mehr zur aktiven Historie.
Am 15. August 2010 machte Entwickler Jeff Garzik auf den merkwürdigen Block 74 638 aufmerksam. Die Transaktion 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9 gab einen einzigen Input von 0,50 BTC aus und erzeugte zwei riesige Outputs. Der damalige printblock-Auszug beziffert jeden auf 92 233 720 368,54275808 BTC. Der Urheber der Exploit-Transaktion wurde nicht zuverlässig identifiziert: Die öffentliche Aufzeichnung belegt ihre Daten, nicht seine Identität oder sein Motiv. [1]
Bitcoin stellte Beträge damals als vorzeichenbehaftete 64-Bit-Ganzzahlen in Satoshi dar. Der ganzzahlige Wert jedes Outputs, auch hexadezimal als 0x7ffffffffff85ee0 dokumentiert, war positiv und lag knapp unter dem int64-Maximum. Ihre Summe von 18 446 744 073 708 551 616 Satoshi überschritt jedoch den Wertebereich und sprang auf −1 000 000 Satoshi. Die alte Validierung akzeptierte diese negative Summe beim Vergleich mit dem Input. Das war ein Rechenfehler, kein Bruch der Signaturen. Der erste JSON-Auszug im Diskussionsthread weist andere letzte Nachkommastellen auf. Für die genaue Rechnung verwenden wir hier den ganzzahligen Wert, den sowohl printblock als auch die Hexadezimaldarstellung bestätigen. [1]
Die negative Outputsumme von −0,01 BTC ergab gegenüber dem Input von 0,50 BTC eine scheinbare Gebühr von 0,51 BTC. Der Miner beanspruchte deshalb in der Coinbase 50,51 BTC statt der Grundbelohnung von 50 BTC. Nach Abzug des ausgegebenen Inputs und unter Einbeziehung des Coinbase-Überschusses erhöhten die beiden riesigen Outputs den Bestand des fehlerhaften Zweigs um genau 18 446 744 073 709 551 616 Satoshi: 2^64 Satoshi oder 184 467 440 737,09551616 BTC. Diese Zahl ist also nicht einfach die Summe der beiden Outputs. [2]
Die Gemeinschaft reagierte öffentlich unter Zeitdruck. Lfm nannte den Fehler ernst, Gavin Andresen schlug einen schnellen Vergleich jedes Outputs mit 21 Millionen BTC vor, und Satoshi Nakamoto veröffentlichte eine breitere Lösung: negative oder zu hohe Outputs sowie nach jeder Addition eine zu hohe laufende Summe ablehnen. Satoshi bat Miner auch um eine vorübergehende Pause, damit ein neuer gültiger Zweig den fehlerhaften schneller einholen und ersetzen konnte. [2]
Satoshi kündigte Version 0.3.10 am 15. August 2010 um 23:48 Forumszeit an, ungefähr fünf Stunden und vierzig Minuten nach Garziks Meldung. Aktualisierte Nodes stuften Exploittransaktion und Block 74 638 als ungültig ein und bauten auf dem letzten gemeinsamen gültigen Block. Die damalige Ankündigung meldete später, der gute Zweig habe den schlechten überholt, sodass ein aktualisierter Client ohne manuelles Löschen der Blockchain-Dateien automatisch reorganisieren konnte. [3]
Kein alter Block wurde in einer zentralen Datenbank bearbeitet. Zwei konkurrierende Verläufe bestanden: Alte Nodes akzeptierten den Block nach den ursprünglichen Regeln, gepatchte Nodes lehnten ihn ab und akzeptierten nur Arbeit über dem gültigen Vorfahren. Als der reparierte Zweig mehr Proof of Work angesammelt hatte, folgte ihm das Netzwerk und der Inflationsblock verließ die aktive Historie; entscheidend waren die Installation der neuen Regeln durch Nutzer und Miner sowie die nachfolgende Arbeit, nicht die Anweisung eines Administrators. [3]
Der damals eingeführte Schutz ist bis heute in Bitcoin Core sichtbar. CheckTransaction verwirft negative Outputs, Outputs über MAX_MONEY und laufende Summen außerhalb von MoneyRange; die Prüfung nach jeder Addition verhindert einen Überlauf vor dem Vergleich. Ein Quelltextkommentar verweist ausdrücklich auf CVE-2010-5139, während die separate Prüfung doppelter Inputs an den anderen Vorfall CVE-2018-17144 erinnert. [4]
Der Vorfall zeigt, dass die Grenze von 21 Millionen keine allein durch Hashing geschützte magische Konstante ist: Präzise Validierungsregeln und ihre korrekte Umsetzung erzwingen sie. Ein Audit muss die Wertebereiche einzelner Beträge, sichere Addition, Coinbase und Gebühren, Reihenfolge der Prüfungen, Grenztestvektoren und Übereinstimmung unabhängiger Implementierungen erfassen. Die Geschichte zeigt zugleich schnelle Reparaturfähigkeit und die damalige starke Abhängigkeit von wenigen Entwicklern, Minern und manueller Koordination. [5]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Bitcoin Core, Konsensregeln, Transaktion, UTXO, Reorg, Soft Fork.
01Existierten jemals 184 Milliarden BTC in einem gültigen Bitcoin?+
Sie existierten kurz auf dem damals geschürften fehlerhaften Zweig als Folge des Exploitblocks. Gepatchte Nodes lehnten diesen Zweig ab, der gültige Zweig reorganisierte ihn, daher gehören die riesigen Outputs weder zur heutigen aktiven Blockchain noch zum heutigen UTXO-Satz. Der historische Vorfall selbst ist durch Block und zeitgenössische Reaktion dokumentiert.
02Brach der Vorfall die Grenze von 21 Millionen dauerhaft?+
Nicht in der heute akzeptierten Geschichte, denn die korrigierten Konsensregeln lehnten den fehlerhaften Block ab und seine Outputs verschwanden bei der Reorganisation. Das Ereignis zeigte aber, dass die Grenze von korrekter Validierung und tatsächlich betriebener Software abhängt; eine Aussage in der Dokumentation erzwingt das Angebot nicht.