Als Block Size War bezeichnet man die Auseinandersetzungen um Bitcoins Kapazität und Regeländerungen. Sie mündeten 2017 in die Aktivierung von SegWit, die Abspaltung von Bitcoin Cash und die Aussetzung des geplanten SegWit2x-Forks. Diese drei Ereignisse hatten unterschiedliche Ursachen und technische Abläufe.
Stellen wir uns zwei alltägliche Bedürfnisse vor. Anna möchte Bitcoin versenden, ohne lange zu warten oder hohe Gebühren zu zahlen. Pavel betreibt einen Full Node: einen Computer, der Blöcke und Transaktionen selbst prüft. Er möchte sein Geld auch ohne teure Geräte überprüfen können. Beides ist verständlich. Mehr Daten pro Block bedeuten jedoch auch mehr Daten, die übertragen und geprüft werden müssen. Um dieses Verhältnis ging es im Block Size War. Ein Block ist ein Bündel von Transaktionen, das die gemeinsame Zahlungshistorie des Netzwerks ergänzt. Anna und Pavel sind frei erfundene Personen, an denen sich die beiden Anliegen zeigen lassen. An der tatsächlichen Debatte von 2015 bis 2017 beteiligten sich Entwickler, Mining-Betreiber, Börsen, Wallet-Anbieter und Nutzer. Umstritten waren sowohl die Kapazität als auch ein sicherer Weg zur Änderung. Bitcoin hatte keinen Geschäftsführer, der eine Variante auswählen und allen den Umstieg anordnen konnte. [1] [11] [13]
Vor SegWit begrenzten die Regeln einen Block auf 1 MB, also 1 000 000 Bytes. Das war keine feste Zahl von Zahlungen: Transaktionen beanspruchen unterschiedlich viel Platz. Ein neuer Block entsteht im Durchschnitt ungefähr alle zehn Minuten. Übersteigt die Nachfrage die Kapazität, bevorzugen Miner meist Transaktionen mit höheren Gebührensätzen; andere warten. Befürworter größerer Blöcke wollten direkt im Basisnetz mehr Platz schaffen und Zahlungen bezahlbar halten. Gegner sorgten sich um Internetanbindung, Rechneranforderungen und die schnelle Weitergabe von Blöcken. Könnten weniger Menschen selbst prüfen, müssten mehr Nutzer fremden Diensten vertrauen. Ein höheres Limit beschleunigt die Blockerzeugung nicht von selbst und garantiert auch keine dauerhaft niedrigen Gebühren. Nachfrage und tatsächliche Auslastung bleiben entscheidend. [1] [2] [13]
Ein Entwickler kann neue Software schreiben, ein Miner damit einen Block erzeugen. Der Betreiber eines Full Node entscheidet jedoch, welche Regeln sein Knoten prüft. Selbst eine Mehrheit der Rechenleistung kann einen unveränderten Knoten nicht dazu bringen, einen regelwidrigen Block anzunehmen. Rechenleistung hilft bei der Auswahl zwischen gültigen Ketten; sie macht einen ungültigen Block nicht gültig. Das gibt nicht jedem Knoten eine Stimme in einer weltweiten Abstimmung. Auch kann eine einzelne Person andere nicht am Weggehen hindern. Unternehmen entscheiden, was sie annehmen, Miner, was sie schürfen, und Nutzer, was für sie Wert hat. Unvereinbare Regeln können zu zwei Netzen führen. Eine Branchenvereinbarung konnte eine Änderung fördern, aber nicht automatisch sämtliche Programme und Entscheidungen überschreiben. [11] [12]
Die Vorschläge wurden als BIPs dokumentiert, kurz für Bitcoin Improvement Proposal. Ein BIP beschreibt einen Vorschlag, damit andere ihn prüfen und diskutieren können. Eine vergebene Nummer bedeutet noch nicht, dass das Netzwerk ihn angenommen hat. Gavin Andresen schlug mit BIP 101 vor, das Limit auf 8 MB anzuheben und anschließend nach einem festgelegten Zeitplan weiter zu erhöhen. Vorgesehen waren ungefähr eine Verdopplung alle zwei Jahre und bestimmte Aktivierungsbedingungen. Mike Hearn und Andresen warben für Bitcoin XT, eine alternative Software für diesen Ansatz. Ihre Veröffentlichung änderte jedoch noch nicht die Regeln des gesamten Netzes. Alte Knoten hätten Blöcke oberhalb des bisherigen Limits abgelehnt. Es handelte sich um einen Hard Fork: eine Erweiterung der zulässigen Blöcke, für deren Annahme andere Regeln nötig wären. Damit ging die Debatte über die Frage nach zusätzlichem Platz hinaus. Wer würde umsteigen, wie sollte das abgestimmt werden und was geschähe, wenn ein bedeutender Teil nicht mitmachte? [1] [18] [13]
Eric Lombrozo, Johnson Lau und Pieter Wuille beschrieben in BIP 141 einen anderen Ansatz. SegWit ordnete Transaktionsdaten neu und führte ein Blockgewicht mit einem Limit von 4 000 000 weight units ein. Der sogenannte Witness enthält insbesondere Daten zur Prüfung der Ausgabeberechtigung. Diese verschwanden nicht und wurden weiterhin geprüft; bei der Gewichtsberechnung wurden sie anders behandelt. Die Kapazität hängt vom Transaktionsmix ab. Es wurden also nicht einfach gewöhnliche Vier-Megabyte-Blöcke erlaubt. Das Gewicht legt fest, wie Daten auf das Blocklimit angerechnet werden: Ein Byte Basisdaten zählt als 4 Einheiten, ein Byte zusätzlicher Witness-Daten als 1. Gleich große Transaktionen können deshalb unterschiedlich viel des zulässigen Gewichts beanspruchen. Die Kapazität hängt also auch davon ab, welche Transaktionstypen genutzt werden. Bei geeigneten Transaktionen beseitigte SegWit außerdem die Möglichkeit, ihre Kennung durch veränderte Signaturdaten zu beeinflussen. Das erleichterte den Aufbau von Zahlungskanälen für das Lightning Network. SegWit war als Soft Fork angelegt: Neue gültige Blöcke passen zu den alten Regeln, ältere Knoten prüfen jedoch nicht alle neuen Einschränkungen. Bitcoin Core 0.13.1 enthielt den Aktivierungsmechanismus; die Veröffentlichung allein schaltete SegWit noch nicht ein. [2] [3]
Am 23. Mai 2017 veröffentlichte Digital Currency Group das New York Agreement, eine Vereinbarung von Unternehmen und Minern. Sie verband die Unterstützung für SegWit mit einem versprochenen Hard Fork auf 2 MB innerhalb von sechs Monaten. Dieser zweite Schritt wurde als SegWit2x bekannt; das Projekt btc1 lieferte die Implementierung. Manche Beteiligte sahen darin einen tragbaren Kompromiss: Beide Seiten sollten einen Teil ihrer Wünsche erhalten. Andere lehnten sowohl die zweite Änderung als auch das Vorgehen ab. Die Zustimmung eines Unternehmens stand nicht automatisch für die Zustimmung aller Kunden. Bitcoin Core stellte später ausdrücklich klar, dass btc1 keine notwendige Aktualisierung seiner Software sei und Unterstützung für SegWit nicht gleichbedeutend mit Unterstützung für SegWit2x sei. Auch wenn beide in derselben Vereinbarung standen, blieben sie unterschiedliche Regeländerungen. [6] [7] [11]
Der pseudonyme Autor Shaolin Fry schlug BIP 148 vor, einen UASF, also einen von Nutzern aktivierten Soft Fork. Knoten mit dieser Regel sollten ab dem 1. August 2017 gemessen an Median Time Past Blöcke ohne SegWit-Signalisierung ablehnen, sofern SegWit noch nicht festgeschrieben oder aktiv war. Hätten Mining und Blockannahme unterschiedliche Wege genommen, hätte sich das Netz teilen können. Das war kein risikoloser Schalter, den alle Nutzer gemeinsam bedienten. Median Time Past ist der mittlere Wert der sortierten Zeitstempel der letzten 11 Blöcke, nicht die Uhrzeit auf dem Gerät jedes Nutzers. Signalisierung bedeutete hier eine Markierung im Blockheader, mit der der Miner seine Unterstützung für diese Einführung ausdrückte. Die Markierung allein setzte die neuen Regeln noch nicht in Kraft. James Hilliard beschrieb in BIP 91 eine Koordination der Miner mit niedrigerer Schwelle: 269 von 336 Blöcken, ungefähr 80 %. Nach Inkrafttreten sollten Teilnehmer Blöcke ablehnen, die nicht für die bestehende SegWit-Einführung signalisierten. Die Koordination im Juli verringerte die Gefahr eines Konflikts zur Augustfrist. SegWit selbst war deshalb aber noch nicht im Juli festgeschrieben oder aktiviert. Dafür lief weiterhin der eigene Mechanismus nach BIP 9. [4] [5] [9] [19]
Am 1. August 2017 spaltete sich Bitcoin Cash ab. Die Software Bitcoin ABC unterstützte auf diesem Zweig größere Blöcke, damals standardmäßig bis 8 MB. Ab der Trennung hatten die Netze unterschiedliche Regeln und eigene Coins. Die gemeinsame Vorgeschichte bedeutete nicht, dass spätere Zahlungen frei zwischen BTC und BCH übertragbar wären. Bitcoin Cash war nicht SegWit2x und Bitcoin ABC nicht btc1. Wer diese Namen vermischt, verwechselt die Abspaltung im August mit einem anderen, später ausgesetzten Vorhaben. Auch die replay protection unterschied sich: der Schutz davor, eine Transaktion auf der anderen Kette zu wiederholen. Für Nutzer hieß das praktisch, dass eine Ausgabe auf einem Zweig nicht unbeabsichtigt auch Guthaben auf dem anderen ausgeben sollte. Gemeinsame Schlüssel durften zudem nicht bedenkenlos in beliebige Werkzeuge für angeblich neue Coins eingegeben werden. [8] [15] [11]
SegWit erreichte mit Block 479 808 am 9. August 2017 den Zustand LOCKED_IN. Das Entscheidungsintervall war abgeschlossen; vor der Durchsetzung der neuen Regeln folgte noch ein Warteintervall. Aktiv wurde SegWit mit Block 481 824 am 24. August. Dazwischen liegen 2 016 Blöcke. Die BIP-91-Koordination im Juli, die Festschreibung im August und die eigentliche Aktivierung waren somit verschiedene Ereignisse. Offen blieb der zweite Schritt von SegWit2x, geplant für Höhe 494 784. Am 8. November gaben die Organisatoren um Mike Belshe die Aussetzung bekannt: Nach eigener Aussage fehlte die ausreichende Einigung für einen reibungslosen Übergang. Dadurch verlor Bitcoin weder das bereits aktive SegWit, noch verschwand das eigenständige Bitcoin Cash. Beendet wurde dieser konkrete Versuch, die Unterstützung von Unternehmen und Minern in eine Erhöhung des Bitcoin-Limits umzusetzen. [9] [10] [12] [14] [16] [17]
Der Streit zeigte: Bitcoin lässt sich ändern, aber Code zu schreiben, Unterschriften von Unternehmen zu sammeln und Akzeptanz für Regeln zu erreichen sind verschiedene Aufgaben. Er bewies weder, dass Entwickler keinen Einfluss haben, noch dass Miner unwichtig sind oder künftig jede Entscheidung gleich ausgeht. Kapazität, bezahlbare Prüfung und Einigung bleiben Fragen, die sich nicht durch einen neuen Namen für ein Update erledigen. Fragen Sie bei einem neuen Vorschlag zuerst, was er konkret ändert, welche Knoten anschließend abweichen würden und wie die Aktivierung erfolgen soll. Unterscheiden Sie danach Vorschlag, veröffentlichte Software und tatsächlich geltende Regeln. Zeitgenössische BIPs und Code belegen Mechanismen, Stellungnahmen der Beteiligten deren Positionen. Keine einzelne Stellungnahme ist für sich eine unparteiische Darstellung der gesamten Geschichte. [1] [6] [11] [12]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit SegWit, Soft Fork, Hard Fork, Full Node, Bitcoin, Konsensregeln. Auf diesen Eintrag verweisen außerdem Soft Fork, Hard Fork, Block Weight, Jeff Garzik.