‍Was BIP 110 wollte

BIP steht für Bitcoin Improvement Proposal, einen formellen Vorschlag zur Änderung des Protokolls. BIP 110 trug den Namen „Reduced Data Temporary Softfork" und hatte ein klares Ziel: bestimmte Formen der Datenspeicherung im Netzwerk einzuschränken. Gemeint waren vor allem Ordinals, Inscriptions und ähnliche datenintensive Anwendungen, die in den vergangenen Jahren auf Bitcoin entstanden sind. Konkret sollten Output-Skripte auf 34 Byte begrenzt, Datenfelder auf maximal 256 Byte beschränkt und der sogenannte Taproot-Annex verboten werden.

Die Kritik dahinter ist nicht aus der Luft gegriffen. Viele Nutzer sehen Bitcoin in erster Linie als Zahlungs- und Wertaufbewahrungsnetzwerk und stören sich daran, dass knapper Blockplatz für das Einschreiben beliebiger Daten verwendet wird. Diese Sorge ist berechtigt, und man muss die Befürworter nicht für Ideologen halten, um sie ernst zu nehmen.

Nur hätte die vorgeschlagene Lösung das Problem kaum gelöst. Selbst mit den Regeln von BIP 110 lassen sich weiterhin Daten in der Blockchain unterbringen, nur eben auf anderen Wegen. Wer Inscriptions verhindern will, jagt hier einem beweglichen Ziel hinterher: Man verengt die Konsensregeln, handelt sich damit reale Risiken ein und bekommt am Ende trotzdem keine verlässliche Spamverhinderung. Hinter dem Vorschlag stand vor allem die Community rund um den alternativen Client Bitcoin Knots und dessen bekanntesten Verfechter, Luke Dashjr.
‍

Ein Aktivierungsmechanismus, der Fragen aufwarf

Übliche Softforks werden über einen bewährten Prozess aktiviert: Miner signalisieren ihre Unterstützung, und erst wenn eine überwältigende Mehrheit zustimmt, in der Regel 90 Prozent der Hashrate über mehrere Difficulty-Perioden, wird die Änderung scharf geschaltet. So lief es etwa bei Taproot.

BIP 110 ging einen anderen Weg. Die Aktivierungsschwelle wurde auf 55 Prozent gesenkt, und schon das war heikel. Bei einem Softfork bleiben die Blöcke der neuen Kette auch für alte Nodes gültig, weil die Regeln nur enger, nicht anders werden. Gleichzeitig gilt: Es gewinnt die Kette mit dem meisten Proof-of-Work, also der meisten aufgewendeten Rechenleistung. Läge die Hashrate nahe der 50-Prozent-Marke, käme es nach dem Fork immer wieder zu einem Rennen um die längste Kette, mit der Gefahr sogenannter Reorgs. Bei einem Reorg verwirft eine Node ihre aktuelle Kette, weil sie eine längere, ebenfalls gültige sieht. Werden dabei mehrere Blöcke verworfen, kann eine Transaktion, die eben noch drei Bestätigungen hatte, plötzlich wieder bei null stehen. Angreifer könnten so etwas ausnutzen.

Der eigentliche Kniff steckte aber woanders. Als absehbar wurde, dass die 55 Prozent nie zusammenkommen würden, griff ein bereits implementierter Mechanismus namens „Forced Signaling". Ab Block 961.632 verwarfen BIP-110-Nodes jeden Block, der nicht aktiv für BIP 110 stimmte, so als wäre er ungültig. In ihrer Blockchain gab es damit nur noch Blöcke, die zu 100 Prozent für die Aktivierung votierten. Am Ende der Periode würde die Software brav ihre 100 Prozent Zustimmung sehen, das ist mehr als 55, und BIP 110 als aktiviert markieren. So weit kam es auf der Fork-Kette allerdings nie, weil sie schon nach zwei Blöcken zum Stillstand kam.

Die Logik dahinter ist bemerkenswert: Nicht die Mehrheit entscheidet durch aktive Zustimmung, sondern jede Ablehnung wird als ungültig weggefiltert. Es ist so, als würde man bei einer Wahl alle Stimmzettel für ungültig erklären, auf denen nicht der eigene Kandidat steht. Das Ergebnis steht damit vorher fest. Und genau dieser erzwungene Selbstausschluss, nicht die Spamfilter-Regeln, löste am 8. August die Abspaltung aus.
‍

Was am 8. August wirklich geschah

Der Ausgang war eindeutig, und er kam schnell. In der Signalisierungsperiode vor dem Fork hatten von 2.016 Blöcken gerade einmal 51 für BIP 110 gestimmt, rund 2,53 Prozent. Von einer echten Unterstützung war das weit entfernt.

Als der Fork bei Block 961.632 einsetzte, trennten sich die Wege der beiden Ketten. Die reguläre Bitcoin-Kette lief weiter wie an jedem anderen Tag. Die BIP-110-Kette kam über zwei Blöcke nicht hinaus: Bei Höhe 961.632 zweigte sie von der gemeinsamen Historie ab, fügte mit 961.633 einen zweiten Block hinzu und steckt seither fest. Beide Blöcke stammten vom Miner Roughnecks über den Pool OCEAN, dessen Mitgründer Luke Dashjr die Bewegung anführte. Weil die Hauptkette normal weiterläuft, wächst ihr Vorsprung ganz von allein: Am 10. August stand sie bei rund Block 961.860, also über 200 Blöcke vor der eingefrorenen BIP-110-Kette, und der Abstand wächst weiter.

Michael Saylor schätzte, dass etwa 99,85 Prozent der Hashrate bei Bitcoin blieben und nur rund 0,15 Prozent der neuen Kette folgten. Das ist seine eigene Rechnung und nicht protokollarisch bestätigt, aber die Größenordnung passt zum Bild.

Und selbst dieser Rest hielt nicht. Schon am 9. August stellte Roughnecks, praktisch der einzige aktive Miner der Fork-Kette, den Betrieb ein und riet anderen ausdrücklich, es ebenso zu halten. Die über den Pool OCEAN sichtbare Rechenleistung brach daraufhin um rund 96 Prozent ein. Von einer echten, dauerhaften Unterstützung war zu keinem Zeitpunkt etwas zu sehen.
‍

Warum die Abspaltung praktisch tot ist

Hier rächt sich ausgerechnet eine Eigenschaft, die Bitcoin sonst schützt: die Difficulty. Unmittelbar nach dem Fork waren beide Ketten identisch und hatten dieselbe Mining-Schwierigkeit. Diese Schwierigkeit ist auf die gewaltige Rechenleistung des Gesamtnetzwerks geeicht. Fällt fast diese gesamte Leistung weg, passt sich die Difficulty nicht sofort an, sondern erst nach 2.016 Blöcken.

Für eine Kette, die im Schnitt kaum noch einen Block zustande bringt, ist das ein Todesurteil auf Raten. Bei so wenig Hashrate dauert es nicht zwei Wochen bis zur nächsten Anpassung, sondern Monate, womöglich Jahre. Bis dahin müssten Miner auf einer Kette weiterschürfen, deren Coins niemand handelt und die keinen erkennbaren Nutzen hat. Diesen Anreiz hat kaum jemand. Genau deshalb blieb die Kette nach zwei Blöcken stehen. Neue Blöcke entstehen dort faktisch nicht mehr, und weil die Hauptkette normal weiterläuft, wächst der Rückstand von selbst.

Und weil so wenig Hashrate der Abspaltung folgte, trat das gefürchtete Reorg-Szenario nie ein. Die Hauptkette war zu keinem Zeitpunkt in Gefahr. Die Sorge vor einem knappen Kopf-an-Kopf-Rennen erledigte sich in dem Moment, in dem klar wurde, wie klein das BIP-110-Lager tatsächlich war.
‍

Der geplante Notausgang: ein anderer Mining-Algorithmus

Genau hier setzt der nächste Schritt der BIP-110-Befürworter an. Um der Difficulty-Falle zu entkommen, liegt ein Plan für einen Wechsel des Proof-of-Work-Algorithmus bereit. Der Entwickler Chris Guida hat Anfang August alten Hardfork-Code von Luke Dashjr aus dem Jahr 2017 auf die aktuelle Bitcoin-Knots-Software portiert. Aktiviert ist davon nichts, und welcher Algorithmus zum Einsatz käme, ist offen. Guida selbst bezeichnet es als Code für die Hosentasche, für den Fall, dass die Miner „Bitcoin verraten".

Inzwischen wird das Ganze konkreter. Luke Dashjr brachte den 1. September als Zieldatum ins Spiel, den Tag, an dem BIP 110 regulär hätte aktiviert werden sollen. Offen diskutiert wird sogar, auf welcher Basis dieser Neustart laufen soll: auf der dann aktuellen regulären Bitcoin-Kette oder auf der festgefahrenen BIP-110-Kette. Beschlossen ist davon nichts, und der Kreis, der das ernsthaft betreibt, ist klein.

Was würde so ein Wechsel bedeuten? Bitcoin wird heute mit spezialisierten ASIC-Maschinen geschürft, die genau auf den bestehenden Algorithmus SHA-256 ausgelegt sind. Ein anderer Algorithmus würde diese Geräte auf der BIP-110-Kette mit einem Schlag wertlos machen und die Startschwierigkeit drastisch senken, laut den Entwicklern grob um den Faktor Million. Die Kette könnte dann wieder Blöcke in vernünftigem Takt produzieren, ohne auf die großen Mining-Pools angewiesen zu sein.

Der Preis dafür ist hoch, und er zeigt, worum es im Kern geht. Ein solcher Schritt würde die etablierten Miner bewusst aussperren und ihre Hardware auf dieser Kette entwerten. Wer eine Änderung nicht über breiten Konsens erreicht, müsste am Ende genau jene ausschließen, die den Großteil der Rechenleistung stellen. Aus einem Streit über Datenspam wäre damit ein Eingriff in die Sicherheitsgrundlage von Bitcoin geworden. Dashjr selbst sagt, er hoffe, dass dieser Notfallplan nie gebraucht wird.
‍

Das offene Risiko: keine Replay Protection

So klar der Fork gescheitert ist, ein Punkt bleibt und betrifft jeden, der Bitcoin On-Chain bewegt: Es gibt keine Replay Protection.

Bei einem Chain-Split mit Replay Protection trägt jede Transaktion eine Markierung und ist nur auf einer der beiden Ketten gültig. Ohne diesen Schutz ist eine Transaktion, die auf der einen Kette gültig ist, automatisch auch auf der anderen gültig. Bei BIP 110 fehlt diese Schutzschicht.

Praktisch heißt das: Wer vor dem Split Bitcoin besaß, hält dieselbe Menge Coins nun auf beiden Ketten. Wer nach dem Split eine gewöhnliche Bitcoin-Transaktion sendet, sendet sie unter Umständen gleichzeitig auf beiden Ketten. Solange man keinen Coin bewegt, der nur auf einer der Ketten existiert, laufen Transaktionen parallel, ohne dass man aktiv etwas dagegen tun kann.

Unser Rat, solange die Lage nicht eindeutig geklärt ist: Sieh nach Möglichkeit von größeren On-Chain-Transaktionen ab, wenn sie nicht ohnehin nötig sind. So vermeidest du, ungewollt Coins auf beiden Ketten zu verschieben. Die gute Nachricht ist, dass die BIP-110-Kette faktisch tot ist und die meisten seriösen Börsen und Broker durchgehend normal gearbeitet und keine Fork-Coins gelistet haben. Das senkt das reale Risiko deutlich. Verschwunden ist es damit aber nicht.
‍

Die Scam-Welle, die erfahrungsgemäß folgt

Nach jedem Fork tauchen dieselben Angebote auf, und auch diesmal ist Wachsamkeit angebracht. Das Muster ist stets ähnlich: Ein Dienst oder eine Wallet bietet an, deine „gratis erhaltenen Fork-Coins" zu verkaufen. Es klingt nach geschenktem Geld. Tatsächlich sendest du, weil die Replay Protection fehlt, mit deinen vermeintlichen Fork-Coins auch deine echten Bitcoin mit. Das Ergebnis: Die echten Coins landen beim Käufer, und du hast nichts davon.

Auch eine eigene „BIP-110-Wallet" ändert daran nichts. Solange du keinen Coin hast, der nur auf einer Kette existiert, lässt sich die Transaktion im Hintergrund weiter auf beiden Ketten ausführen.

Die wichtigsten Vorsichtsregeln auf einen Blick:

• Geh nicht auf Angebote ein, BIP-110-Coins zu verkaufen. Das Risiko, echte Bitcoin zu verlieren, ist real.
• Installiere keine unbekannten „BIP-110-Wallets" und gib deinen Seed nirgends ein, wenn du dir nicht zu 100 Prozent sicher bist, was du tust.
• Verschiebe größere Beträge On-Chain möglichst erst, wenn die Situation abschließend geklärt ist.
  ‍

Was BIP 110 über Bitcoin verrät

Zum Schluss die eigentlich spannende Ebene. BIP 110 wirft eine Frage auf, die seit dem Blocksize War von 2017 im Raum steht: Was passiert, wenn eine Gruppe versucht, eine Protokolländerung durchzudrücken, die keine breite Unterstützung hat?

Die Antwort steht nun in den Blöcken. Rund 2,5 Prozent Signalisierung, danach eine Kette, die nach zwei Blöcken einfriert. Die großen Mining-Pools, Börsen und Infrastrukturanbieter zogen nicht mit. Ein Mechanismus, der die Zustimmung technisch herbeirechnet, ersetzt eben keine echte Mehrheit. Sobald es ums tatsächliche Schürfen ging, folgte fast niemand.

Das ist die eigentliche Lehre. Bitcoin ist nicht deshalb schwer zu ändern, weil es niemand ändern wollte, sondern weil Änderungen breiten Konsens brauchen. Wer diesen Konsens umgehen will, kann sich zwar jederzeit eine eigene Kette bauen. Ob ihm jemand dorthin folgt, kann er aber nicht erzwingen. Die berechtigte Debatte über Datenspam auf Bitcoin ist damit übrigens nicht erledigt. Sie muss nur einen anderen Weg finden als einen Fork, den kaum jemand mitträgt.
‍

Das Wichtigste in Kürze

• BIP 110 wollte die Datenspeicherung in Bitcoin-Blöcken einschränken (Ziel: Ordinals, Inscriptions). Die Sorge ist berechtigt, die konkrete Lösung hätte Daten in der Blockchain aber nicht zuverlässig verhindert. Gleichzeitig würden aktuelle Use Cases rund um Miniscript, Vererbung und zukünftige Update-Optionen für Lightning dadurch eingeschränkt werden. 
• Der Aktivierungsmechanismus „Forced Signaling" erzwang ab Block 961.632 eine Abspaltung, ohne echte Mehrheit.
• Der Split fand am 8. August statt. Die BIP-110-Kette brachte nur zwei Blöcke zustande (961.632 und 961.633) und steckt seither fest, während die Hauptkette über 200 Blöcke davongezogen ist. Geschätzt folgten ihr nur rund 0,15 Prozent der Hashrate.
• Weil so wenig Hashrate mitzog, war die Hauptkette nie in Gefahr, und die befürchteten Reorgs blieben aus.
• Um der Difficulty-Falle zu entkommen, liegt ein Plan für einen Wechsel des Mining-Algorithmus (Proof-of-Work) bereit. Er ist nicht beschlossen, als Zieldatum kursiert der 1. September. Der Schritt hätte einen hohen Preis: Bestehende Bitcoin-Miner würden auf dieser Kette bewusst ausgeschlossen und ihre Hardware entwertet.
• Das verbleibende Risiko ist die fehlende Replay Protection: On-Chain-Transaktionen können auf beiden Ketten gültig sein. Größere Transaktionen daher besser aufschieben, bis die Lage geklärt ist.
• Keine Fork-Coin-Verkaufsangebote annehmen, keine unbekannten Wallets installieren, keinen Seed eingeben.
  ‍

Wenn du Fragen hast, erreichst du uns wie immer über unsere offiziellen Kanäle.

‍