Der OP_RETURN Showdown: Bitcoins neuer Governance-Kampf

Bitcoin hat Forks, regulatorische Razzien und Billionen-Dollar-Ausverkäufe überlebt. Aber eine einzige Richtlinienänderung – die Anhebung eines 80-Byte-Datenlimits auf 100.000 Byte – hat den erbittertsten Governance-Showdown seit den Blocksize-Kriegen von 2017 ausgelöst. Das Schlachtfeld ist OP_RETURN, und es steht nichts Geringeres auf dem Spiel als die Frage, wofür Bitcoin eigentlich da ist.

Von 80 Byte auf 100.000: Die Änderung, die eine Community spaltete

Seit über einem Jahrzehnt setzte Bitcoin Core eine einfache Regel durch: OP_RETURN-Outputs – der Mechanismus zum Einbetten beliebiger Daten in Transaktionen – waren auf 80 Byte begrenzt. Das reichte für einen Hash, einen Zeitstempel oder eine kurze Nachricht. Es war explizit nicht genug für Bilder, Dateien oder irgendetwas, das einer Datenspeicherschicht ähnelte.

Dann kamen die Ordinals.

Als das Ordinals-Protokoll Anfang 2023 startete, bewies es, dass Entwickler ganze Bilder und NFT-ähnliche Assets direkt in die Bitcoin-Blockchain einbetten konnten, indem sie Witness-Daten ausnutzten. Das 80-Byte-Limit für OP_RETURN wirkte plötzlich veraltet – Daten flossen bereits über andere Kanäle ein, oft auf weniger effiziente Weise, die das UTXO-Set aufblähte.

Die Entwickler von Bitcoin Core standen vor einer pragmatischen Entscheidung. Im Mai 2025 schlugen sie vor, das 80-Byte-Limit für OP_RETURN in der kommenden v30-Version vollständig zu entfernen und durch einen Standardwert von 100.000 Byte zu ersetzen. Die Logik war simpel: Wenn das Einbetten von Daten ohnehin stattfand, war es besser, dies über OP_RETURN zu kanalisieren – was entfernbar (prunable) ist und das UTXO-Set nicht belastet –, anstatt es in Witness-Daten oder reine Multisig-Outputs zu zwingen, die den Speicher der Nodes dauerhaft aufblähen.

Bitcoin Core 30.0 wurde am 12. Oktober 2025 veröffentlicht. Die 80-Byte-Obergrenze war Geschichte.

Die philosophische Bruchlinie

Das technische Argument für die Änderung war fundiert. Doch die Reaktion legte einen tieferen Riss in der Bitcoin-Community offen – einer, der seit der ersten Ordinal-Inschrift auf der Chain schwelte.

Die Pragmatiker argumentierten, dass die Richtlinien die Realität widerspiegeln sollten. Miner akzeptierten bereits große Datenpakete. Das Beibehalten des 80-Byte-Limits in der Standard-Relay-Policy von Core drängte die Daten nur an schlechtere Stellen – Witness-Daten, gefälschte Multisig-Skripte –, wo sie mehr Schaden anrichteten. Durch die Erweiterung von OP_RETURN reduzierte Core das UTXO-Wachstum, anstatt Spam zu ermöglichen.

Die Puristen sahen die Änderung als Kapitulation. Luke Dashjr, einer der dienstältesten Core-Entwickler von Bitcoin, nannte den Vorschlag „völligen Wahnsinn“. Für dieses Lager ist Bitcoins Zweck der monetäre Ausgleich – zensurresistenter, dezentraler Werttransfer. Die Erweiterung von OP_RETURN war keine neutrale technische Entscheidung; es war eine Einladung, die Blockchain in eine Müllhalde für JPEGs, Memecoins und beliebige Dateien zu verwandeln, die nichts mit hartem Geld zu tun haben.

Samson Mow, CEO von JAN3 und lautstarker Bitcoin-Maximalist, schloss sich dem Widerstand an. Ebenso eine wachsende Zahl von Node-Betreibern, die die Änderung als Verrat an Bitcoins konservativem Entwicklungsethos betrachteten – dem Prinzip, dass sich das Netzwerk langsam, vorsichtig und nur bei überwältigendem Konsens ändern sollte.

Einen solchen Konsens gab es hier nicht.

Der Aufstieg von Bitcoin Knots

Die Gegenreaktion blieb nicht nur rhetorisch. Sie führte zu einer konkreten, messbaren Spaltung im Netzwerk.

Bitcoin Knots – eine alternative Full-Node-Implementierung, die von Luke Dashjr gepflegt wird – wurde zum Sammelpunkt. Während Core OP_RETURN auf 100.000 Byte erweiterte, setzte Knots ein strengeres Limit von 42 Byte durch und weigerte sich, Inschrift-Transaktionen überhaupt weiterzuleiten. Für Betreiber, die der Meinung waren, dass Bitcoins Relay-Policy nicht-monetäre Daten aktiv entmutigen sollte, bot Knots genau das, was Core verweigerte: Widerstand.

Die Zahlen erzählen die Geschichte einer Migration:

• Januar 2024: 69 Bitcoin-Knots-Nodes im Netzwerk
• April 2025: Knots-Nodes steigen in einem einzigen Monat während des Höhepunkts der OP_RETURN-Debatte um 49 %
• September 2025: Über 4.200 Knots-Nodes, was etwa 18 % des öffentlichen Netzwerks entspricht
• Anfang 2026: Knots erreicht etwa 25 % aller öffentlichen Bitcoin-Nodes – ein Sprung von 47 % in nur wenigen Tagen nach erneuten Kontroversen

Dies ist keine Randbewegung. Jeder vierte öffentliche Bitcoin-Node führt nun eine Software aus, die die Relay-Policies von Bitcoin Core explizit ablehnt. Das Netzwerk hat dieses Maß an Client-Diversität – oder Client-Uneinigkeit – seit den Kämpfen um die SegWit-Aktivierung nicht mehr erlebt.

Das rechtliche Minenfeld, über das niemand sprechen möchte

Jenseits der Philosophie hat die OP_RETURN-Erweiterung ein Problem ans Licht gebracht, für das Bitcoins Governance-Modell nie ausgelegt war: rechtliche Haftung.

Da OP_RETURN-Outputs nun bis zu 100.000 Byte an beliebigen Daten aufnehmen können, kann die Blockchain weit mehr als nur Transaktionsmetadaten speichern. Kritiker haben das Gespenst illegaler Inhalte heraufbeschworen – von urheberrechtlich geschütztem Material bis hin zu Darstellungen von sexuellem Missbrauch von Kindern –, die dauerhaft in Bitcoins unveränderlichem Ledger eingebettet werden könnten.

Für Betreiber von Archiv-Nodes schafft dies eine unmögliche Wahl. Jeder Full Node speichert eine vollständige Kopie der Blockchain. Wenn diese Blockchain Inhalte enthält, deren Besitz oder Verbreitung in einer bestimmten Gerichtsbarkeit illegal ist, befindet sich der Node-Betreiber – zumindest theoretisch – im Besitz dieser Inhalte.

Rechtsexperten stellen fest, dass kein Gericht endgültig über die Haftung von Node-Betreibern für passiv gespeicherte Blockchain-Daten entschieden hat. „Section 230“-Schutzmaßnahmen, die Internetplattformen vor der Haftung für nutzergenerierte Inhalte schützen, könnten anwendbar sein – aber ihre Anwendbarkeit auf dezentrale Node-Betreiber bleibt eine offene Frage. Die Sichtbarkeit und Zusammenhängigkeit von OP_RETURN-Daten im Vergleich zu Daten, die über Witness-Felder verstreut sind, könnte das rechtliche Risiko erhöhen.

Die praktische Implikation ist beängstigend: Die Anhebung des OP_RETURN-Limits könnte datenschutzbewusste oder rechtlich vorsichtige Node-Betreiber dazu zwingen, ihre Nodes abzuschalten, anstatt eine strafrechtliche Haftung für Inhalte zu riskieren, die sie nie speichern wollten und die sie nicht löschen können, ohne den Betrieb vollständig einzustellen.

Eine Richtlinienänderung oder eine Konsensänderung?

Die Entwickler von Bitcoin Core haben darauf geachtet, die Erweiterung von OP_RETURN als eine Änderung auf Richtlinienebene (policy-level) und nicht auf Konsensebene (consensus-level) darzustellen. Diese Unterscheidung ist wichtig.

Konsensregeln sind das Fundament von Bitcoin — die Regeln, auf die sich jeder Node einigen muss, damit das Netzwerk funktioniert. Eine Änderung der Konsensregeln erfordert einen Fork. Richtlinienregeln hingegen bestimmen, wie einzelne Nodes ihren Mempool verwalten: welche Transaktionen sie weiterleiten, welche sie ablehnen und welche sie priorisieren. Richtlinienänderungen sind optional (opt-in). Niemand wird gezwungen, ein Upgrade durchzuführen.

Aber die Unterscheidung ist weniger eindeutig, als sie klingt. Die Standardrichtlinie (Default Policy) ist in der Praxis von enormer Bedeutung, da die überwiegende Mehrheit der Node-Betreiber Core mit Standardeinstellungen ausführt. Wenn Core seine Standardeinstellungen ändert, ändert sich das Verhalten des Netzwerks — selbst wenn keine Konsensregel angetastet wurde.

Ein Zugeständnis ergab sich aus der Debatte. Ursprünglich sollte Bitcoin Core v30 die Konfigurationsoption datacarriersize einstellen, die es Betreibern ermöglichte, OP_RETURN-Daten manuell zu begrenzen. Nach anhaltendem Widerstand der Community und der erfolgreichen Zusammenführung von PR 33453 wurde diese Einstellung auf unbestimmte Zeit verschoben. Node-Betreiber, die auf v30 upgraden, können die Weiterleitung von OP_RETURN weiterhin manuell einschränken, wenn sie dies wünschen.

Es ist ein Kompromiss, der jedoch keine der beiden Seiten zufriedenstellt. Puristen argumentieren, dass Standardeinstellungen das Verhalten prägen — die meisten Betreiber werden die Konfiguration nie anrühren. Pragmatiker entgegnen, dass die Beibehaltung der Option genau so ist, wie die Bitcoin-Governance funktionieren sollte: den Betreibern die Wahl lassen, ohne eine Ideologie durch Code aufzuzwingen.

Echos der Blockgrößen-Kriege

Für jeden, der die Blockgrößen-Kriege (Blocksize Wars) von 2015–2017 miterlebt hat, sind die Parallelen schwer zu übersehen.

Damals ging es in der Debatte darum, ob die Blockgröße von Bitcoin von 1 MB erhöht werden sollte, um mehr Transaktionen zu ermöglichen. Big Blocker argumentierten für Praktikabilität und Skalierbarkeit. Small Blocker argumentierten, dass größere Blöcke das Netzwerk zentralisieren würden, indem sie die Kosten für den Betrieb eines Full Nodes erhöhen würden. Der Konflikt führte zu Bitcoin Cash, einer Chain-Abspaltung und jahrelanger Erbitterung.

Die OP_RETURN-Debatte folgt demselben Skript:

• Pragmatismus vs. Ideologie: Core-Entwickler sagen, sie akzeptieren die Realität; Kritiker sagen, sie geben Prinzipien auf.
• Netzwerkfragmentierung: Der 25 % Node-Anteil von Knots spiegelt das frühe Wachstum von Bitcoin Unlimited und Bitcoin Classic während der Blockgrößen-Debatte wider.
• Governance durch groben Konsens (Rough Consensus): Beide Seiten behaupten, der anderen fehle es an Legitimität. Core-Entwickler verweisen auf ihren Merge-Prozess; Knots-Anhänger verweisen auf die Node-Adoption als Abstimmung.
• Rechtlicher und wirtschaftlicher Druck: Genau wie bei der Blockgrößen-Debatte Börsen, Miner und das „New York Agreement“ involviert waren, betrifft die OP_RETURN-Debatte Miner, die von datenintensiven Transaktionen profitieren, und Node-Betreiber, die die Speicherkosten tragen.

Der entscheidende Unterschied ist, dass die Blockgrößen-Kriege mit einer Chain-Abspaltung endeten. Die OP_RETURN-Debatte hat das nicht — bisher. Core und Knots bleiben konsenskompatibel; sie sind sich uneinig über die Relay-Richtlinien, nicht darüber, welche Blöcke gültig sind. Aber wenn der Anteil von Knots weiter wächst und die beiden Implementierungen weiter divergieren, wächst damit die Möglichkeit einer tieferen Spaltung.

Was als Nächstes passiert

Stand Anfang 2026 ist das Node-Netzwerk von Bitcoin ideologisch so gespalten wie seit der SegWit-Aktivierung nicht mehr. Bitcoin Core v31, das für Ende 2026 erwartet wird, soll weitere Änderungen am Peer-to-Peer- und UTXO-Management einführen, die die Lücke zu Knots vergrößern oder verkleinern könnten.

Mehrere Ergebnisse sind möglich:

1. Konvergenz: Core und Knots finden einen Mittelweg — vielleicht einen konfigurierbaren Standard, der genügend Betreiber zufriedenstellt, um eine weitere Fragmentierung zu verhindern. Das unbefristete Festhalten an der Option datacarriersize deutet darauf hin, dass die Core-Entwickler sich der politischen Kosten bewusst sind, die das Entfernen der Wahlfreiheit für Betreiber mit sich bringt.

2. Stabile Bifurkation: Das Netzwerk pendelt sich in einem Zwei-Client-Gleichgewicht ein, ähnlich wie der Geth/Prysm-Split bei Ethereum. Core und Knots koexistieren, wobei jeder eine andere philosophische Wählerschaft bedient, ohne dass es zu einer Chain-Abspaltung kommt. Dies ist wohl das gesündeste Ergebnis für die Dezentralisierung — Client-Diversität ist ein Feature, kein Bug.

3. Eskalation: Knots oder ein anderer alternativer Client führt konsens-inkompatible Änderungen ein (wie z. B. Transaktionsfilterung auf Konsensebene), was eine Chain-Abspaltung auslöst. Dies ist das Albtraumszenario, bleibt aber unwahrscheinlich, solange sich beide Implementierungen über die Blockgültigkeit einig sind.

4. Miner-Schiedsgerichtsbarkeit: Miner, die letztendlich entscheiden, welche Transaktionen in Blöcke aufgenommen werden, werden zu De-facto-Entscheidungsträgern. Wenn Miner weiterhin große OP_RETURN-Outputs unabhängig von der Relay-Richtlinie aufnehmen, wird die Debatte in der Praxis hinfällig — und die Machtdynamik verschiebt sich weiter von den Node-Betreibern hin zu den Minern.

Die tiefergehende Frage

Im OP_RETURN-Krieg geht es eigentlich nicht um Bytes. Es geht um Identität.

Bitcoin wurde als „ein elektronisches Peer-to-Peer-Cash-System“ erschaffen. Aber über 16 Jahre hinweg ist es auch zu einem Wertaufbewahrungsmittel, einer Abwicklungsschicht, einem politischen Statement und — mit Ordinals und Inscriptions — zu einer kulturellen Leinwand geworden. Nicht jeder fühlt sich mit all diesen Rollen wohl.

Das 80-Byte-Limit war eine Grenze — unvollkommen, leicht zu umgehen, aber symbolisch mächtig. Es besagte: Dies ist für Geld. Es zu entfernen, sagt etwas anderes aus. Ob dieses Etwas eine pragmatische Akzeptanz der Realität oder der Beginn einer Zielabweichung (Mission Drift) ist, hängt ganz davon ab, auf welcher Seite der Bruchlinie man steht.

Klar ist, dass Bitcoins Governance-Modell — dezentralisiert, führerlos und konsensgesteuert — einer Belastungsprobe unterzogen wird, wie sie es seit den Blockgrößen-Kriegen nicht mehr erlebt hat. Das Ergebnis wird nicht nur prägen, welche Daten Bitcoin transportiert, sondern auch, wer darüber entscheiden darf.

---

Bauen Sie auf Bitcoin oder anderen Blockchain-Netzwerken? BlockEden.xyz bietet Node-Infrastruktur der Enterprise-Klasse und API-Dienste über mehrere Chains hinweg, entwickelt für Entwickler, die einen zuverlässigen Hochleistungszugang zu Blockchain-Daten benötigen. Erkunden Sie unseren API-Marktplatz, um loszulegen.