Der Totgeborene Split: BIP-110, die Diktatur der Minorität und die Physik des Konsenses Warum zwei Blöcke und dann Stillstand der sauberste Konsens-Beweis sind, den Bitcoin je geliefert hat.
Am 8. und 9. August 2026 hat Bitcoin einen Stresstest bestanden, den keine Simulation hätte ersetzen können. Bei Block 961.632 trat die verpflichtende Signalisierungsphase von BIP-110 in Kraft: Knoten, die den Vorschlag durchsetzten, begannen, ansonsten gültige Blöcke abzulehnen. Damit war die Abspaltung vollzogen. Was danach geschah, ist die eigentliche Nachricht. Die BIP-110-Kette produzierte genau zwei Blöcke – 961.632 und 961.633 – und blieb dann stehen. Nicht langsam, nicht holprig. Stehen. Vor dem Split hatten lediglich 51 von 2.016 Blöcken signalisiert, also 2,53 Prozent gegen eine geforderte Schwelle von 55 Prozent. Nach dem Split verblieben nach einer von Michael Saylor veröffentlichten Momentaufnahme rund 99,85 Prozent der Rechenleistung auf der Hauptkette – eine Schätzung, keine unabhängig reproduzierte Netzwerkmessung. Dieses Dispatch seziert, warum das kein Zufall war, sondern das erwartbare Ergebnis der Mechanik – und welches Protokoll du während eines Splits befolgen solltest, um dich selbst nicht zu beschädigen.
Dispatch Metadata
Critical Alarm / Dispatch #014Das Scheitern bei Block 961.632
Um zu verstehen, was hier passiert ist, musst du zuerst verstehen, was BIP-110 überhaupt wollte. Der Vorschlag – auch unter den Bezeichnungen RDTS und BIP-444 geführt – zielte darauf, die Speicherung beliebiger Daten in der Blockchain für ein Jahr einzuschränken. Konkret ging es um Inschriften im Ordinals-Stil, große Datenlasten in Skripten und bestimmte Taproot-Konstruktionen. Die vorgeschlagenen Regeln waren scharf: neue Ausgänge auf 34 Byte begrenzt, Datenschiebeoperationen in Skripten auf 256 Byte, das Taproot-Annex verboten, und OP_IF in Tapscript deaktiviert. Nach der veröffentlichten Spezifikation wären Inputs, die vor der Aktivierung entstandene UTXOs ausgeben, dauerhaft von diesen Regeln ausgenommen gewesen; die Beschränkungen selbst sollten nach 52.416 Blöcken auslaufen.
Man kann das Anliegen nachvollziehen, ohne die Methode zu billigen. Und die Methode war der Kern des Problems. BIP-110 sah eine freiwillige frühe Aktivierung bei 55 Prozent Signalisierung in einem 2.016-Block-Fenster vor. Diese Schwelle allein ist bereits bemerkenswert niedrig – die etablierten Aktivierungsmechanismen der Bitcoin-Geschichte arbeiteten mit 90 bis 95 Prozent, aus gutem Grund. Als die freiwillige Zustimmung ausblieb, griff die verpflichtende Phase: Ab Block 961.632 sollten Knoten, die BIP-110 durchsetzen, jeden Block ablehnen, der nicht das Versionsbit 4 signalisierte.
Schau dir die Zahl an, mit der dieser Mechanismus scharfgeschaltet wurde. Im maßgeblichen Fenster hatten 51 von 2.016 Blöcken signalisiert. Das sind 2,53 Prozent gegen eine geforderte Schwelle von 55 Prozent, was 1.109 Blöcken entspräche. Die Unterstützung lag also nicht knapp darunter. Sie erreichte rund 4,6 Prozent der erforderlichen Schwelle – etwa ein Zweiundzwanzigstel des Notwendigen. Trotzdem trat die verpflichtende Phase in Kraft, weil sie zeitgesteuert war und nicht zustimmungsgesteuert. Genau das ist der Konstruktionsfehler: Der Mechanismus konnte die Regeln nur für die durchsetzenden Knoten selbst ändern. Für alle anderen blieb die Kette, was sie war.
Was folgte, war deshalb kein Machtkampf, sondern eine Rechenaufgabe. Die BIP-110-Kette erbte die Difficulty der Elternkette – jenen Schwierigkeitsgrad, der auf die gesamte weltweite Rechenleistung kalibriert war. Sie musste diese Difficulty nun mit einem Bruchteil davon bedienen. Sie schaffte zwei Blöcke, 961.632 und 961.633 – in der öffentlichen Berichterstattung dem Umfeld von OCEAN und dessen hauseigenem DATUM-Protokoll zugerechnet, ohne dass eine blockweise Auswertung der Coinbase-Daten das hier belegen würde. Danach Stillstand. Nach acht Stunden stand die Hauptkette bei 961.681, die Minderheitskette unverändert bei 961.633 – ein Abstand von 48 Blöcken. Im Tagesverlauf wuchs die Lücke auf über 80.
Quellen: CoinDesk – BIP-110 mines two blocks then stops | BIP-110 – Proposal | BGeometrics – Technische Regelübersicht | mempool.space – Block 961.632 | Block 961.633 | mempool.space – Difficulty & Hashrate | Stand: 10. August 2026
Eine Anmerkung zur Sorgfalt, weil in solchen Ereignissen viele Zahlen kursieren, die niemand nachprüft. Die vielzitierte geerbte Difficulty von 127,48 Billionen ist plausibel und entspricht dem, was eine Abspaltung strukturell übernimmt – sie lässt sich aus den mir vorliegenden Primärquellen aber nicht unabhängig bestätigen. Ebenso wird die Urheberschaft der beiden Blöcke öffentlich einer bestimmten Mining-Gruppe zugeschrieben, ohne dass eine Primärquelle die Zuordnung je Block belegt. Ich führe beides deshalb als das, was es ist: belastbar in der Richtung, unbelegt im Detail. Wenn du es genau wissen willst, schau selbst in die Block-Header. Das ist ohnehin der Punkt dieses gesamten Dispatches.
Ebenfalls präzisierenswert ist die Differenz zwischen zwei Prozentzahlen, die gerne verwechselt werden. Die 2,53 Prozent beschreiben die Signalisierung vor dem Split – eine Absichtserklärung. Die rund 0,15 Prozent, die sich aus den 99,85 Prozent auf der Hauptkette ergeben, beschreiben die tatsächlich verbliebene Rechenleistung nach dem Split. Die zweite Zahl ist die entscheidende, und sie ist deutlich kleiner als die erste. Ein Teil derer, die signalisiert hatten, folgte der Abspaltung am Ende nicht. Signalisieren kostet nichts. Einer Kette ohne Ertrag zu folgen, kostet Geld.
Die Illusion der erzwungenen Konsens-Änderung
Hier liegt die eigentliche Lektion, und sie betrifft nicht BIP-110, sondern eine weit verbreitete Fehlvorstellung darüber, wo in Bitcoin die Macht sitzt. Die Vorstellung lautet: Wer die Knoten kontrolliert, kontrolliert die Regeln. Und wer genug Knoten dazu bringt, eine neue Regel durchzusetzen, hat die Regel geändert. Das ist zur Hälfte richtig, und die falsche Hälfte ist teuer.
Richtig ist: Knoten validieren. Jeder vollständige Knoten prüft eigenständig jeden Block gegen sein Regelwerk und lehnt ab, was nicht passt. Das ist die Grundlage der Selbstsouveränität und der Grund, warum du einen eigenen Knoten betreiben solltest. Falsch ist die stille Zusatzannahme, dass Validierung auch Fortschritt erzeugt. Das tut sie nicht. Blöcke entstehen ausschließlich durch Rechenleistung, die unter der geltenden Difficulty einen gültigen Nachweis findet. Ein Knoten kann sagen, was gilt. Er kann nicht sagen, was als Nächstes kommt.
Genau diese Trennung hat BIP-110 vorgeführt. Die durchsetzenden Knoten haben exakt getan, wofür sie konfiguriert waren: Sie haben nicht signalisierende Blöcke abgelehnt. Sie waren dabei technisch vollkommen erfolgreich. Nur entstand dadurch keine neue Bitcoin-Kette, sondern eine separate Kette mit einem Bruchteil der Rechenleistung und der vollen ererbten Difficulty. Das Regelwerk war durchgesetzt. Es war nur niemand da, der darauf baute.
Knoten bestimmen, welche Blöcke sie akzeptieren. Hashrate erzeugt die Blockfolge. Regeln allein erzwingen weder Rechenleistung noch Nachfrage – und ohne beides bleibt eine Kette unter geerbter Difficulty stehen.
Jetzt könnte man einwenden: Bitcoin passt die Difficulty doch alle 2.016 Blöcke an. Eine Kette mit wenig Rechenleistung müsste also irgendwann leichter werden und wieder laufen. Das stimmt im Prinzip – und genau hier wird die Rechnung vernichtend. Block 961.632 lag exakt auf einer Anpassungsgrenze, denn 961.632 entspricht 477 mal 2.016. Die nächste Neuberechnung hätte also bei Block 963.648 stattgefunden, exakt jenem Block, den die Spezifikation als Lock-in vorsah. Um dorthin zu gelangen, hätte die Minderheitskette 2.016 Blöcke unter voller ererbter Difficulty produzieren müssen. Bei rund 0,15 Prozent der Rechenleistung dauert das keine zwei Wochen, sondern etwa 25 Jahre. Der Ausweg existiert. Er ist nur ein Vierteljahrhundert entfernt.
Dazu kommt die dritte, oft vergessene Instanz: die ökonomische Mehrheit. Vor dem Split war die Unterstützung im Wesentlichen auf einen Knoten-Client und einen einzelnen Mining-Pool konzentriert – auf Nutzer von Bitcoin Knots und auf OCEAN, jenen Pool, der 2023 aus demselben Umfeld hervorging. Keine große Börse, kein bedeutender Verwahrer, kein ETF, keine der großen Wallets und kein Zahlungsnetzwerk hat BIP-110 durchgesetzt. Ohne diese Instanzen gibt es für die Coins der Minderheitskette keine Preisfindung, keine Liquidität und keinen Grund für einen Miner, dort Strom zu verbrennen. Die Rechnung ist banal und deshalb unerbittlich: Wenn die Blöcke keinen verkäuflichen Ertrag tragen, hört das Mining auf.
Auch inhaltlich gab es gewichtige Einwände. Adam Back bezeichnete den Vorschlag als bewusste Verschlechterung und warnte, dass die Deaktivierung von OP_IF in Tapscript bestehende Konstruktionen wie Miniscript beschädigen, einzelne UTXOs vorübergehend oder dauerhaft unausgabbar machen und künftige Erweiterungspfade verschließen könnte. Michael Saylor fasste die Lage nach dem Split in einem Satz zusammen, der als Beschreibung der Mechanik kaum zu verbessern ist: Bitcoin habe exakt wie vorgesehen funktioniert – BIP-110 stand es frei abzuspalten, und dem Netzwerk stand es frei, nicht zu folgen.
Bemerkenswerter als der Split ist jedoch, was danach vorgeschlagen wurde. Nachdem die Kette stand, wurde öffentlich der 1. September 2026 als Datum für eine Hard Fork ins Gespräch gebracht, die den Proof-of-Work-Algorithmus ändern würde – jenes Datum, an dem BIP-110 regulär hätte aktiv werden sollen. Die begleitende Argumentation lief darauf hinaus, bestehende Miner ausscheiden zu lassen und bei Bedarf neue anzuwerben. Diese Berichte stützen sich auf Sekundärquellen zu Beiträgen auf X, nicht auf einen veröffentlichten Vorschlag oder eingebrachten Code. Ich behandle sie deshalb als Absichtsbekundung, nicht als Vorhaben.
Doch selbst als bloße Äußerung ist der Gedanke aufschlussreich. Er dreht das Argument um: Nicht der Vorschlag hat sich an der Realität des Netzwerks als nicht mehrheitsfähig erwiesen – sondern die Realität soll ausgetauscht werden, damit der Vorschlag passt. Ein Wechsel des Arbeitsnachweises würde die gesamte akkumulierte Sicherheit des Netzwerks entwerten und die Neutralität zerstören, die Bitcoin überhaupt erst wertvoll macht. Wer die Miner austauscht, weil sie nicht folgen, hat den Mechanismus nicht verstanden: Sie sollen nicht folgen. Sie sollen rechnen. Das Folgen ist die Aufgabe der ökonomischen Mehrheit.
Das Protokoll der Selbstverteidigung
Genug Theorie. Ein Split ist für dich als Halter vor allem eine Phase erhöhter Verwundbarkeit – nicht weil deine Coins gefährdet wären, sondern weil in solchen Fenstern die meisten Fehler passieren. Und die gefährlichsten Fehler entstehen nicht durch Angreifer, sondern durch Hektik. Hier ist das Protokoll, das dich schützt.
Erstens: Nichts übereilen. Setze nicht zwingend notwendige Transaktionen aus, bis eine Kette eindeutig ökonomisch dominiert und das Verhalten deiner Wallet und deiner Dienstleister geklärt ist. Ein Bitcoin-Core-Entwickler hat Händlern während des Risikofensters ausdrücklich geraten, Transfers auszusetzen. Der Grund ist das Replay-Risiko: Sofern beide Zweige eine Transaktion nach denselben Konsens- und Signatur-Regeln akzeptieren und kein wirksamer Replay-Schutz existiert, kann eine auf einem Zweig gesendete Transaktion auf dem anderen wiederholt werden. Das ist keine automatische Folge jeder Abspaltung, aber es ist die Standardannahme, solange du das Gegenteil nicht geprüft hast. Du bewegst dann ungewollt Werte auf einer Kette, die du gar nicht anfassen wolltest.
Zweitens, und das ist die absolute Grenze: Gib deinen Seed niemals irgendwo ein. Bei jedem Split entstehen innerhalb von Stunden Webseiten, Browser-Erweiterungen und Werkzeuge, die dir versprechen, deine Coins auf der neuen Kette einzulösen. Ein Teil davon ist inkompetent, ein Teil ist bösartig, und du kannst die beiden von außen nicht unterscheiden. Deine Seed-Phrase gehört in kein Formular, keine Erweiterung und kein Einlöse-Werkzeug. Niemals. Es gibt keine Ausnahme, die diesen Satz relativiert.
Drittens: Trenne die UTXOs, bevor du irgendetwas ausgibst. Wenn du überhaupt auf einem Zweig aktiv werden willst, dann nur mit Ausgängen, die ausschließlich auf dieser einen Kette existieren – etwa mit nach dem Split entstandenen, zweigspezifischen Ausgängen – und nur nach einer wallet-spezifischen Anleitung aus einer vertrauenswürdigen Implementierung. Nutze dafür ein separates Wallet und einen separaten UTXO-Satz. Vermeide in dieser Phase Adress-Wiederverwendung und prüfe, dass deine Backups aktuell sind.
Viertens: Verifiziere die Kette selbst, nicht das Etikett. Verlasse dich nicht auf ein Tickersymbol oder eine Beschriftung in einer Wallet-Oberfläche. Prüfe Blockhöhe, Block-Hash, kumulierte Arbeit und mit welchen Gegenstellen deine Software spricht. Und geh nicht davon aus, dass ein Guthaben bei einer Börse dir automatisch einen Anspruch auf Coins der Minderheitskette verschafft – ob ein Verwahrer gutschreibt, entscheidet allein seine schriftliche Fork-Richtlinie.
Bleibt die Einordnung, mit der du aus diesem Dispatch gehen solltest. Was am 8. und 9. August passiert ist, war kein Angriff auf Bitcoin und keine Krise. Es war ein Funktionsnachweis. Eine Gruppe hat versucht, eine Regeländerung ohne breite Zustimmung durchzusetzen, hat die dafür vorgesehene Möglichkeit genutzt, sich abzuspalten – und das Netzwerk ist ihr schlicht nicht gefolgt. Kein Gremium musste eingreifen, keine Instanz entscheiden. Die Mechanik hat gereicht.
Genau darin liegt die beruhigende Lehre. Bitcoins Konsens ist nicht deshalb stabil, weil alle einer Meinung wären, sondern weil eine dauerhaft tragfähige Regeländerung drei Dinge zugleich braucht: kompatible Software bei den ökonomisch relevanten Validierern, ausreichende Blockproduktion, und eine Infrastruktur aus Börsen, Verwahrern und Wallets, welche die resultierenden Coins annimmt und bewertet. Das ist keine formale Gewaltenteilung, sondern eine schlichte Beobachtung darüber, was in der Praxis zusammenkommen muss. Fehlt eines davon, entsteht kein neues Bitcoin – es entsteht eine Kette, die nach zwei Blöcken stehen bleibt. Und das ist nicht das Versagen des Systems, sondern seine präziseste Funktion.
Prüfe die Regeln selbst. Vertraue keiner Oberfläche.
In einem Split entscheidet nicht, wer am lautesten ruft, sondern wer selbst validiert. Ein eigener Knoten sagt dir, welche Regeln gelten. Eigene Schlüssel sagen dir, dass du handlungsfähig bleibst. Beides zusammen macht dich unabhängig von jeder Fork-Richtlinie und jedem Einlöse-Werkzeug.
George V.
Lead Architect, BitAtlas
DISPATCH #014 | 10. AUGUST 2026 | STATUS: CRITICAL_ALARM