Die 21 wichtigsten Fragen zur OP_Return-Debatte

OP_RETURN ist ein spezieller Befehl im sogenannten „Bitcoin Script“ – das ist die Programmiersprache, mit der Transaktionen beschrieben werden. Mit OP_RETURN kann man kleine Datenstücke in eine Transaktion einfügen. Diese Daten sind nicht dafür gedacht, dass man sie später wieder ausgibt, sondern ausschließlich, um sie dauerhaft in der Blockchain zu speichern.

Warum wurde das eingeführt? In den frühen Jahren des Netzwerks haben manche Nutzer versucht, Daten auf eine andere Weise in Bitcoin zu speichern: Sie haben diese in scheinbar gültige Bitcoin-Adressen gesteckt, die in Wahrheit keinen Schlüssel hatten. Das Problem: Solche „Fake-Adressen“ landeten in der UTXO-Datenbank, also der Sammlung aller ungenutzten Bitcoin-Ausgaben, die jeder Bitcoin-Knotenpunkt (Node) dauerhaft im Speicher behalten muss. Diese nutzlosen Daten blieben dort für immer liegen und blähten die Datenbank somit auf.

Mit Bitcoin Core 0.9 (2014) wurde deshalb OP_RETURN eingeführt: Damit können Nutzer zwar weiterhin kleine Daten in der Blockchain verankern, aber auf eine saubere Art, die die UTXO-Datenbank nicht belastet. Es war also ein Kompromiss – eine kontrollierte Möglichkeit für kleine Notizen, ohne dass Bitcoin durch andere Tricks dauerhaft „zugemüllt“ wird.

Ein Bitcoin-Client ist eine Software, mit der man eine sogenannte Node (Knotenpunkt) betreiben kann. Der Hauptzweck von (Full) Nodes ist, für sich selbst eine akkurate Kopie der Bitcoin-Bestände zu haben, die man nach den selbstgewählten Bitcoin-Regeln geprüft hat. Und obwohl der Nutzen von privaten, zu Hause betriebenen Nodes für das Gesamtnetzwerk eher marginal ist, hilft jeder Knotenpunkt dennoch ein wenig mit, das Bitcoin-System am Laufen zu halten.

Der wichtigste und am meisten genutzte Client heißt Bitcoin Core. Er wird von einer relativ großen Entwicklergemeinschaft gepflegt und gilt als die Standardsoftware für Bitcoin.

Daneben gibt es andere Clients, zum Beispiel Bitcoin Knots. Knots basiert zwar grundlegend auf Bitcoin Core, hat aber andere Voreinstellungen und verfolgt eine andere „Politik“. Einer der größten Unterschiede liegt aktuell darin, wie streng beide Programme mit OP_RETURN-Daten umgehen.

Im Rahmen von Bitcoin gibt es zwei Arten von Regeln:

• Konsensus-Regeln: Das sind die festen Grundregeln, an die sich alle Netzwerkteilnehmer halten müssen. Sie bestimmen zum Beispiel, dass es nie mehr als knapp 21 Millionen Bitcoin geben wird oder wie ein gültiger Block aussehen muss. Wenn eine Node Transaktionen beziehungsweise Blöcke akzeptiert, die gegen diese Regeln verstoßen, wird sie sich vom „echten“ Bitcoin-Netzwerk abspalten.
• Policy-Regeln: Das sind zusätzliche Einstellungen einzelner Nodes. Sie betreffen nicht die Gültigkeit, sondern nur, welche Transaktionen eine Node in ihren Speicher (den Mempool) aufnimmt und an andere weiterleitet.

Das bedeutet: Eine Transaktion kann nach den Konsensus-Regeln völlig gültig sein, aber von manchen Nodes trotzdem abgelehnt werden, weil deren Policy strenger ist.

Mit der Veröffentlichung von Bitcoin Core v30 wird das bisherige Standard-Limit von den genannten 83 Bytes für OP_RETURN-Daten auf 100.000 Bytes angehoben und damit faktisch entfernt, weil es nur noch durch die maximale Standardgröße für das Blockgewicht respektive die Blockgröße limitiert ist. Das heißt: Core gibt nicht mehr zentral vor, wie groß OP_RETURN-Daten maximal sein dürfen. Stattdessen können Node-Betreiber in ihrer Konfiguration selbst entscheiden, ob sie ein Limit setzen – und wenn ja, wie hoch.

Wichtig dabei: Die Konsensus-Regeln haben sich nicht verändert. Schon früher waren eben auch größere OP_RETURN-Transaktionen gültig. Der Unterschied ist nur, dass sie durch das alte Limit von vielen Nodes standardmäßig nicht weitergeleitet wurden. Durch die Aufhebung dieses Limits werden größere OP_RETURN-Transaktionen nun einfacher durch das Netzwerk verbreitet.

Die Folgen sind allerdings umstritten: Befürworter sehen darin einen logischen Schritt, weil Policy-Regeln ohnehin keinen dauerhaften Schutz vor Spam bieten. Kritiker warnen aber, dass damit mehr „schädliche“ Daten in die Blockchain gelangen könnten.

Die Entwickler von Bitcoin Core sind zu dem Entschluss gekommen, dass ein festes Standard-Limit für OP_RETURN keinen echten Schutz vor „Spam“ bietet. Wer viele Daten in die Blockchain schreiben will, kann das auch über andere Wege tun – zum Beispiel über sogenannte Inscriptions beziehungsweise Witness-Daten, die sogar günstiger sind. Das 80-Byte-Limit im OP_RETURN war also ohnehin eine künstliche Hürde, die leicht umgangen werden konnte.

Statt Sicherheit zu schaffen, hatte das Limit eher Nachteile: Es konnte dazu führen, dass Nodes unterschiedliche Transaktionen im Speicher hatten, weil manche strenger filterten als andere. Das erschwert die Vorhersage, wie hoch die aktuelle Gebührenrate ist, welche Transaktionen wirklich im nächsten Block landen, und schwächt die Effizienz des Netzwerks.

Die Aufhebung kam jetzt mit Version 30, weil die Entwickler seit Längerem diskutieren, alte und wenig nützliche Policy-Regeln zu vereinfachen. Ziel ist es, den Code schlanker zu halten, Widersprüche zu vermeiden und Node-Betreibern mehr Eigenverantwortung zu geben. Core möchte damit auch klarstellen: Spam wird nicht durch willkürliche Limits verhindert, sondern durch das Gebührenmodell von Bitcoin selbst.

Für die meisten Node-Betreiber ändert sich erst einmal nichts. Wer Bitcoin Core v30 installiert, hat automatisch die neue Einstellung: Es gibt kein fest eingebautes Limit mehr für OP_RETURN-Daten (abgesehen vom maximalen Standardgewicht). Transaktionen mit größeren OP_RETURN-Feldern werden also weitergeleitet, solange sie die allgemeinen Regeln (Konsensus) erfüllen.

Wer weiterhin ein Limit möchte, kann das aber selbst einstellen. Über die beiden erwähnten Optionen datacarrier und datacarriersize lässt sich in der Konfigurationsdatei festlegen, ob OP_RETURN erlaubt ist und wie groß es maximal sein darf. Das heißt: Die Verantwortung liegt jetzt stärker bei den einzelnen Betreibern.

Wichtig ist aber auch: Niemand ist gezwungen, die Änderung zu übernehmen. Wer die neue Einstellung ablehnt, kann einfach eine ältere Version wie Bitcoin Core v29 weiterlaufen lassen oder zu einem alternativen Client wie Bitcoin Knots wechseln, der nach wie vor strengere Regeln verwendet.

Die aktuelle Debatte um OP_RETURN ist gewissermaßen auch ein Stellvertreterstreit über zwei Grundhaltungen in der Bitcoin-Welt.

Die meisten Leute in der Bitcoin Core-Fraktion vertreten den Standpunkt, dass Bitcoin so neutral wie möglich sein soll. Nach dieser Sichtweise ist jede Transaktion legitim, solange sie die Regeln einhält und die entsprechenden Gebühren bezahlt. Ob jemand Bitcoin nur als Geld überweist oder Daten in eine Transaktion schreibt, soll keine Rolle spielen. Die Core-Entwickler betonen stets: Der Markt – also die Gebühren – ist das wirksamste Mittel gegen Spam. Wer viele Daten in die Blockchain legen will, muss entsprechend dafür bezahlen. Wenn „dem Markt“ monetäre Transaktionen wichtiger sind als nutzloser Spam (was langfristig sehr wahrscheinlich auch so sein wird), dann wird dieser über kurz oder lang ohnehin ausgepreist.

Die Knots-Fraktion sieht das anders. Für sie ist Bitcoin in erster Linie ein Tauschmittel und sollte auch so behandelt werden. Sie argumentiert, dass Transaktionen, die hauptsächlich Daten enthalten, das eigentliche Ziel von Bitcoin verwässern und Ressourcen verbrauchen, die besser für die Anwendung als Geld genutzt werden sollten. Deshalb setzt Knots strengere Regeln und Filter ein, um das Einfügen von Daten zu erschweren und Transaktionen zu zensieren.

Wenn man es herunterbrechen möchte, könnte man sagen: Core setzt auf Neutralität und Gebühren als Regulator, während Knots aktiv eingreifen will, um Bitcoin stärker auf die Geldfunktion zu beschränken. Genau an dieser Trennlinie entzündet sich die aktuelle Diskussion um OP_RETURN.

Kritiker – vor allem aus dem Knots-Lager – sehen in der Aufhebung des Limits die Gefahr, dass Bitcoin von seiner eigentlichen Aufgabe als Geld abgelenkt wird. Ihrer Ansicht nach sollte möglichst jeder Transaktionsplatz in einem Block dem Geldtransfer dienen. Wenn stattdessen immer mehr Daten gespeichert werden, könnte der Eindruck entstehen, dass Bitcoin nicht in erster Linie ein Geldnetzwerk ist, sondern ein „Datenspeicher für alles“.

Dazu kommen praktische Risiken: Angreifer oder Datenprojekte könnten große Mengen nutzloser Informationen über OP_RETURN in die Blockchain schreiben. „Das würde die Blockchain schneller wachsen lassen, Nodes stärker belasten und die Kosten für den Betrieb einer eigenen Node erhöhen“, erklären manche Knots-Verfechter. Diese Befürchtung beruht in den meisten Fällen jedoch auf Unwissenheit beziehungsweise einem Missverständnis. Denn während zwar das Limit für OP_Return angehoben respektive aufgehoben werden soll, würde die Grenze für die Blockgröße natürlich weiterhin bestehen bleiben. Ein deutlich schnelleres Wachstum im Vergleich zu vorher ist deshalb gar nicht möglich.

Viele Experten sind überzeugt, dass sich Spam in einem offenen, dezentralen System wie Bitcoin ohnehin nicht dauerhaft mit Filtern verhindern lässt. Filter-Regeln funktionieren immer nur so lange, bis Angreifer sie umgehen. Danach müssen neue Regeln aufgestellt werden – und das Spiel beginnt von vorn. Auf Dauer würde das bedeuten, dass es eine zentrale Instanz geben müsste, die ständig vorgibt, was als Spam gilt und was nicht. Genau das aber widerspricht dem dezentralen Charakter von Bitcoin.

Die Befürworter von Filtern argumentieren zwar, dass sie zumindest die Hürde erhöhen und damit verhindern könnten, dass Bitcoin leicht mit großen oder unnützen Daten überflutet wird. Doch Simulationen zeigen, dass Filter in der Praxis kaum wirksam sind. Selbst wenn 90 % der Nodes Filter einsetzen, erreichen fast alle Transaktionen weiterhin die restlichen „toleranten“ Nodes – und damit auch die Miner. Da Miner letztlich entscheiden, was in Blöcke aufgenommen wird, landen diese Transaktionen am Ende trotzdem in der Blockchain.

Filter-Regeln erzeugen also vor allem zusätzliche Komplexität im Netzwerk, verhindern aber keinen Spam. Für die Core-Sichtweise gilt deshalb: Der einzig wirklich dezentrale und verlässliche Spam-Schutz sind die Gebühren. Wer viele oder große Transaktionen in die Blockchain schreiben will, muss dafür bezahlen. Damit reguliert sich der Missbrauch von selbst, ohne dass jemand zentral eingreifen muss.

Zum anderen liegt die Entscheidung darüber, welche Transaktionen in die Blockchain aufgenommen werden, letztlich immer bei den Minern. Eine OP_RETURN-Transaktion, die 500 oder 5.000 Bytes groß ist, ist nach den Konsensus-Regeln gültig – und wenn ein Miner dafür Gebühren erhält, wird er sie in seinen Block aufnehmen. Es bringt also wenig, wenn ein Großteil der Nodes diese Transaktionen unterwegs aussortiert. Sie landen am Ende trotzdem in der Blockchain, nur über Umwege.

Genau das birgt Risiken. Wenn viele Nodes bestimmte Transaktionen blockieren, entsteht ein Anreiz, sie direkt an große Miner zu schicken. Daraus könnten parallele, halb-zentrale „Transaktionsnetzwerke“ entstehen, die kleine Miner ausschließen und das gesamte Bitcoin-Ökosystem anfälliger für Zensur machen. Ein scheinbar harmloser Filter im Relay-Verhalten kann so im schlimmsten Fall zu Mining-Zentralisierung beitragen – einem echten Risiko für die Dezentralität von Bitcoin.

Für die einzelnen Node-Betreiber bringt ein Limit ebenfalls keinen Vorteil. Auch wenn ihre Node bestimmte Transaktionen nicht weiterleitet, muss sie sie spätestens dann verarbeiten und speichern, wenn ein Miner sie in einem gültigen Block bestätigt hat. Der Speicher- oder Sicherheitsaufwand sinkt also nicht, sondern der Node-Betreiber verliert lediglich den Überblick, welche Transaktionen wahrscheinlich bald in Blöcken auftauchen.

Deshalb haben die Core-Entwickler entschieden, das Limit aufzuheben.

Ja, genau das ist ein zentrales Problem von Filtern. Sie unterscheiden nicht zwischen „Spam“ und legitimen Anwendungsfällen, sondern blockieren stumpf alle Transaktionen, die ein bestimmtes Muster erfüllen. Dadurch kann es passieren, dass auch völlig unproblematische Transaktionen aussortiert werden.

Ein Beispiel ist der Umgang von Bitcoin Knots mit Transaktionen, die eine sogenannte „Locktime“ von 21 enthalten. Ursprünglich wurde dieser Wert einmal von einem obskuren Altcoin-Protokoll namens „CAT-21“ genutzt. Knots filtert bis heute standardmäßig (aber optional) alle Transaktionen heraus, die genau diese Locktime haben, obwohl das ursprüngliche Projekt längst tot ist.

Genau darin sehen viele Core-Befürworter die Gefahr: Filter-Regeln können willkürlich wirken, sind oft schlecht dokumentiert und beruhen manchmal nur auf der Meinung oder Einschätzung einzelner Entwickler. Im Fall von Knots liegt die Verantwortung für diese Filter quasi ausschließlich bei Luke Dashjr. Kritiker sprechen deshalb wohl zurecht davon, dass Nodes mit solchen Regeln im Grunde einseitig „zensieren“. Wenn eine zentrale Instanz bestimmt, welche Transaktionen „erwünscht“ sind und welche nicht, ja, dann ist das im Kern nichts anderes als Zensur. Und dies sollte in einem freien System wie Bitcoin tunlichst vermieden werden.

Die Knots-Fraktion hält dagegen, dass solche Filter ein gewisses Signal senden sollen: „Wir verstehen Bitcoin als Geld, nicht als Datenspeicher.“ Für sie geht es weniger um praktische Wirksamkeit, sondern um eine klare Abgrenzung und ein Stück „plausible deniability“, falls jemals rechtlicher Druck entstehen sollte.

OP_RETURN ist, wie bereits erwähnt, nicht die einzige Möglichkeit, Daten in Bitcoin zu speichern. Es ist nur eine der ältesten und ursprünglich am klarsten dafür vorgesehenen Varianten. Schon seit Jahren gibt es andere Wege, Daten in Transaktionen zu „verstecken“.

Die wichtigste Alternative sind sogenannte Witness-Daten, die mit dem SegWit-Update 2017 eingeführt wurden. Witness ist der Teil einer Transaktion, der kryptografische Signaturen enthält. Da hier Platz flexibel nutzbar ist, haben Entwickler schnell erkannt, dass sich dort auch beliebige Daten unterbringen lassen – zum Beispiel die Bilder und Dateien, die bei Ordinals und Inscriptions seit 2023 für große Aufmerksamkeit gesorgt haben.

Für „Spammer“ oder, nennen wir sie „kreative Nutzer“, ist der Witness-Teil oft attraktiver als OP_RETURN – und zwar aus zwei Gründen:

1. Kosten: Daten im Witness-Bereich werden im Blockgewicht vergünstigt behandelt und zählen nur ¼ des eigentlichen Gewichts. Das bedeutet: Wer Daten dort speichert, zahlt im Verhältnis weniger Gebühren als bei OP_RETURN und verdrängt auch weniger „reguläre“ Transaktionen.
2. Flexibilität: Während OP_RETURN-Outputs klar erkennbar sind und im Prinzip auch gefiltert werden können, gibt es quasi unendlich viele andere Möglichkeiten, Daten auf Bitcoin zu bringen. Diese Daten lassen sich auf eine Weise speichern, die schlechter zu identifizieren und im Zweifel auch deutlich schwieriger zu entfernen ist.

Genau deshalb argumentieren viele Core-Entwickler eben auch, dass ein Limit bei OP_RETURN ohnehin kein wirksamer Schutz ist. Selbst wenn man dort restriktiv bleibt, werden Daten einfach in Witness-Daten gepackt und das sogar zu günstigeren Konditionen. OP_RETURN ist also längst nicht mehr der Hauptkanal für Daten auf der Bitcoin-Blockchain.

Im Bitcoin-System ist Blockplatz begrenzt. Etwa alle 10 Minuten kann nur ein Block mit maximal rund 4 Megabyte Blockgewicht erzeugt werden. Wer diesen knappen Platz nutzen will – egal ob für eine Zahlung oder für Daten –, muss dafür Gebühren bieten. Die Miner sortieren ihren Mempool in der Regel nach der „Fee Rate“ (Gebühren pro Byte). Nur die Transaktionen mit den höchsten Gebühren schaffen es in den Block.

Das bedeutet: Ob große Datenmengen tatsächlich in Blöcken landen, entscheidet allein der Marktmechanismus. Wenn jemand bereit ist, für eine große OP_RETURN- oder Witness-Transaktion hohe Gebühren zu bezahlen, hat er die gleiche Chance, in einen Block aufgenommen zu werden, wie jemand, der eine einfache Zahlung tätigt. Ist er nicht bereit, diesen Preis zu zahlen, wird seine Transaktion einfach verdrängt.

Das Gebührenmodell ist somit der einzige Spam-Schutz, der dezentral, fair und dauerhaft funktioniert. Jeder Versuch, bestimmte Transaktionen zusätzlich durch Filter-Regeln zu blockieren, wäre entweder wirkungslos (weil Miner sie eben trotzdem aufnehmen können) oder zentralistisch (weil dann eine Instanz entscheidet, was „Spam“ ist).

Ein weiterer Punkt ist: Je knapper der Blockplatz und je höher die Gebühren, desto unattraktiver wird es automatisch, große Datenmengen in Bitcoin zu speichern. Schon heute zeigt sich das bei Ordinals und Inscriptions. In Zeiten hoher Gebühren brechen die Daten-Transaktionen stark ein, weil sie schlicht zu teuer werden.

Für die Core-Fraktion ist daher klar: Der Markt reguliert sich selbst. Spam existiert nur so lange, wie jemand bereit ist, dafür zu zahlen, und dieser Mechanismus stärkt zugleich die langfristige Sicherheit von Bitcoin, weil die Gebühren für Miner bekanntermaßen eine immer größere Rolle spielen, wenn die Blocksubvention – also die Belohnung durch neu geschaffene BTC – weiter sinkt.

Die Aufhebung des 80-Byte-Limits für OP_RETURN verändert den Gebührenmarkt wahrscheinlich nicht spürbar, sondern wirkt vor allem als Verschiebung.

Denn wie erwähnt spielt OP_RETURN beim „Datenboom“ auf Bitcoin ohnehin nur eine Nebenrolle.

Dazu kommt: In der Praxis gibt es ohnehin extrem wenige OP_RETURN-Transaktionen über 80 Bytes. Eine aktuelle Analyse zeigt, dass im August 2025 gerade einmal 0,007 % aller OP_RETURN-Ausgaben größer als 80 Bytes waren. Mit anderen Worten: Der Markt hat das Limit praktisch von selbst respektiert. Nicht, weil es technisch unmöglich war, sondern weil es für die meisten Anwendungsfälle schlicht keinen Sinn machte, größere Daten über OP_RETURN einzuschreiben.

Das bedeutet, ob OP_RETURN-Transaktionen nun 80 Bytes oder 8.000 Bytes groß sein dürfen, ändert am ökonomischen Prinzip voraussichtlich wenig. Wenn die Nachfrage nach Daten hoch ist, wird sie ohnehin über Witness laufen. Wenn die Nachfrage gering ist, spielt es keine Rolle, ob OP_RETURN offen ist oder nicht.

Was sich ändert, ist eher das Signal: Core macht mit der Entfernung des Limits klar, dass der Gebührenmarkt die einzige neutrale Regulierung ist.

Die Diskussion um OP_RETURN wird leider nicht nur nüchtern und technisch, sondern hoch emotional geführt. Beide Seiten werfen sich Dinge vor, die weit über den eigentlichen Code oder die Funktionsweise von Bitcoin hinausgehen.

Kritiker der Änderung, allen voran Knots-Maintainer Luke Dashjr und seine Anhänger, werfen den Core-Entwicklern vor, sie würden die Risiken kleinreden oder sogar bewusst die Unwahrheit sagen. In ihrer Wahrnehmung „lügt“ das Core-Team, wenn es behauptet, das Limit habe ohnehin keine Schutzwirkung gehabt. Für sie geht es um Glaubwürdigkeit: Wer das Limit aufhebt, signalisiert nach außen, dass Bitcoin ein Daten-Relay ist, und nimmt damit auch die Gefahr in Kauf, dass illegale Inhalte eingeschrieben werden. Manche sprechen sogar davon, dass Core damit eine „Komplizenschaft“ mit Spam und Missbrauch eingehe.

Umgekehrt unterstellen Befürworter der Änderung den Knots-Anhängern eine Form von Zensurmentalität. Sie werfen Luke vor, willkürliche Filter einzubauen – wie etwa das Blockieren bestimmter Transaktionen mit Locktime 21, ohne klare Begründung oder Diskussion. Aus ihrer Sicht ist das kein verantwortungsvoller Umgang mit Bitcoin, sondern eine Art „Astrologie im Code“, die allein auf Lukes Meinung basiert. Deshalb lautet der Vorwurf: Knots sei kein seriöses Projekt, sondern ein Ein-Mann-Experiment, das die Community mit überzogenen Schreckensszenarien – Stichwort Kinderpornografie – emotionalisiert.

Diese wechselseitigen Anschuldigungen haben die Debatte schärfer gemacht als viele frühere technische Streitpunkte. Es geht nicht mehr nur um Codezeilen, sondern um Grundsatzfragen, Reputation und persönliche Glaubwürdigkeit. Entsprechend wird in den Diskussionen nicht selten mit starken Worten wie „Lügen“, „Zensur“ oder „Clownshow“ gearbeitet, was die Fronten unnötigerweise verhärtet und die Möglichkeit einer nüchternen Debatte weiter erschwert.

Dieser plötzliche Anstieg hat jedoch einige Skepsis ausgelöst. Mehrere Experten weisen darauf hin, dass es sich dabei wahrscheinlich nicht um einen echten Zuwachs handelt, sondern um eine Sybil-Attacke, also das künstliche Hochziehen tausender Fake-Nodes, um den Eindruck einer stärkeren Verbreitung zu erwecken. Bestätigt wird dieser Verdacht durch Tools wie asmap, die solche Angriffe filtern und den Anteil von Knots bei gerade einmal etwa 2 bis 3 % verorten.

Die Dunkelziffer liegt aber wohl eher bei circa 10 % – unter anderem, weil asmap wohl zu viel herausfiltert. Kurz nach dem sprunghaften Anstieg verschwanden aber, wie zuvor erwähnt, viele der angeblichen Knots-Nodes wieder, was die Manipulationsvermutung definitiv weiter stützt.

In der öffentlichen Wahrnehmung zeigt sich also ein gemischtes Bild: Während die technische Realität klar für Core spricht, versuchen Knots-Unterstützer, durch Node-Zahlen und lautstarke Kommunikation den Eindruck einer größeren Bewegung zu erzeugen.

Dennoch muss man festhalten, dass Knots im Zuge des Disputs wohl auch ohne die Fake-Nodes einen massiven Anstieg verzeichnen konnte.

Die Möglichkeit eines Forks schwebt schon ein wenig wie ein Schatten über der aktuellen Debatte. Historisch sind Forks in Bitcoin zwar sehr selten, aber auch damals 2017 bei der Abspaltung von „Bitcoin Cash“ mit großen Spannungen verbunden gewesen.

Auch in der jetzigen Auseinandersetzung tauchte das Thema auf, nachdem in geleakten Chats von Luke Dashjr Andeutungen über einen möglichen Hardfork das Thema waren. Dabei handelte es sich zwar eher um theoretische Gedankenspiele als um konkrete Pläne, doch schon diese Überlegungen zeigen, wie verhärtet die Fronten sind. Wenn ein prominenter Entwickler wie Luke überhaupt über ein solches Szenario nachdenkt, sorgt das für Unruhe – selbst wenn die Wahrscheinlichkeit gering ist, dass daraus wirklich ein Fork entsteht.

Die Kräfteverhältnisse sprechen klar gegen einen Knots-Fork. Core dominiert das Netzwerk sowohl in der Zahl der Nodes als auch in der Unterstützung durch Börsen, Wallets und Infrastrukturbetreiber. Ein Fork hätte es extrem schwer, sich wirtschaftlich durchzusetzen. Selbst viele Kritiker der Core-Entscheidung räumen ein, dass ein Knots-Bitcoin kaum Chancen hätte, mehr als eine Randerscheinung zu werden.

Dennoch bleibt ein Restrisiko. Schon die Andeutung solcher Szenarien kann leider Unsicherheit stiften.

Zahlreiche Knots-Anhänger zeichnen derweil ein düsteres Bild: Mit Core v30 beginne angeblich das Ende von Bitcoin, das Netzwerk werde zu einem „Daten-Relay“ degradiert und verliere damit seine Glaubwürdigkeit. In Foren und auf Social Media ist häufig vom „Anfang vom Ende“ die Rede.

Sachlich betrachtet spricht jedoch nichts dafür. Die Änderung betrifft nur eine Policy-Einstellung, keine Konsensus-Regel. Miner, Gebühren und Nutzerverhalten bestimmen weiterhin, welche Transaktionen in Blöcken landen – genau wie bisher.

Und die Erfahrung zeigt: Bitcoin ist extrem robust und hat schon weitaus größere technische und ideologische Konflikte überstanden, ohne Schaden zu nehmen.

Auch wenn die Debatte hitzig geführt wird und manche den Untergang an die Wand malen, in der Praxis wird sich wahrscheinlich wenig ändern. Bitcoin wird schlicht weiterlaufen wie bisher. Viel Lärm um nichts.