BIP-110: Warum es nichts bringt und wieso es sogar gefährlich ist

Rund um den 7. August 2026 soll etwas passieren, das seit 2017 nicht mehr auf dem Tisch lag: eine erzwungene Regeländerung im Bitcoin-Netzwerk, durchgesetzt gegen die überwältigende Mehrheit der Miner. Das Vehikel heisst BIP-110, und seine Befürworter verkaufen es als kleinen, temporären «Guardrail» gegen Spam. Wir sehen darin etwas anderes: einen Versuch, Zensur ins Protokoll zu schreiben, der technisch scheitern wird – und dabei ein reales Risiko für alle schafft, auch für euch.

In diesem Beitrag zerlegen wir, was BIP-110 überhaupt ist, warum die Aktivierungsmethode ein Denkfehler ist, weshalb die entstehende «Supporter-Chain» nicht lebensfähig sein kann und warum die Behauptung, man müsse sich «aus Sicherheitsgründen» anschliessen, das Gegenteil der Wahrheit ist.

Was ist BIP-110 überhaupt?

BIP-110 trägt den offiziellen Titel Reduced Data Temporary Softfork und wurde von einem Autor unter dem Pseudonym Dathon Ohm eingereicht (ursprünglich als BIP-444 im Oktober 2025). Es handelt sich um einen auf ein Jahr befristeten Soft Fork, der die Menge an beliebigen Daten begrenzen soll, die man in Bitcoin-Transaktionen unterbringen kann. Ziel sind Ordinals, Inscriptions, grosse OP_RETURN-Payloads und ähnliche Konstruktionen. Die Details stehen auf der Kampagnenseite bip110.org.

Konkret führt BIP-110 sieben neue Gültigkeitsregeln ein, unter anderem:

• Neue Outputs werden auf 34 Bytes begrenzt, OP_RETURN auf maximal 83 Bytes.
• Daten-Pushes und Witness-Elemente werden auf 256 Bytes gedeckelt.
• Bestimmte Opcodes, Taproot-Annexes und grosse Control Blocks werden temporär eingeschränkt.
• UTXOs, die vor der Aktivierung existierten, sind dauerhaft ausgenommen – bestehende Gelder sind also nicht direkt betroffen.

Die Regeln laufen nach rund 52'416 Blöcken (etwa ein Jahr) automatisch wieder aus. Wichtig für die Einordnung: BIP-110 wird nicht in Bitcoin Core entwickelt, sondern baut auf Bitcoin Knots auf – jener alternativen Node-Software, die Luke Dashjr pflegt und die bereits konservativere Filter mitbringt. Wer den grundsätzlichen Unterschied zwischen den beiden Implementierungen verstehen will, findet das in unserem älteren Beitrag Bitcoin Knots vs. Bitcoin Core.

Der Aktivierungsmechanismus: 55 % statt 95 % – und dann Zwang

Hier wird es interessant, und hier liegt der eigentliche Sprengstoff. BIP-110 nutzt einen modifizierten BIP9-Mechanismus: Miner signalisieren Zustimmung, indem sie Bit 4 im Versionsfeld ihrer Blöcke setzen. Für ein frühes Lock-in genügen laut Spezifikation 55 % der Blöcke innerhalb einer Difficulty-Periode (1'109 von 2'016) – nicht die historisch üblichen 95 %.

Der eigentliche Hebel ist aber das Forced Signaling (Mandatory Signaling). Ab Block 961'632 – projiziert auf ca. den 7. August 2026, gegen 17:59 UTC – lehnen BIP-110-Nodes jeden Block ab, der Bit 4 nicht setzt. Das Fenster läuft bis Block 963'647. Die Idee: Miner sollen gezwungen werden, mitzumachen, weil ihre Blöcke sonst von den BIP-110-Nodes als ungültig verworfen werden.

Genau das hat Dathon Ohm Ende Juni öffentlich als «ATTENTION. THIS IS NOT A DRILL» angekündigt: Alle Miner müssten Bit 4 setzen, sonst würden ihre Blöcke als ungültig verworfen. Das klingt nach einer Drohung mit Autorität – ist in Wahrheit aber ein Bluff, und das lässt sich vorrechnen.

Der zentrale Denkfehler: Forced Signaling ohne Hashrate

Befürworter ziehen gern die Segwit-Aktivierung von 2017 als Vorbild heran. Der Vergleich hinkt an der entscheidenden Stelle. Bei Segwit stand am Ende eine grosse Mehrheit der Hashpower hinter der Aktivierung – die Segwit-Chain war die längste Chain, und selbst Nicht-Unterstützer folgten ihr nach geltender «heaviest chain»-Regel automatisch. Der oft zitierte UASF (BIP148) musste 2017 gar nie scharf geschaltet werden, weil Segwit letztlich über Miner-Signaling (MASF) aktiviert wurde. Das erklärt auch Jameson Lopp ausführlich in seinem Layman's Guide to BIP-110.

Bei BIP-110 ist die Ausgangslage umgekehrt. Das Signaling lag Ende Juni 2026 bei rund 0,31 % der Hashrate – etwa 5 EH/s von rund 940 EH/s im Netzwerk, zeitweise sogar 0,00 %. Kein einziger grosser Pool signalisiert; die Signalblöcke stammen praktisch ausschliesslich von Ocean, dem Pool von Luke Dashjr. Bei so wenig Rückhalt passiert Folgendes:

1. Ab dem Forced Signaling verwerfen die BIP-110-Nodes alle Blöcke ohne Signal.
2. Die Blöcke ohne Signal stellen aber die überwältigende Mehrheit – die Nicht-Supporter-Chain ist damit die längere Chain.
3. Nicht-Unterstützer minen auf der Nicht-Supporter-Chain weiter, die wenigen Unterstützer auf ihrer eigenen. Ergebnis: ein Chain-Split.

Und jetzt kommt der Teil, den die Befürworter nicht gern rechnen. Es gibt keine Anpassung der Difficulty beim Split. Auf der BIP-110-Chain arbeiten aber nur noch ein Bruchteil der Miner. Bei 1 % der Hashrate dauert ein Block im Schnitt nicht mehr 10 Minuten, sondern rund 17 Stunden. Bei den real signalisierten ~0,31 % wären es über 53 Stunden – mehr als zwei Tage pro Block.

Noch dramatischer ist das Difficulty-Retargeting: Die Schwierigkeit passt sich erst nach 2'016 Blöcken an. Bei 1 % Hashrate würde diese erste Anpassung erst nach rund 3,8 Jahren greifen. Eine Chain, auf der man tagelang auf eine einzige Bestätigung wartet und die sich fast vier Jahre lang nicht selbst korrigieren kann, ist schlicht nicht als Geldnetzwerk brauchbar. Die zentrale Frage aus der Community bleibt unbeantwortet: Wie soll diese Chain lebensfähig sein?

Adam Back bringt es auf den Punkt: Was hier entstünde, wäre kein Bitcoin-Upgrade, sondern eher eine separate Coin – vergleichbar mit Bitcoin Gold, das 2017 zwar abspaltete, aber nie das Original herausforderte.

Warum ein Chain-Split gefährlich ist – auch für euch

Ein Chain-Split ohne Replay-Schutz ist kein theoretisches Ärgernis. Das letzte Mal, dass Bitcoin einen Split ohne Replay-Schutz erlebte, war 2013. Lopp, der 2017 bei BitGo die Infrastruktur auf den beinahe eingetretenen SegWit2X-Split vorbereiten musste, beschreibt genau dieses Szenario als Albtraum: Unsicherheit darüber, welche Chain «gewinnt», Double-Spend-Risiko und ein Ökosystem, das vorsorglich zum Stillstand kommt.

Besonders heikel wird es für Layer 2, allen voran das Lightning Network. Lightning-Sicherheit beruht auf einer stillschweigenden Annahme: Beide Channel-Partner sehen dieselbe Chain und können darauf im Streitfall dieselben Transaktionen durchsetzen. Bei einem Split mit zwei unterschiedlichen Chain-Tips fällt diese Annahme weg. Die Folge sind mehrere neue Angriffsflächen:

• Justice- bzw. Penalty-Transaktionen können ins Leere laufen. Wenn ein Betrugsversuch nur auf einer der beiden Chains sichtbar ist, kann die Straftransaktion auf der anderen Chain wirkungslos bleiben – oder wegreorganisiert werden.
• Timelocks verhalten sich unerwartet, weil die beiden Chains unterschiedlich schnell wachsen und Blockhöhen auseinanderdriften.
• Watchtowers reagieren zu spät oder auf der falschen Chain, weil sie den relevanten Broadcast nicht dort sehen, wo er zählt.
• Bestätigungen vermitteln eine Scheinsicherheit, obwohl dieselben Coins auf der Gegen-Chain noch verschiebbar sind.

Wir nennen hier bewusst keine Schritt-für-Schritt-Anleitung – die Mechanik ist konkret genug ausgearbeitet worden, dass sie in der Community bereits als Diebstahlsszenario diskutiert wird. Genau das ist der Punkt: Ein erzwungener Split verwandelt eine ideologische Debatte in ein handfestes finanzielles Risiko für unbeteiligte Dritte. Auch BitMEX Research warnte, dass ein Angreifer im Extremfall sogar illegale Inhalte on-chain platzieren könnte, um eine gewünschte Reorg zu erzwingen – ausgerechnet eine Folge der Zensur-Logik, die BIP-110 verkauft.

Dazu kommt ein handwerkliches Problem: Ein Bitcoin-Core-Entwickler (l0rinc) fand im BIP-110-Code einen Konsensfehler rund um Cache-Poisoning bei einer Reorg an der Aktivierungsgrenze, der monatelang unbemerkt blieb. Für einen Vorschlag, der das Fundament des Netzwerks anfassen will, ist das kein gutes Zeichen.

Warum BIP-110 nichts bringt: Bitcoin regelt Spam über Gebühren

Der ganze Aufwand wäre vielleicht noch diskutabel, wenn er sein Ziel erreichte. Tut er nicht. Bitcoin reguliert «Spam» seit jeher selbst – über einen offenen Markt für Blockspace und die Gebühren. Wer Daten unterbringen will, zahlt dafür; teurer Blockspace verdrängt minderwertige Nutzung von allein. Das ist der marktwirtschaftliche, zensurfreie Mechanismus, und er funktioniert ohne dass jemand entscheiden muss, welche Transaktion «erwünscht» ist.

BIP-110 ersetzt diesen Mechanismus durch eine subjektive Regel darüber, was in einen Block darf – also durch Zensur. Und selbst diese Zensur ist trivial umgehbar: Peter Todd hat den kompletten BIP-110-Text on-chain eingebettet und dabei alle Regeln des Vorschlags eingehalten, um zu demonstrieren, dass sich die Beschränkungen mit minimalem Aufwand aushebeln lassen. Ein Filter, der das Grundprinzip der Zensurresistenz opfert und trotzdem nicht filtert, ist das schlechteste beider Welten.

Die Reaktionen aus der Branche fallen entsprechend deutlich aus. Alex Thorn von Galaxy Digital nannte den Soft Fork einen «Angriff auf Bitcoin», Michael Saylor stufte ihn als Protokoll-Bedrohung ein, und Lopp bezeichnet den Vorschlag schlicht als rücksichtslos und zum Scheitern verurteilt.

«Gefährlich, sich nicht anzuschliessen»? Genau umgekehrt

Aus dem Umfeld von Luke Dashjr kommt das Narrativ, es sei gefährlich, sich BIP-110 nicht anzuschliessen – Miner riskierten, dass ihre Blöcke verworfen würden. Diese Drohung dreht die Realität um.

Verworfen werden die Blöcke nur von den BIP-110-Nodes selbst. Ein Soft Fork, der Blöcke ablehnt, funktioniert nur dann, wenn die ablehnenden Nodes jene sind, die ein Miner zwingend braucht, um seine Coinbase-Rewards zu «verkaufen» – also die wirtschaftlich relevanten Nodes, an denen Börsen, Zahlungsdienstleister und Nutzer hängen. Bei einem Rückhalt von unter 1 % ist das nicht der Fall. Die BIP-110-Nodes haben, wie Lopp trocken feststellt, keine ökonomische Macht. Wer nicht signalisiert, bleibt schlicht auf der Chain mit der gesamten Hashpower, der gesamten Liquidität und dem gesamten Ökosystem.

Die neueste Volte: «Null Blöcke lehnen BIP-110 ab»

Weil das «gefährlich, nicht mitzumachen»-Narrativ nicht verfängt, wird das Argument inzwischen schlicht auf den Kopf gestellt. Auf den Einwand, dass unter 1 % der Miner BIP-110 unterstützen, entgegnet Dashjr, «readiness» sei nicht dasselbe wie Unterstützung, Miner träfen die Entscheidung ohnehin nicht – und bemerkenswerterweise gebe es «zero blocks signalling rejection of BIP110». Kein einziger Block signalisiere also eine Ablehnung, ergo laufe es auf eine erfolgreiche Aktivierung hinaus.

Das ist ein rhetorischer Taschenspielertrick. Im Signaling-Mechanismus von Bitcoin gibt es kein «Nein»-Bit. Die einzige Möglichkeit, einen Soft Fork abzulehnen, besteht darin, Bit 4 nicht zu setzen – und genau das tun über 99 % der Blöcke. Schweigen ist hier keine Zustimmung, sondern die einzige verfügbare Form des Widerspruchs, und sie fällt so deutlich aus, wie sie nur ausfallen kann. Die Behauptung, das Fehlen expliziter Ablehnungsblöcke bedeute Zustimmung, ist ungefähr so schlüssig wie die Aussage, alle seien dafür, weil auf dem Stimmzettel keine «Dagegen»-Box abgedruckt war.

Auch die beiden Vorstufen des Arguments tragen nicht. «Readiness» ohne Signal ist für die Aktivierung schlicht unsichtbar – der Mechanismus zählt gesetzte Bits, keine unausgesprochenen Absichten. Und der Satz «Miner entscheiden nicht» ist die klassische UASF-Denkfigur: Angeblich entscheiden die wirtschaftlich relevanten Nodes. Das funktioniert aber nur, wenn diese Nodes ökonomisches Gewicht haben – bei einem Rückhalt im Promillebereich haben sie das nachweislich nicht.

Zudem stimmt schon die Prämisse nicht: Grosse Pools wie F2Pool haben BIP-110 öffentlich abgelehnt. Und selbst wenn ein kleiner Teil der Hashrate mitzöge, wäre eine Minderheits-Chain für Miner wirtschaftlich unattraktiv: Coinbase-Rewards sind erst nach 100 Bestätigungen ausgabefähig – bei zwei Blöcken pro Tag rund 50 Tage, und Börsen würden auf einer Chain mit Minderheits-Hashrate wegen des Reorg-Risikos noch weit mehr Bestätigungen verlangen. Rationale Miner bleiben auf so einer Chain schlicht nicht.

Gefährlich ist also nicht das Nicht-Mitmachen. Gefährlich ist der Versuch, eine Regeländerung ohne Konsens zu erzwingen und dabei einen Split zu provozieren, der reale Gelder auf Layer 2 gefährdet. Die hohen Node-Zahlen von Knots taugen dabei nicht als Gegenargument: Nodes sind nicht Sybil-resistent, das Betreiben ist billig, und der auffällig hohe Tor-Anteil unter den signalisierenden Nodes lässt vermuten, dass hinter vielen «Stimmen» wenige Akteure stehen.

Fazit

BIP-110 ist ein Lehrstück darüber, wie man es nicht macht. Der Vorschlag will ein Problem lösen, das der Gebührenmarkt bereits regelt, mit einem Mittel – Zensur –, das dem Kern von Bitcoin widerspricht, über einen Mechanismus, der ohne Hashrate-Mehrheit nur einen unbrauchbaren Chain-Split erzeugen kann, und mit Regeln, die sich nachweislich umgehen lassen. Übrig bleibt ein reales Risiko für Lightning-Nutzer und ein Reputationsschaden für ein Netzwerk, dessen wichtigste Eigenschaft gerade seine Berechenbarkeit und Zensurresistenz ist.

Unsere Empfehlung ist unaufgeregt: Lasst euch von «THIS IS NOT A DRILL»-Rhetorik nicht drängen. Betreibt die Node-Software, der ihr vertraut, versteht die Aktivierungsmechanik, und behaltet – gerade wenn ihr Lightning-Channels betreibt – die erste Augustwoche im Auge. Mit an Sicherheit grenzender Wahrscheinlichkeit verpufft BIP-110 als lautes, aber folgenloses Ereignis. Vorbereitet zu sein, kostet nichts. Panik dagegen ist genau das, was hier verkauft werden soll.