Die Nacht, in der Bitcoin zwei gültige Geschichten hatte

Block 225 430 wurde nicht mit der Absicht erstellt, das Netz zu teilen. Er enthielt jedoch mehr Transaktions-Eingänge als bisherige Blöcke und belastete damit die Datenbank auf eine Weise, die den Unterschied zwischen den Versionen aufdeckte. Bitcoin 0.8 verwendete LevelDB und verarbeitete den Block. Version 0.7 mit Berkeley DB stieß auf die Anzahl der Sperren und endete mit einem Fehler.

Die Ursache war gefährlich unscheinbar. Beide Gruppen von Knoten befolgten die Regeln so, wie ihre Software sie umsetzen konnte. Der neuere Zweig verstieß nicht gegen die beabsichtigten Konsensregeln, und die älteren Knoten waren keinem Angriff ausgesetzt. Ein undokumentiertes praktisches Limit einer Datenbanktechnologie hatte das Netzwerk gespalten.

Miner mit Version 0.8 bauten auf dem neuen Block auf. Miner mit älteren Versionen setzten fort, wo sein Vorgänger aufgehört hatte. Sobald beide Zweige weitere Blöcke erhielten, musste eine bestätigte Zahlung auf einer nicht unbedingt auf der anderen existieren. Ein Benutzer konnte nicht sicher auf die übliche Anzahl der Bestätigungen vertrauen, bis klar war, welche Geschichte die wirtschaftliche Mehrheit akzeptieren würde.

Hinter dem neueren Zweig standen zunächst rund sechzig Prozent der Rechenleistung. Normalerweise würde sich die Kette mit mehr angesammelter Arbeit durchsetzen. Doch die älteren Knoten konnten den neuen Block nicht akzeptieren, unabhängig davon, wie viel Arbeit auf ihm aufbaute. Eine Reorganisation kann keinen Block gültig machen, den die lokale Prüfsoftware ablehnt.

Der Vorfall zeigte damit die Grenze der einfachen Faustregel „Die längste Kette gewinnt“. Genauer gesagt wählt ein Knoten die Kette mit der größten angesammelten Arbeit aus denjenigen aus, die er zuvor als gültig anerkannt hat. Sind sich die Knoten schon bei der Gültigkeit uneinig, reicht die Hashrate allein nicht aus, um das Netzwerk sofort wieder zusammenzuführen.

Die Entwickler bemerkten das Problem, als sich die Höhen und Hashes der überwachten Knoten zu unterscheiden begannen. Die Kommunikation konzentrierte sich auf den IRC-Kanal, wo man Log-Dateien, Leistungen der Zweige und Reaktionen großer Pools vergleichen konnte. Gavin Andresen verfasste später in BIP 50 eine Zeitleiste und die Entscheidungen, die während der Nacht getroffen wurden.

Es ging nicht um die Wahl zwischen einem eindeutig richtigen und einem offensichtlich falschen Zweig. Wer Version 0.8 unterstützte, erhielt die Kette mit mehr Arbeit, schloss aber viele ältere Knoten aus. Zurück zum Zweig der Version 0.7 zu gehen bedeutete dagegen, die Miner mit neuer Software zum Verzicht zu bewegen: Sie sollten Blöcke aufgeben, die sie nach ihren Regeln gültig geschürft hatten und für die sie eine Belohnung erwarteten.

Für die Rückkehr sprach vor allem die Kompatibilität. Version 0.8 konnte die kleineren Blöcke des älteren Zweigs akzeptieren. Die Knoten mit Version 0.7 konnten den problematischen Block des neueren Zweigs hingegen nicht verarbeiten. Würde die Rechenleistung auf einen für beide Gruppen gültigen Zweig wechseln, könnte sich das Netzwerk wieder vereinen, ohne sofort alle älteren Knoten zu einem Upgrade zu zwingen.

Die Entscheidung war kein Befehl, den Andresen über das Protokoll erteilen konnte. Entwickler kontaktierten die Pool-Betreiber und erklärten die Lage. Börsen wurde empfohlen, Einzahlungen auszusetzen. Bitcoin.org veröffentlichte eine Warnung und bat große Pools, zur älteren Softwareversion zurückzukehren, damit sich das Netzwerk auf einem kompatiblen Zweig wieder vereinen konnte.

Diese Koordination war schnell, weil der Kreis der Schlüsselteilnehmer noch relativ klein war und die Leute sich aus öffentlichen Kanälen kannten. Die Geschwindigkeit half, das Netzwerk vor einer längeren Spaltung zu retten, zeigte aber auch die sozialen Bindungen, auf denen der frühe Betrieb basierte. Bitcoin hatte keinen Chef; er hatte jedoch Leute, deren Anruf oder Nachricht einen großen Anteil der Leistung verschieben konnte.

Das IRC-Gespräch hatte weder rechtliche Verbindlichkeit noch einen geheimen Admin-Schlüssel. Seine Bedeutung lag darin, dass es an einem Ort Menschen mit unterschiedlichen Einflussmöglichkeiten zusammenbrachte. Entwickler konnten die Ursache erklären, Mining-Pools konnten Hashrate umleiten, Börsen Einzahlungen stoppen und Knotenbetreiber ihre Version wechseln. Jeder Schritt trug sein eigenes Risiko, und niemand konnte garantieren, dass die anderen mitziehen würden. Die Entscheidung, den mit der Version 0.7 kompatiblen Zweig zu unterstützen, war daher kein technischer Befehl aus dem Zentrum des Netzwerks, sondern eine koordinierte Wette darauf, dass dieser Weg die gemeinsame Historie am schnellsten mit dem geringsten Einfluss auf die Nutzer wiederherstellen würde. Der Erfolg lässt sich nicht von der damals geringen Größe der Community trennen und darf auch nicht als universelles Krisenverfahren ausgegeben werden.

Den entscheidenden Schritt machten BTCGuild unter Michael Marsee, bekannt als Eleuthria, und der von Marek Palatinus betriebene Slush Pool. Beide Betreiber wechselten von Version 0.8 zurück auf 0.7 und richteten ihre Rechenleistung auf den älteren Zweig. Dadurch verschob sich das Verhältnis der angesammelten Arbeit zwischen den beiden Ketten.

Dieser Verzicht kostete echtes Geld. Bei der Reorganisation fielen die Blöcke des aufgegebenen Zweigs aus der Hauptkette heraus; ihre Blockbelohnungen konnten dort nicht mehr ausgegeben werden. BIP 50 hält ausdrücklich fest, dass die Pools erhebliche Einnahmen opferten, um das Netzwerk wieder auf einer gemeinsamen Kette zusammenzubringen.

Sobald der ältere Zweig mehr Arbeit angesammelt hatte, konnten ihn auch die Knoten mit Version 0.8 akzeptieren und ihre bisherige Kette reorganisieren. Die älteren Knoten arbeiteten bereits auf diesem Zweig. Keine Softwareversion hatte die andere aus der Ferne überschrieben. Vielmehr hatten genügend Miner eine Kette mit mehr Arbeit aufgebaut, deren Blöcke beide Versionen prüfen konnten.

Während des Vorfalls kam es zu mindestens einem größeren Double Spend. Er wurde als Experiment beschrieben, nicht als vorsätzlicher Angriff. Trotzdem machte er das Risiko deutlich: Eine Transaktion konnte auf einem Zweig bestätigt werden, der später aufgegeben wurde. Die Empfehlung, Einzahlungen auszusetzen, sollte Dienste davor schützen, Kundenguthaben auf Grundlage einer nur vorübergehend gültigen Transaktionshistorie gutzuschreiben.

Die Pools besaßen das Netzwerk dadurch nicht. Mit der von den Minern bereitgestellten Rechenleistung konnten sie beeinflussen, welche Blöcke sich durchsetzten. Sie konnten aber nicht jeden Full Node zur Annahme beliebiger Regeln zwingen. Ihr Erfolg hing an einem begrenzten Ziel: einen für alte wie neue Knoten gültigen Zweig aufzubauen und ihm die größte angesammelte Arbeit zu verschaffen.

Gavin Andresen dokumentierte den Vorfall später in BIP 50. Der Bericht behauptet nicht, das Netzwerk habe fehlerfrei funktioniert. Er erklärt die Ursache, den Ablauf, die verlorenen Blöcke, den Double Spend und die Maßnahmen, die ähnliche Widersprüche früher aufdecken sollen. Durch die Veröffentlichung blieb die Erfahrung dieser Krisennacht nicht allein in der Erinnerung der Beteiligten. Auch andere Entwickler konnten daraus lernen.

Eine Lehre war, dass Konsens nicht nur die Regeln umfasst, die in Kommentaren oder Dokumentationen geschrieben sind. Das praktische Verhalten eines weit verbreiteten Programms kann sich zu einer Einschränkung des Netzwerks entwickeln, auch wenn niemand beabsichtigt hat, dass es eine finanzielle Bedeutung hat. Die Migration der Datenbank darf daher nicht als rein interne Änderung angesehen werden, wenn sie die Akzeptanz eines Blocks ändern kann.

Eine weitere Lehre war die Notwendigkeit, Upgrades vorsichtiger zu koordinieren und Blöcke nahe den Betriebsgrenzen zu testen. Version 0.8 brachte eine Leistungsverbesserung, aber der Unterschied zeigte sich erst in der realen Kette. Nach dem Vorfall führten die Entwickler vorübergehende Grenzen ein und bereiteten den Weg, um alte Abhängigkeiten später sicher aufgeben zu können.

Die Geschichte wird manchmal als Beweis verwendet, dass Bitcoin von einigen Entwicklern gesteuert wird, manchmal als Beweis, dass es automatisch unzerstörbar ist. Keine dieser verkürzten Versionen stimmt. Die Leute konnten dringend die Reparatur koordinieren, aber sie benötigten die Zusammenarbeit von Pools, Börsen und Knoten-Betreibern. Die Software entschied auf jedem Computer einzeln, und das gemeinsame Ergebnis entstand erst durch ihre Kombination.

Am Ende der Nacht vom 11. auf den 12. März gab es wieder eine Hauptkette. Die Unterschiede hatten sich jedoch nicht von selbst erledigt. Einige Beteiligte schlugen Alarm, andere setzten Dienste aus, und Miner verzichteten auf geleistete Arbeit, um eine kompatible Historie wiederherzustellen. Bitcoin überstand seine zwei konkurrierenden Vergangenheiten durch das Zusammenspiel von Regeln, wirtschaftlichen Kosten und Menschen, die akzeptierten, dass diesmal die neuere Software zurückstehen musste.

Der Wert von BIP 50 liegt darin, dass der Vorfall nicht mit einem Triumph der Dezentralisierung für erledigt erklärt wird. Der Bericht hält die konkrete Ursache, den zeitlichen Ablauf, die verlorene Arbeit und die geplanten Gegenmaßnahmen fest. Aus einem unangenehmen Fehler wird so eine Grundlage für weitere Tests. Eine Frage bleibt offen: Wie viele unausgesprochene Annahmen liegen zwischen zwei Programmversionen, die wir für kompatibel halten? Konsens ist mehr als eine Liste von Regeln auf Papier. Unabhängige Implementierungen und Knoten müssen auch in Grenzfällen zum selben Ergebnis kommen. Wie wichtig diese Übereinstimmung ist, wird besonders deutlich, wenn sie zerbricht.