Die Blocksize Wars und Bitcoin Forks

Der Konflikt, der Bitcoin stärker machte

Zwischen 2015 und 2017 tobte innerhalb der Bitcoin-Community ein Krieg — nicht um Coins, sondern um eine einzige Zahl: die maximale Blockgröße. Dieser Konflikt, bekannt als die Blocksize Wars, war die wichtigste Bewährungsprobe in Bitcoins Geschichte. Das Ergebnis definiert Bitcoin bis heute.

Das Problem: Volle Blöcke

Bitcoins Blöcke hatten von Anfang an ein Limit von 1 MB. Als die Nutzung stieg, wurden die Blöcke regelmäßig voll:

Transaktionen mussten warten
Gebühren stiegen
Nutzer beschwerten sich

Die Frage war einfach: Wie skaliert Bitcoin?

Zwei Lager, zwei Philosophien

Die „Big Blocker“

Ihr Argument: Erhöht die Blockgröße auf 2 MB, 8 MB, oder sogar 32 MB. Mehr Platz = mehr Transaktionen = niedrigere Gebühren.

Unterstützer: Mining-Pools (vor allem Bitmain/Jihan Wu), Unternehmen (Coinbase, BitPay), einige frühe Entwickler (Gavin Andresen, Mike Hearn, Roger Ver).

Die „Small Blocker“

Ihr Argument: Die Blockgröße darf nicht einfach erhöht werden, weil:

Größere Blöcke = weniger Nodes. Wenn jeder Block größer wird, brauchen Nodes mehr Bandbreite, Speicher und Rechenleistung. Das schließt kleine Teilnehmer aus und zentralisiert das Netzwerk.
Skalierung gehört auf Layer 2. Die Basisschicht muss so dezentral und sicher wie möglich bleiben. Lightning löst die Skalierung, ohne die Basisschicht zu kompromittieren.
Ein Hard Fork spaltet das Netzwerk. Eine Blockgrößen-Erhöhung erfordert, dass alle Nodes die neuen Regeln akzeptieren — wer nicht aktualisiert, wird abgehängt. Das ist ein Hard Fork und gefährdet den Konsens.

Unterstützer: Bitcoin Core-Entwickler (Greg Maxwell, Pieter Wuille, Luke Dashjr), die Mehrheit der Node-Betreiber, die Cypherpunk-Community.

graph TB
    A["Volle Blöcke
Gebühren steigen"] --> B{"Wie skalieren?"}
    B --> C["Big Blocker
Blockgröße erhöhen"]
    B --> D["Small Blocker
Layer 2 + SegWit"]
    C --> E["Hard Fork nötig
Netzwerk-Spaltung"]
    C --> F["Weniger Nodes
Zentralisierung"]
    D --> G["Soft Fork
Rückwärtskompatibel"]
    D --> H["Lightning Network
Skalierung ohne Kompromiss"]
    E --> I["Bitcoin Cash
1. Aug 2017"]
    G --> J["SegWit aktiviert
24. Aug 2017"]
    style D fill:#98971a,color:#282828
    style J fill:#98971a,color:#282828
    style I fill:#cc241d,color:#fbf1c7

SegWit: Die elegante Lösung

Segregated Witness (SegWit), entworfen von Pieter Wuille, löste das Problem auf eine brillante Weise:

Signaturdaten werden ausgelagert — sie zählen nur zu 25% zur Blockgröße. Dadurch passen effektiv mehr Transaktionen in einen Block.
Soft Fork — alte Nodes können SegWit-Blöcke trotzdem validieren. Kein Zwang zum Update.
Transaktionsformbarkeit gelöst — ein Bug, der Lightning-Channels unsicher machte, wurde behoben.
Effektive Kapazität: ~1,7-2,2 MB statt dem alten 1 MB — ohne das Limit formal zu erhöhen.

Das war der Schlüssel: SegWit erhöhte die Kapazität, ohne einen Hard Fork zu erzwingen.

Die Forks: Bitcoin Cash und weitere

Als klar wurde, dass SegWit aktiviert würde, spalteten sich die Big Blocker ab:

Fork	Datum	Blockgröße	Status heute
Bitcoin Cash (BCH)	1. Aug 2017	8 MB → 32 MB	Existiert, ~0,5% von BTCs Marktkapitalisierung
Bitcoin SV (BSV)	15. Nov 2018	128 MB → unbegrenzt	Fast tot, Craig Wright-Projekt
SegWit2x (B2X)	Abgesagt Nov 2017	2 MB + SegWit	Nie gestartet — zu wenig Node-Support

Was die Forks bewiesen

Jeder kann Bitcoin forken — der Code ist Open Source. Das ist eine Stärke, kein Schwäche.
Aber niemand kann Bitcoins Netzwerkeffekt kopieren. Hash Rate, Nodes, Liquidität, Vertrauen — das folgt nicht automatisch dem Fork.
Die Nodes entscheiden, nicht die Miner. Obwohl über 80% der Mining-Hashrate für größere Blöcke waren, haben die Node-Betreiber SegWit durchgesetzt. Die ökonomische Mehrheit zählt.

Ein Fork kann den Code kopieren, aber nicht das Netzwerk. Bitcoin Cash hat identische Technologie — aber nur einen Bruchteil der Sicherheit, Liquidität und Adoption. Das Netzwerk ist der Wert, nicht der Code.

Hard Fork vs. Soft Fork

	Hard Fork	Soft Fork
Kompatibilität	Alte Nodes verstehen neue Blöcke nicht	Alte Nodes akzeptieren neue Blöcke
Risiko	Netzwerk-Spaltung	Keine Spaltung
Beispiel	Bitcoin Cash (BCH)	SegWit, Taproot
Erzwungenes Update	Ja — alle müssen aktualisieren	Nein — optional

Bitcoin hat seit 2017 bewusst nur Soft Forks gemacht. Taproot (2021) wurde ebenfalls als Soft Fork aktiviert — mit derselben Philosophie: Rückwärtskompatibilität, keine Spaltung.

UASF: Die Macht der Nutzer

Der entscheidende Moment war der User Activated Soft Fork (UASF) — BIP-148. Node-Betreiber kündigten an: „Ab dem 1. August 2017 akzeptieren unsere Nodes nur noch Blöcke, die SegWit signalisieren.“

Das zwang die Miner, SegWit zu aktivieren — obwohl viele dagegen waren. Es war der Beweis: In Bitcoin haben die Nutzer die Macht, nicht die Miner.

Überlege: Warum konnten die Miner (mit >80% Hashrate) den UASF nicht ignorieren? Was wäre passiert, wenn sie weiterhin Blöcke ohne SegWit-Signal produziert hätten?

Die Lehren für heute

Dezentralisierung ist nicht verhandelbar. Jeder Kompromiss zugunsten von „Effizienz“ oder „Skalierung“ gefährdet das Fundament.
Soft Forks > Hard Forks. Rückwärtskompatibilität schützt den Konsens.
Layer 2 skaliert, Layer 1 sichert. Lightning beweist, dass die Small-Blocker-Philosophie funktioniert.
Bitcoin governance funktioniert. Ohne CEO, ohne Vorstand, ohne Abstimmung — durch dezentrale Koordination.
Forks sind kein Risiko. Sie sind ein Feature. Wer eine andere Vision hat, kann forken. Aber der Markt entscheidet, welche Chain wertvoll ist.

Weiterführend

Das Byzantinische Problem und Nakamoto-Konsens — warum dezentraler Konsens so schwer ist
Mining und Proof of Work — wie Miner Blöcke finden
Blöcke und die Timechain — was in einem Block steckt
Warum nur Bitcoin? — warum Forks und Altcoins nicht konkurrieren

Zurück zur Übersicht: Grundlagen