BIP-110: Droht Bitcoin im August die Spaltung des Netzwerks?

Bitcoin könnte Anfang August zum ersten Mal seit der Abspaltung von „Bitcoin Cash (BCH)“ im Jahr 2017 vor einer neuen Kettenspaltung (Chain-Split) stehen. Der Auslöser ist diesmal allerdings kein Streit um größere Blöcke, keine akute Sicherheitslücke und auch keine weithin gewünschte Erweiterung des Protokolls. Stattdessen will eine kleine Gruppe von Akteuren bestimmte Formen der Datenspeicherung für rund ein Jahr durch zusätzliche Konsensregeln unterbinden. Der ursprünglich als BIP-444 diskutierte Vorschlag trägt den Titel „Reduced Data Temporary Softfork“ und richtet sich vor allem gegen sogenannte Ordinals, Inscriptions und andere Anwendungen, bei denen größere Datenmengen in Bitcoin-Transaktionen eingebettet werden. Dazu sollen verschiedene Bitcoin-spezifische Elemente, Output-Skripte und mehrere Taproot-Konstruktionen eingeschränkt werden. Die Kritik oder die Wurzel dessen, wo diese herkommt, ist nicht grundsätzlich unberechtigt. Full Nodes müssen sämtliche Blöcke herunterladen und validieren. Das UTXO-Set benötigt schnellen Speicher. Blockspace ist knapp, und umfangreiche Inscriptions können mit finanziellen Transaktionen um diesen Blockspace konkurrieren. Doch BIP-110 geht weit über lokale Spamfilter oder eine Debatte über sinnvolle Mempool-Policy hinaus. Der Vorschlag verändert die Regeln, nach denen Nodes entscheiden, welche Blöcke überhaupt zu Bitcoin gehören. Noch problematischer ist außerdem der geplante Aktivierungsmechanismus. Obwohl das öffentlich sichtbare Miner-Signaling weit von der vorgesehenen Schwelle entfernt ist, sollen BIP-110-Nodes ab Block 961.632 jeden Block ablehnen, der nicht das vorgeschriebene Signal enthält. Nach dem aktuellen Dashboard-Stand vom 30. Juli 2026 wurden in der laufenden Periode erst 10 signalisierende Blöcke gefunden – in der letzten vollständigen Periode waren es nur 26. Für eine freiwillige Aktivierung wären allerdings 1.109 signalisierende Blöcke erforderlich. BIP-110 soll, nach erfolgreicher Aktivierung, bestimmte Möglichkeiten zur Speicherung größerer Datenmengen in Bitcoin-Transaktionen für die nächsten 52.416 Blöcke, also ungefähr ein Jahr lang, einschränken. Und gleich vorab, weil es oft missverstanden wird: Eine BIP-Nummer bedeutet dabei weder, dass der Vorschlag von Bitcoin Core unterstützt wird, noch dass er einen breiten Konsens besitzt. Sie zeigt lediglich, dass der Vorschlag formal beschrieben und in das sogenannte BIP-Repository aufgenommen wurde. BIP-110 verfolgt ausdrücklich das Ziel, Bitcoin stärker auf seine Funktion als Geld- und Zahlungssystem zu begrenzen. Anwendungen, die Bitcoin als allgemeinen Datenspeicher verwenden, sollen erschwert werden. Dafür führt der Vorschlag sieben zusätzliche Konsensregeln ein. Unter anderem sollen: neue Output-Skripte grundsätzlich auf 34 Byte begrenzt werden, bestimmte Datenfelder in Skripten und Witness-Elementen maximal 256 Byte groß sein, bislang undefinierte Witness- und Tapleaf-Versionen nicht verwendet werden dürfen, der Taproot-Annex verboten werden, Taproot-Control-Blocks auf 257 Byte begrenzt werden, OP_SUCCESS sowie ausgeführte OP_IF- und OP_NOTIF-Befehle in Tapscripts verboten werden. Damit richtet sich BIP-110 zwar vor allem gegen heute verbreitete Inscriptions-Techniken, ist aber kein gezieltes „Ordinals-Verbot“. Die Regeln greifen allgemein in Script, Witness, Taproot und verschiedene vorgesehene Upgrade-Mechanismen ein. Damit können allerdings auch Anwendungen betroffen sein, die nichts mit Ordinals oder NFTs zu tun haben. Das ist entsprechend problematisch, weil es bei Bitcoin ja keine zentrale Liste sämtlicher verwendeter Skripte und Vertragskonstruktionen gibt. Nicht jede Anwendung ist öffentlich dokumentiert. Unternehmen, Entwickler und Privatpersonen können eigene Skripte, Taproot-Bäume oder vorab signierte Transaktionen einsetzen, ohne dies öffentlich anzukündigen. Die BIP-110-Webseite behauptet zwar, alle bekannten monetären Anwendungsfälle blieben vollständig funktionsfähig. Diese Formulierung enthält jedoch bereits die entscheidende Einschränkung: bekannt. Für eine Konsensänderung reicht es nicht aus, dass den Autoren keine Probleme bekannt sind. Entscheidend ist, ob legitime Nutzer tatsächlich nicht geschädigt werden können, und genau das lässt sich bei BIP-110 eben nicht garantieren. Um bestehende Nutzer zu schützen, enthält BIP-110 allerdings immerhin eine sogenannte „Grandfathering-Regel“. UTXOs, die bereits vor Aktivierung der eigentlichen Datenregeln bestätigt wurden, dürfen weiterhin nach den bisherigen Regeln ausgegeben werden. Wer heute gewöhnliche Bitcoin auf einer klassischen SegWit- oder Taproot-Adresse hält, sollte sie deshalb grundsätzlich auch auf einer möglichen BIP-110-Kette bewegen können. Die neuen Einschränkungen betreffen vor allem Outputs, die nach der Aktivierung entstehen. Das reduziert das Risiko erheblich, löst es aber nicht vollständig. Hinzu kommt, dass BIP-110 Datenspeicherung ohnehin nicht grundsätzlich verhindert. Daten könnten weiterhin etwa auf viele kleinere Elemente oder mehrere Transaktionen verteilt oder als scheinbar finanzielle Daten codiert werden. Der Vorschlag würde also lediglich bestimmte Methoden etwas komplizierter und teurer machen. BIP-110 ist deshalb keine rein technische Reparatur, sondern eine grundsätzliche Entscheidung darüber, wie Bitcoin verwendet werden soll. Nach dem Motto: „Soll Bitcoin lediglich prüfen, ob eine Transaktion nach neutralen Regeln gültig ist?“ Oder: „Sollen die Konsensregeln zusätzlich bestimmte Verwendungszwecke des Blockspaces verhindern?“ Gerade bei einer Änderung, die gültige Transaktionen verbietet und bei Uneinigkeit zu einer Kettenspaltung führen kann, ist das äußerst riskant und, offen gesagt, sogar ziemlich dumm. Die niedrige Schwelle ist von den verantwortlichen BIP-110-Entwicklern nämlich weniger als Sicherheitsmechanismus zur sauberen Koordination gewählt worden, sondern mehr als der Versuch, die Aktivierung trotz fehlender breiter Unterstützung zu erleichtern. Wird die 55-%-Schwelle erreicht, gilt BIP-110 zunächst als fest eingeplant. Nach einer weiteren Periode würden die neuen Regeln aktiv. Allerdings zeigt Miner-Signaling ohnehin keinen allgemeinen Bitcoin-Konsens. Es sagt nichts Verlässliches darüber aus, ob Börsen, Wallet-Anbieter, Node-Betreiber, Unternehmen oder Nutzer die Änderung unterstützen. Ein Miner kann das Bit zudem theoretisch sogar setzen, ohne die neuen Regeln tatsächlich zu überprüfen. Es ist zudem etwas irritierend, dass, selbst wenn diese ungewöhnlich niedrige Schwelle nicht erreicht wird, BIP-110 trotzdem aktiviert werden soll. Denn statt sich einzugestehen, dass es wirklich keinen Konsens dafür innerhalb der Akteure des Netzwerks gibt, beginnt bei Block 961.632 das verpflichtende Signaling: BIP-110-Nodes lehnen dann jeden Block ohne Bit 4 ab. Dadurch kann bereits an diesem Punkt ein Chain-Split entstehen. Spätestens bei Block 963.648 soll BIP-110 als fest aktiviert gelten. Die eigentlichen Datenbeschränkungen würden anschließend spätestens bei Block 965.664 greifen. Der Begriff „Mandatory Signaling“ klingt zunächst so, als würden die Miner tatsächlich zur Aktivierung gezwungen. Keine Sorge, ganz so einfach funktioniert das aber nicht. BIP-110-Nodes können zwar beschließen, ab Block 961.632 keine Blöcke mehr zu akzeptieren, die Bit 4 nicht setzen. Produziert die große Mehrheit der Miner aber weiterhin gewöhnliche Bitcoin-Blöcke ohne dieses Signal, laufen diese Blöcke für reguläre Bitcoin-Nodes völlig normal weiter. Die BIP-110-Nodes bleiben dann schlicht zurück. Ein sogenannter UASF (User Activated Soft Fork) kann grundsätzlich schon Druck auf Miner ausüben. Dafür braucht es aber eine glaubwürdige wirtschaftliche Mehrheit aus Börsen, Unternehmen, Wallet-Anbietern, Händlern und Nutzern, die nur die strengere Kette als Bitcoin akzeptiert. Bei BIP-110 ist eine solche Mehrheit aber bislang nun mal nicht erkennbar. Und ohne diese ist das verpflichtende Signaling damit weniger ein Druckmittel gegen die Miner, sondern vielmehr ein vorbereiteter Mechanismus zur Selbstabspaltung. Für gewöhnliche Bitcoin-Nutzer ist das größte Risiko nicht, dass ihre bisherigen Coins durch eine BIP-110-Regel plötzlich „unspendable“ werden, sondern das eigentliche Problem ist die mögliche Aufspaltung. Coins auf beiden Ketten Wer vor dem Split seine Private Keys kontrolliert, kontrolliert grundsätzlich auch die entsprechenden Coins auf beiden Ketten. Aus einem BTC können technisch also werden: ein BTC auf der regulären Bitcoin-Kette ein Coin auf der BIP-110-Kette Der zweite Coin besitzt aber nicht automatisch einen relevanten Wert. Er könnte – und bisher ist es das wahrscheinlichste Szenario – von keiner bedeutenden Börse unterstützt werden, entsprechend kaum handelbar oder wegen der extrem langsamen Blockproduktion praktisch nicht nutzbar sein. Replay-Risiken: Eine Zahlung könnte auf beiden Ketten ausgeführt werden Bei einem Chain-Split entstehen vereinfacht gesagt zwei Versionen derselben Bitcoin-Historie. Wer vor dem Split einen Bitcoin besitzt, kontrolliert danach grundsätzlich einen Coin auf beiden Ketten. Das Problem ist, dass beide Coins zunächst auf denselben Private Keys und denselben alten Transaktionen basieren. Eine neu signierte Zahlung kann deshalb unter Umständen auf beiden Ketten gültig sein. Ein Beispiel: Ein Nutzer möchte nach dem Split nur seinen BIP-110-Coin an eine Börse schicken und verkaufen. Er erstellt dafür eine Transaktion auf der BIP-110-Kette. Da diese Transaktion aber möglicherweise auch nach den Regeln der regulären Bitcoin-Kette gültig ist, kann jemand dieselbe signierte Transaktion dort erneut veröffentlichen. Dann werden nicht nur die BIP-110-Coins übertragen, sondern möglicherweise auch die echten Bitcoin auf der anderen Kette. Dieser Vorgang wird als Replay bezeichnet, weil eine Transaktion von einer Blockchain auf der anderen „wiederholt“ wird. Das Risiko besteht vor allem, weil BIP-110 keinen eingebauten allgemeinen Replay-Schutz vorsieht. Die beiden Ketten unterscheiden Transaktionen also nicht automatisch anhand einer eigenen Kennzeichnung. Was ihr als Nutzer deswegen beachten solltet: Fork-Coins nicht direkt nach einer Abspaltung hektisch bewegen keine unbekannten Anleitungen zum „Claimen“ oder Verkaufen der Coins befolgen auf eine geprüfte Methode zur Trennung der Coins warten niemals die Seed-Phrase in eine unbekannte Fork-Wallet eingeben Eine sichere Coin-Trennung würde zunächst dafür sorgen, dass sich die Coins auf beiden Ketten in unterschiedlichen Wallet-Zuständen befinden. Erst danach könnten sie unabhängig voneinander übertragen werden. Solange das nicht sauber erfolgt ist, kann eine Zahlung auf einer Kette unbeabsichtigt auch die Coins auf der anderen Kette bewegen. Vorsicht vor Fork-Wallets Nach früheren Bitcoin-Forks tauchten regelmäßig dubiose Wallets und Webseiten auf, die angeblich neue Coins freischalten konnten. Nutzer sollten niemals ihre Seed-Phrase oder Private Keys in eine unbekannte BIP-110- oder Fork-Wallet eingeben. Das Risiko, dadurch die echten Bitcoin zu verlieren, ist deutlich größer als die Chance, einen möglicherweise wertlosen Fork-Coin zu retten. Börsen können Ein- und Auszahlungen stoppen Börsen und Verwahrer könnten rund um die kritischen Blockhöhen: Einzahlungen pausieren Auszahlungen stoppen deutlich mehr Bestätigungen verlangen die BIP-110-Kette vollständig ignorieren mögliche Fork-Coins nicht gutschreiben Wer seine Bitcoin bei einem Verwahrer hält, ist somit von dessen Entscheidung abhängig. Deswegen empfiehlt es sich gegebenenfalls, die Coins vorher in Self-Custody zu nehmen und auf eine Hardware-Wallet wie die BitBox02 Nova oder eines der Geräte von Trezor zu ziehen. Lightning wird besonders kompliziert Lightning basiert auf Bitcoin-UTXOs, vorab signierten Transaktionen und blockbasierten Zeitfenstern. Bei einem Split können Funding-Outputs und Commitment-Transaktionen auf beiden Ketten existieren. Gleichzeitig laufen Timelocks auf einer extrem langsamen BIP-110-Kette real wesentlich länger. Für normale Lightning-Nutzer, die die Infrastruktur eines Anbieters nutzen, dürfte die Lage trotzdem relativ klar sein. Die meisten Anbieter werden voraussichtlich nur der wirtschaftlich dominanten Bitcoin-Kette folgen. Betreiber eigener Lightning-Nodes sollten aber die Hinweise ihrer jeweiligen Implementierung dennoch aufmerksam verfolgen. Unter dem Strich ist die grundsätzliche Kritik an umfangreicher Datenspeicherung auf Bitcoin ja grundsätzlich zu verstehen, selbst wenn man anderer Meinung ist. BIP-110 ist trotzdem der falsche Weg. Der Vorschlag versucht, eine subjektive Vorstellung legitimer Bitcoin-Nutzung in die Konsensregeln zu schreiben. Dabei werden aber nun mal auch legitime Bitcoin-Funktionen eingeschränkt und auch die Datenspeicherung wird dadurch nicht verhindert. Sie wird lediglich komplizierter, fragmentierter und möglicherweise noch schwerer erkennbar. Noch problematischer ist die Aktivierung. Bereits die Schwelle von 55 % ist für einen umstrittenen Soft Fork ungewöhnlich niedrig. Doch selbst diese Schwelle wird mit hoher Wahrscheinlichkeit deutlich verfehlt. Anstatt den Vorschlag bei fehlender Unterstützung scheitern zu lassen, sollen BIP-110-Nodes reguläre Bitcoin-Blöcke ablehnen und sich damit potenziell von der dominanten Kette abspalten. Gleichzeitig behaupten führende Befürworter weiterhin, es gebe bereits Konsens und keine vernünftigen Einwände, obwohl alle sichtbaren Daten eine andere Sprache sprechen. Zudem wurde ein reproduzierbarer Fehler in einem naheliegenden Upgrade-Pfad dokumentiert und zwei vermeintlich identische BIP-110-Nodes können dadurch unterschiedliche Blockchain-Historien akzeptieren. Das alles passt kaum zu der Erzählung eines ausgereiften und breit getragenen Vorhabens. Bitcoin-Konsens entsteht nicht durch Tweets, Marketing oder die oft genug wiederholte Behauptung, er sei bereits vorhanden. Er entsteht, wenn sich unabhängige Nutzer, Miner, Entwickler und wirtschaftliche Akteure freiwillig auf gemeinsame Regeln einigen. Genau dies ist bei BIP-110 aber eben nicht erkennbar. Normale Nutzer müssen deshalb nicht in Panik geraten. Sie sollten den möglichen Fork-Punkt aber aufmerksam beobachten, bei größeren Transaktionen vorsichtig sein und vor allem keine Seeds in dubiose Fork-Software eingeben. Eine sachliche Debatte über Blockspace und Datenspeicherung zu führen, ist natürlich sinnvoll. Was Bitcoin aber nicht braucht, ist eine hastig konstruierte Konsensänderung, die bei kaum sichtbarer Unterstützung und mit einem problematischen Aktivierungsclient erzwungen werden soll. Und noch weniger braucht es eine kleine Gruppe von Personen, die versucht, allen anderen ihre eigene, viel zu kurz gedachte Meinung aufzuzwingen. Von daher, kann man dem möglichen Fork relativ entspannt entgegenschauen, auch wenn die Hoffnung gering ist, dass danach zeitnah wieder etwas mehr Ruhe in die hitzige Debatte einkehrt.