Es ging nicht um einen Streit über eine neue Regel, sondern um eine verborgene Abhängigkeit der Validierung von der Datenbankimplementierung: Das neuere LevelDB verarbeitete einen Block mit ungewöhnlich vielen Inputs, während frühere Versionen die voreingestellte Zahl der Berkeley-DB-Sperren erschöpften; Miner koordinierten daher die Rückkehr zum kompatiblen Zweig, und Version 0.8.1 bereitete anschließend einen kontrollierten Übergang vor.
Am 11. März 2013 schürfte ein Node mit Bitcoin 0.8 den Block 225 430. Die neue Version akzeptierte ihn, während einige Nodes mit 0.7.2 und älter ihn ablehnten; vom selben Vorgänger wuchsen deshalb ein Zweig mit und ein Zweig ohne diesen Block. Der Unterschied lag nicht im Hash oder proof of work selbst, sondern darin, ob die lokale Software den Block überhaupt als gültig ansah. [2]
Auslöser war nicht einfach die Blockgröße in Bytes. Der Block enthielt eine bis dahin ungewöhnlich große Zahl an Transaktionsinputs, und alte Nodes erschöpften beim Schreiben die voreingestellte Zahl der Berkeley-DB-Sperren. Die benötigte Sperrenzahl hing außerdem von der Anordnung der Datenbankseiten des jeweiligen Nodes ab, sodass ein kleinerer, sonst gültiger Block scheitern konnte, obwohl frühere Testblöcke maximaler Größe funktioniert hatten. [1]
Bitcoin 0.8 verlagerte die Block- und Transaktionsindizes von Berkeley DB zu LevelDB, das dieses Sperrenlimit nicht hatte. Anfangs bauten etwa 60 % der Hashrate auf dem 0.8-Zweig, doch ältere Nodes rechneten dessen Arbeit nicht an, weil sie den Ausgangsblock ablehnten. Die Regel der schwersten Kette wählt nur unter Historien, die ein Node zuvor validiert hat; sie konnte den Dissens daher nicht allein lösen. [1]
Pieter Wuille veröffentlichte die Notfallwarnung und riet Händlern, die Zahlungsabwicklung auszusetzen. Nach Gesprächen zwischen Entwicklern und Betreibern wechselten der von Michael Marsee alias Eleuthria geführte Pool BTCGuild und Marek Palatinus’ Slush Pool zurück zu Bitcoin 0.7. Ziel war nicht, den technisch neueren Zweig dauerhaft für falsch zu erklären, sondern die Arbeit rasch auf eine Historie zu bündeln, die beide verbreiteten Versionen validieren konnten. [3]
Als der kompatible Zweig bei der kumulierten Arbeit in Führung ging, reorganisierten sich die 0.8-Nodes auf ihn; nur im ursprünglichen 0.8-Zweig geschürfte Blöcke wurden stale. BIP 50 dokumentiert während der Spaltung mindestens einen großen double spend; laut Post-Mortem war er ein Experiment und kein beabsichtigter Diebstahl. Das Ereignis zeigte dennoch, warum Börsen und Händler bei unklarer Kettenspitze Einzahlungen pausieren und weitere Bestätigungen abwarten. [1]
Bitcoin Core 0.8.1 erschien am 18. März 2013. Es führte eine vom 21. März bis 15. Mai durchgesetzte temporäre Blockannahmeregel ein, die Blöcke verhinderte, welche ältere Peers nicht verarbeiten konnten, und ergänzte einen eingebauten Checkpoint bei Block 225 430. Das Post-Mortem nennt außerdem einen Schätzwert von 10 000 Sperren, ein Mininglimit von 500 000 Bytes und Backports mit einem Limit von 537 000 Berkeley-DB-Sperren. [4]
Die temporäre Kompatibilität war nicht der Endzustand. Betreiber älterer Nodes sollten bis 15. Mai auf 0.8.1, einen aktualisierten Backport oder ein ausdrücklich höheres Sperrenlimit umstellen; Miner durften das Limit vor dem koordinierten Termin nicht anheben, um nicht erneut einen vom Rest des Netzes abgelehnten Block zu erzeugen. Am 16. August 2013 akzeptierte das Netzwerk Block 252 451 und ließ ungepatchte Nodes endgültig zurück. [5]
Der Vorfall zeigte, dass Konsens mehr als eine Beschreibung des Blockformats ist. Dazu gehören das genaue Verhalten von Validierungscode, Bibliotheken, Datenbanktransaktionen, Fehlerpfaden und Grenztests. Zu den Folgemaßnahmen zählten deshalb Stresstransaktionen im Testnet, bessere Warnungen für Dienste, die Beobachtung langer Seitenzweige und vorsichtigere Koordination von Änderungen; die schnelle Erholung offenbarte zugleich die damalige Abhängigkeit von wenigen erreichbaren Entwicklern und großen Pools. [1]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Bitcoin Core, Konsensregeln, Hard Fork, Reorg, Full Node, Mining Pool. Auf diesen Eintrag verweisen außerdem Schelling Point.
01Entschied damals eine Gruppe, welche Blockchain die echte ist?+
Entwickler und große Pools koordinierten die Notfallreaktion, konnten Nodes aber nicht aus der Ferne umschreiben. BTCGuild und Slush änderten die Software ihrer Miner; Nutzer betrieben Versionen mit eigenen Validierungsregeln. Der kompatible Zweig setzte sich erst durch, als genügend Nodes ihn akzeptierten und er aus Sicht der Bitcoin-0.8-Nodes mehr Arbeit sammelte.
02Waren beide Zweige gleichzeitig gültig?+
Das hing von der validierenden Version ab. Bitcoin 0.8 hielt Block 225 430 und seinen Zweig für gültig; einige ältere Nodes lehnten den Block wegen des Berkeley-DB-Limits ab und kannten nur den anderen Zweig. Unterschiedliche Antworten auf dieselben Eingabedaten sind genau ein Konsensversagen; die heute aktive Historie setzt den koordiniert gewählten kompatiblen Zweig fort.