BIP-110 gescheitert: jetzt soll BLAKE2b es richten

Am 8. August 2026 hat sich die BIP-110-Kette vom Bitcoin-Netzwerk getrennt, und seither kommt sie nicht mehr vom Fleck: vier Blöcke in einer Woche, wo die Hauptkette rund tausend schafft. Wir haben den Vorschlag am 2. Juli in BIP-110: Warum es nichts bringt und wieso es sogar gefährlich ist auseinandergenommen und vorhergesagt, dass die Aktivierung an fehlender Hashrate scheitern wird. Genau das ist eingetreten. Interessant ist deshalb nicht mehr das Scheitern, sondern das, was die Befürworter jetzt daraus machen: Sie wollen Bitcoins Proof of Work austauschen — gegen einen Algorithmus, den ein Testnet-Block ausgelost hat.

Was am 8. August wirklich passiert ist

Der letzte gemeinsame Block beider Ketten war 961.631. Bei Höhe 961.632 begann das Fenster, in dem BIP-110 von jedem Block eine Signalisierung auf Bit 4 verlangt. Blöcke ohne dieses Signal gelten für eine BIP-110-Node ab da als ungültig.

Die Hauptkette lieferte ihren Block 961.632 am 8. August um 19:35:55 UTC, gefunden von AntPool, mit 5.612 Transaktionen und einer Netzwerk-Difficulty von rund 127,5 Billionen. Das lässt sich in jedem Explorer nachsehen, etwa bei mempool.space. Dieser Block signalisierte nicht — die BIP-110-Nodes verwarfen ihn und blieben stehen, bis ein eigener Miner einen eigenen Block 961.632 fand. Ab diesem Moment gab es zwei Ketten.

Wie knapp die Sache war, sagt die Zahl, die BIP-Editor Mark Erhardt am 9. August auf der Entwickler-Mailingliste nannte: BIP-110 kam auf „just shy of 2.5% of blocks signaling readiness". Nötig gewesen wären 55 Prozent, also 1.109 von 2.016 Blöcken. Was ein Soft Fork und was ein Hard Fork ist und warum der Unterschied hier zählt, steht in Unterschied zwischen Hardfork und Softfork in der Blockchain.

Ein Detail, das in der Berichterstattung untergeht: 961.632 ist durch 2.016 teilbar — 2.016 mal 477 ergibt exakt diese Höhe. Die Abspaltung fiel also punktgenau auf eine Difficulty-Anpassung. Das war kein Zufall, sondern gewollt, und es hat für die Abspaltung die denkbar schlechteste Folge.

Die Difficulty-Falle: 2.016 Blöcke bis zur Anpassung

Eine abgespaltene Kette erbt die Schwierigkeit der Kette, von der sie sich trennt — hier also die vollen 127,5 Billionen, aufgestellt für ein Netz mit hunderten Exahash. Angepasst wird erst nach 2.016 eigenen Blöcken. Weil der Split exakt auf der Anpassungsgrenze lag, muss die BIP-110-Kette diese 2.016 Blöcke vollständig durchziehen, bevor ihre Difficulty auch nur ein einziges Mal fällt. Wer wissen will, wie diese Mechanik funktioniert: Was ist die Mining Difficulty.

Nach Angaben von Bitcoin.com stand die Abspaltung am 15. August bei Block 961.635, also vier Blöcken in sieben Tagen, gefunden vom Pool Roughnecks. Diese Zahl liess sich nicht gegen einen neutralen Explorer prüfen und ist als Medienangabe zu lesen. Rechnet sie trotzdem einmal durch: Bei vier Blöcken pro Woche braucht die Kette für 2.016 Blöcke rund 3.500 Tage — knapp zehn Jahre bis zur ersten Anpassung. Die kursierenden Schätzungen reichen von 350 Tagen bis 25 Jahren, je nach unterstellter Hashrate; die beobachtete Blockrate liegt am pessimistischen Ende.

Das ist kein Anlaufproblem, das sich mit Geduld löst, sondern ein Zustand, in dem eine Kette technisch existiert und wirtschaftlich nicht stattfindet — mit Folgen für jeden, der noch auf ihr sendet.

Ocean schickte 18 Stunden Hashrate auf die tote Kette

Der Mining-Pool Ocean räumte ein, dass ein Konfigurationsfehler Miner rund 18 Stunden lang auf der BIP-110-Kette arbeiten liess, obwohl diese den Endpunkt für die andere Kette gewählt hatten. Der Pool kündigte auf X rund 0,3 BTC Entschädigung an, auszuzahlen binnen 72 Stunden.

Als Lehrstück ist der Vorfall mehr wert als die Summe, denn er zeigt, wer bei einer Kettenspaltung tatsächlich entscheidet: nicht der Miner, sondern derjenige, der die Arbeitsaufträge verteilt — dasselbe Machtgefälle, das wir in Stratum V2 und die Coinbase-Hoheit beschrieben haben.

Der Plan: Proof of Work wechseln und die Miner feuern

Statt das Ergebnis anzunehmen, kündigten die Befürworter einen Ausweg an. Luke Dashjr, langjähriger Bitcoin-Entwickler und Mitautor auf der BIP-110-Seite, schrieb bereits am 5. August auf X: „If BIP110 doesn't pan out, the only option is a PoW change."

Ein Wechsel des Proof-of-Work-Algorithmus macht jeden vorhandenen Bitcoin-ASIC auf dieser Kette wertlos. Die Geräte rechnen SHA-256d in Hardware und können nichts anderes. Das ist kein Nebeneffekt, das ist der Zweck: Wer die Miner nicht überzeugen kann, schliesst sie aus.

„Bpedo": Wer hier wen angegriffen haben soll

Bemerkenswert ist, wie die Vorgänge seither beschrieben werden. Noch am Abend des 8. August schrieb Dashjr auf seinem X-Konto: „. @AntPoolofficial appears to be attacking Bitcoin. Hold tight everyone." Gemeint war der Pool, der wenige Stunden zuvor den regulären Block 961.632 gefunden hatte.

Am 12. August legte er unter der Überschrift „Facts" nach. Vier Punkte, sinngemäss: Am Samstag hätten „bad actors" einen strittigen Hard Fork versucht, „with the purpose of forcing users to distribute CSAM"; daraus sei eine neue „scamcoin with an airdrop" entstanden, die er „Bpedo" nennt. Die ehemaligen Bitcoin-Pools würden das Netzwerk angreifen, „to try to deceive the world into thinking Bpedo is 'the real Bitcoin'". Wer keine eigene Node betreibe, falle darauf herein; ein Upgrade auf „the latest release of Bitcoin Knots" bringe einen zurück „on the Bitcoin network". Und: „Community-led mitigations are in progress to overcome the ongoing attack" — erwartet zum 1. September.

Nüchtern betrachtet steht hier die Realität auf dem Kopf. Die Kette mit 97,5 Prozent der Hashrate hat keine Regel geändert — sie läuft unverändert weiter. Geändert hätte die Regeln der Vorschlag, der die nötige Zustimmung nicht bekam. Wer nichts tut, forkt nicht. Auch der CSAM-Vorwurf trägt die Last nicht, die ihm aufgeladen wird: Dahinter steht die seit Jahren bekannte Tatsache, dass sich beliebige Daten in Transaktionen einbetten lassen — ein Problem, das mit dem gescheiterten Fork weder entstanden noch verschwunden ist, und das kein Miner „erzwingt".

Die Zuspitzung hat einen praktischen Zweck: Wenn die Mehrheitskette ein Betrug ist, ist der Wechsel des Proof of Work keine Abspaltung mehr, sondern Notwehr.

BLAKE2b, ausgewürfelt auf Testnet4

Wie der neue Algorithmus bestimmt wurde, kündigte Dashjr am 11. August auf X im Detail an. Ab 14:00 UTC werde die Testnet4-Kette beobachtet. Dann: „The very next block found, look at the block hash. The last character will choose the new algorithm." Aus einer zuvor zusammengestellten, nach Eignung gewichteten Kandidatenliste sollte also das letzte Zeichen eines Testnetz-Blockhashes auswählen — ein Hexadezimalzeichen, sechzehn Möglichkeiten. Um Manipulation auszuschliessen, veröffentlichte er vorab den SHA256-Hash der Zuordnungstabelle: „You can prove I didn't rig it".

Einen Tag später stand das Ergebnis fest: BLAKE2b, mit einem geplanten Hard Fork zum 1. September 2026. Begründet wird die Wahl damit, dass BLAKE2b auf gewöhnlichen CPUs und GPUs laufe und die ASIC-Dominanz breche.

Die Vorab-Festlegung per Hash ist sauber gemacht, das sei ausdrücklich gesagt: Sie beweist, dass die Tabelle nachträglich nicht verändert wurde. Über die Frage, die zählt, beweist sie nichts. Denn welcher Hash-Algorithmus die Sicherheit eines Netzwerks im Milliardenbereich trägt, gehört in eine mehrjährige Prüfung mit Kryptografen, Referenzimplementierungen, Testnetzen und veröffentlichten Angriffsmodellen — nicht in ein Verfahren, dessen Ergebnis am letzten Zeichen eines Testnetz-Blockhashes hängt. Grosse Sorgfalt lag darauf, dass die Ziehung fair ist, und keine erkennbare darauf, ob überhaupt gezogen werden sollte. Manipulationssicher ausgewürfelt bleibt ausgewürfelt.

Wer Proof of Work tauscht, hat aufgehört, Bitcoin zu sein

Das eigentliche Problem liegt tiefer als die Frage, ob BLAKE2b ein guter Algorithmus ist. Bitcoins Sicherheit besteht nicht aus Regeln in einem Dokument, sondern aus über sechzehn Jahren aufgehäufter Rechenarbeit in SHA-256d. Diese Arbeit ist der Grund, warum sich die Kette nicht umschreiben lässt.

Ein Algorithmuswechsel setzt genau diesen Zähler auf null. Ab dem ersten BLAKE2b-Block sichert eine Kette, die eine sechzehnjährige Transaktionshistorie mit sich trägt, sich selbst mit der Rechenleistung eines Hobbynetzwerks. Wer sie umschreiben will, braucht dann keine Milliarden an Hardware mehr, sondern eine Handvoll Server. Die Befürworter wollen Bitcoin vor einem Angriff schützen und bauen dabei genau die Bedingung her, gegen die Proof of Work überhaupt schützt.

Der Streit um die BIP-Editoren

Parallel läuft ein zweiter Konflikt. Jon Atack beantragte am 9. August auf der Entwickler-Mailingliste, den Status von BIP-110 von „Deployed" auf „Closed" zu setzen, weil das Netzwerk den Fork abgelehnt habe. Widerspruch kam unter anderem von Greg Tonoski, der auf rund 18.000 Nodes verwies, die BIP-110 akzeptieren, und fragte, ob deren Guthaben damit zur Beschlagnahmung freigegeben sei. Sjors Provoost hielt dagegen, dass ein geschlossener BIP-Status niemandem etwas wegnimmt.

Am selben Tag beantragte Mark Erhardt in Pull Request 2248 die Abberufung von Luke Dashjr als BIP-Editor. Die Begründung nennt Interessenkonflikte bei einem Vorschlag, an dem er selbst beteiligt war, weniger als ein Prozent der Editor-Kommentare seit April 2024 und die vorzeitige Vergabe einer BIP-Nummer auf X, bevor der Vorschlag auf der Mailingliste diskutiert war. Die zugehörige Debatte steht in der Mailingliste.

Vollzogen wurde die Abberufung schnell. Bryan Bishop hielt am 10. August auf der Mailingliste fest: „The individual known as Luke Dashjr is no longer an authorized user in the BIP content repository." Damit ist der Schreibzugriff weg — die Rolle also faktisch beendet, keine 26 Stunden nach dem Antrag.

Formal hinkt die Dokumentation nach: Pull Request 2248 war am 17. August unverändert offen, und BIP 3, das die Zuständigen auflistet, führte ihn weiterhin auf. Wer die Lage prüfen will, schaut in beide Dokumente statt auf Schlagzeilen — die einen melden die Entfernung als abgeschlossen, die anderen zeigen sie noch nicht.

Was ihr tun könnt

Das Signalisierungsfenster ist vorbei, der angekündigte Hard Fork zum 1. September ist es nicht. Für die kommenden zwei Wochen gilt deshalb dasselbe wie im August:

• Prüft, welche Software eure Node fährt. Bitcoin Core und Bitcoin Knots vor der RDTS-Erweiterung sind konsensidentisch und folgen derselben Kette; die Unterschiede liegen in der Weiterleitungspolitik. Was das konkret heisst, steht in Bitcoin Knots vs. Bitcoin Core.
• Betreibt ihr Lightning-Kanäle, behaltet den 1. September im Auge. Ein offener Kanal über eine Kettenspaltung hinweg ist eine doppelte Haftung, weil der Gegenpart widerrufene Zustände auf der Kette veröffentlichen kann, die ihr nicht überwacht.
• Wenn ihr mint, klärt vorher, welche Kette euer Pool bedient und ob ihr das selbst umstellen könnt. Der Ocean-Vorfall zeigt, dass die Voreinstellung im Zweifel gegen euch läuft. Wer die Kettenwahl nicht abgeben will, betreibt Solo-Mining — etwa über blitzpool.yourdevice.ch oder einen anderen Solo-Pool, bei dem ihr die Node hinter dem Pool kennt.
• Verlasst euch bei einer Spaltung nicht auf eine Börse: Ob ihr auf einer, beiden oder keiner Kette gutgeschrieben werdet, entscheidet der Verwahrer nachträglich. Eigene Verwahrung und eine eigene Full Node sind der Unterschied zwischen Mitreden und Abwarten.

Wenn eure Node auf der Abspaltung hängt

Wer eine Knots-Version mit den RDTS-Regeln fährt, sieht die Hauptkette gar nicht: Die Node hat deren Block 961.632 als ungültig markiert und bleibt auf 961.631 stehen. Wer in diesem Zustand eine Transaktion gesendet hat, wartet womöglich unbegrenzt auf die Bestätigung — auf einer Kette, auf der alle paar Tage ein Block gefunden wird. Der Weg zurück, exemplarisch für eine Linux-Node:

# 1. Node stoppen
bitcoin-cli stop

# 2. Wallet-Verzeichnis sichern, bevor irgendetwas angefasst wird
cp -a ~/.bitcoin/wallets ~/wallets-backup-$(date +%F)

# 3. Binary austauschen: Bitcoin Core installieren oder eine
#    Knots-Version ohne die RDTS-Regeln. Danach Node starten.

# 4. Stand pruefen
bitcoin-cli getblockchaininfo | grep -e '"blocks"' -e bestblockhash

# 5. Haengt die Node weiter auf 961.631, den als ungueltig
#    markierten Hauptketten-Block wieder zulassen:
bitcoin-cli reconsiderblock \
  00000000000000000000d1e01392faa65ceeaed307f0a3159144b84146ff24ba

# 6. Bleibt sie stehen, den Blockindex neu aufbauen:
bitcoind -reindex-chainstate

Danach gleicht ihr Höhe und bestblockhash mit einem öffentlichen Explorer ab. Stimmen beide überein, seid ihr wieder auf der Kette, auf der der Rest des Netzes rechnet. Transaktionen, die auf der Abspaltung unbestätigt liegen geblieben sind, müsst ihr auf der Hauptkette neu senden.

Gebt eure Seed-Phrase nirgends ein, um Fork-Coins zu holen

Bei jeder Kettenspaltung tauchen Angebote auf, die versprechen, die Coins auf der neuen Kette „freizuschalten": eine Seite, eine App, ein Formular für eure Wiederherstellungsphrase. Tut das unter keinen Umständen, auch nicht, wenn das Angebot aus dem Umfeld des Forks selbst kommt.

Eure Seed-Phrase ist nicht der Schlüssel zu den Fork-Coins. Sie ist der Schlüssel zu allen euren Coins, auf jeder Kette, die aus demselben Ursprung hervorgegangen ist. Wer sie bekommt, räumt euer Guthaben auf der Hauptkette ab — und das ist echtes Geld, während Coins auf einer Kette mit vier Blöcken pro Woche und ohne Börsenanbindung praktisch nichts wert sind. Das Geschäft lautet also: alles riskieren für nichts.

Fazit: BIP-110 ist an der Arithmetik gescheitert, nicht an einer Verschwörung

BIP-110 hatte einen Mechanismus, der bei 55 Prozent Zustimmung greift, und bekam knapp 2,5. Danach braucht es keine Verschwörung mehr, nur eine Division. Die Kette, die daraus entstand, schafft vier Blöcke pro Woche und bräuchte in diesem Tempo ein Jahrzehnt bis zur ersten Difficulty-Anpassung. Das ist keine Unterdrückung durch eine Übermacht, sondern das vorhersehbare Ergebnis eines Plans, der die Hashrate für eine Formsache hielt.

Die Antwort darauf — einen ausgelosten Algorithmus einzuführen und die Mehrheit des Netzes zu Angreifern zu erklären — beendet die Diskussion, statt sie zu gewinnen. Eine Kette mit neuem Proof of Work ist kein gerettetes Bitcoin. Sie ist ein neues Projekt mit einer alten Transaktionshistorie und ohne die Arbeit, die diese Historie bisher geschützt hat. Es steht jedem frei, so etwas zu starten. Nur sollte es dann seinen eigenen Namen tragen.

Für alle anderen hat der August eine beruhigende Nachricht geliefert: Bitcoins Konsensregeln lassen sich nicht per Ankündigung ändern, auch nicht von langjährigen Entwicklern mit lauter Stimme. Das ist genau die Eigenschaft, wegen der sich das Ganze lohnt.

Quellen und weiterführende Links

• BIP-110: Reduced Data Temporary Softfork — Text des Vorschlags mit Aktivierungsparametern
• bitcoindev: BIP 110 – update status to closed — Debatte ab 9. August 2026
• bitcoindev: Motion to remove Luke Dashjr from BIP Editors
• bitcoin/bips Pull Request 2248: process – Remove Luke from BIP Editors
• BIP 3 — Liste der amtierenden BIP-Editoren
• mempool.space: Block 961.632 — Zeitstempel, Miner, Difficulty und Blockhash der Hauptkette
• Luke Dashjr am 5. August 2026 zum möglichen PoW-Wechsel
• Luke Dashjr am 11. August 2026 zum Auswahlverfahren über Testnet4
• Das X-Konto von Luke Dashjr — Fundstelle der Beiträge vom 8. und 12. August 2026 („attacking Bitcoin", „Facts"/„Bpedo")
• Ocean zur Entschädigung nach dem Konfigurationsfehler
• Start9: Navigating the BIP-110 (RDTS) Activation — Hinweise für Node- und Lightning-Betreiber
• bip110.run — Statusanzeige zu Signalisierung und Kettenspitzen
• Bitcoin.com: BIP-110 Breakaway Chain Faces a Long Fight to Survive — Fundstelle für Blockstand und Pool der Abspaltung