Die OP_RETURN Kontroverse

Im Oktober 2025 hat Bitcoin Core v30 eine der kontroversesten Änderungen seit dem Block Size War von 2017 eingeführt: die Anhebung des OP_RETURN-Limits von 80 Bytes auf über 100.000 Bytes. [1] Diese Entscheidung spaltet die Community und hat zu einer massiven Verschiebung der Node-Infrastruktur geführt.

Über 21% aller öffentlichen Bitcoin-Nodes liefen inzwischen auf Bitcoin Knots — einer alternativen Client-Implementierung mit strengeren Filterrichtlinien. [2] Parallel dazu hat die Community mit BIP-110 einen Gegenentwurf aktiviert, der mit September 2026 einer Aktivierung entgegen sieht. [3]

Teil 1: Die technischen Grundlagen — Was ist OP_RETURN ?

OP_RETURN ist ein Bitcoin-Opcode, der ein Transaktions-Output als provably unspendable markiert — die darin gespeicherten Satoshis sind unwiederbringlich verloren, aber das Output darf beliebige Daten (bis zur Policy-Grenze) enthalten [1].

Warum wurde OP_RETURN 2014 eingeführt?

Vor 2014 lagerten Nutzer bereits Daten auf der Blockchain ein — nicht über OP_RETURN, sondern durch „Fake Addressen“: Sie kodierte Daten in spendbare Outputs, die niemals ausgegeben würden. Das Problem: Diese Outputs blieben im UTXO-Set erhalten, einer kritischen Datenbank, die jeder Node in RAM halten muss[1]. Das führte zur Speicher-Verschwendung.

OP_RETURN war die elegante Lösung: Ein expliziter Kanal für Daten, der das UTXO-Set nicht belastet. Gleichzeitig setzte Bitcoin Core eine Grenze: zunächst 40 Bytes (2014), später 80 Bytes (2015). Die Logik war simpel: Groß genug für legitime Use Cases (Hash, Timestamp), klein genug, um Missbrauch zu drosseln.

April 2025: Die Entdeckung des „Malincentive“

Im April 2025 identifizierten Core-Entwickler um Peter Todd ein technisches Problem: Das 80-Byte-Limit schuf einen pervertierten Anreiz [4].

Das Paradoxon: Wenn die OP_RETURN-Grenze zu klein ist, weichen Daten-Speicherer auf spendbare Outputs aus — und landen wieder im UTXO-Set. Das ist schlimmer als das 80-Byte-Limit.

Todd argumentierte: „Miners werden diese Transaktionen unabhängig von Node Policy minen, weil sie profitabel sind. Ein Limit zu setzen, incentiviert nur private Mempools, schadet kleine Miner und verschlechtert die Fee-Estimat“ [4].

Oktober 2025: Core v30 und die neuen Standards

Bitcoin Core v30 führte heimlich drei konkrete Änderungen ein und zensierte die Kommentare auf Github [1, 13, 14]:

OP_RETURN Limit-Erhöhung: Von 80 auf ~100.000 Bytes (praktisch aufgehoben, da die 100KB Transaktionsgröße das echte Limit ist)
Multiple OP_RETURN Outputs: Erstmals können Transaktionen mehrere OP_RETURN Outputs mit Daten enthalten
Deprecated Configurability: Der Parameter -datacarriersize wird als veraltet markiert und ändert seine Semantik in v30

Diese dritte Änderung ist besonders heimtückisch: Ein Node Betreiber, der in v29 -datacarriersize=83 setzte, erhielt ~92 Bytes Limit. In v30 das gleiche Setting: plötzlich 830 Bytes[5]. Das ist keine Konfiguration, sondern eine versteckte Standardänderung.

Der Knoten-Betreiber merkt nicht, dass sein Filter plötzlich um den Faktor 10x lockerer wurde.

Teil 2: Historischer Kontext — Warum fühlt sich das wie 2017 an?

Die Block Size War (2015–2017): Eine Vorahnung

Die Block Size War war im Kern ein Konflikt über Philosophie, nicht nur der Technik[6].

Big Blockers (angeführt von Bitmain, Coinbase, Roger Ver): „Bitcoin braucht größere Blöcke für Skalierbarkeit und Massenadoption. 8MB Blöcke ermöglichen Ethereum-artige Aktivität.“

Small Blockers (Bitcoin Core, konservative Knoten-Betreiber): „Größere Blöcke zentralisieren die Node-Infrastruktur, da nur wenige das speichern können. Bitcoin sollte ein Settlement Layer bleiben, nicht eine Universalplattform.“

Die Debatte endete 2017 mit SegWit (Soft Fork, kein Block Size Increase) und der gescheiterten SegWit2x Hard Fork. Bitcoin Cash entstand hingegen als Hart-Fork-Resultat[6].

Damals ging es um Blockgröße und damit um die Kernvalidierungsregeln. Heute geht es um Mempool Policy — kein Fork, aber potenziell genauso spalterisch.

Die Parallelen sind erschreckend:

Dimension	Block Size War 2017	OP_RETURN Krieg 2025
Kern-Frage	Wie groß darf ein Block sein?	Wie viel Non-Monetäre Daten sind akzeptabel?
Ideologie	Skalierbarkeit vs. Dezentralisierung	Innovation vs. Monetary Purity
Gewinner	Kompromiss (SegWit), aber spalterisch	Noch nicht geklärt
Alternative Clients	Bitcoin Unlimited, Bitcoin Classic	Bitcoin Knots
Miner-Rolle	Zentral (signaling)	Zentral (direct submission channels)

Teil 3: Die wirtschaftlichen Mechanismen — Wer profitiert, wer zahlt?

Das Spam-Phänomen und die Runes-Explosion

2024 startete Casey Rodarmor das Runes-Protokoll — ein Token-Standard, der exklusiv auf OP_RETURN basiert[1]. Im Vergleich zu Ordinals (die Taproot ausnutzen) ist Runes „explizit“: Alle Instruktionen stehen im OP_RETURN.

Resultat: OP_RETURN-Nutzung stieg >10x.

Im 2025 belegten Non-Monetäre Daten 37% des genutzten Blockspace[3]. Das sind nicht „spammy Junk-Transaktionen“ — sondern profitable Serviceleistungen:

Inscription Services: Yield Farming auf der Blockchain
Bridge Anchoring: Layer-2 Projekte verankern Merkle Roots
Data Indexing Protocols: Nostr, IPFS-Anchor-Dienste

Alle diese Services zahlen Miner-Gebühren. Für Pools wie Marathon/Slipstream ist das Revenue[2].

Die Anreizkette: Wer zahlt, wer profitiert, wer leidet?

Wer zahlt? Die Datennutzer (Inscription-Services, Rune-Trader).

Wer profitiert direkt? Miner (Gebühren) und große Pools (mit Template-Kontrolle).

Wer trägt die Kosten, ohne Gebühren zu erhalten?

Node Betreiber: Müssen >100KB Transaktionen speichern, validieren, relayed. Bandbreite, CPU, RAM — alles dauerhaft.
Normale Zahlungs-User: Mempool-Congestion treibt Gebühren hoch, auch für monetäre Transaktionen.
Small Miner: Sie nutzen Standard-Mempools. Große Pools mit privaten Templates können Daten-Transaktionen schon im Block-Template filtern — Small Miner sehen die „Spam“ erst im Mempool und müssen mitrelay[7].

Die ökonomische Asymmetrie:

Gebührenfluss: Datennutzer → Miner
Kostenfluss: Alle Node Betreiber
Kontrolle: Miner (Template-Builders, d.h. Pools)

Das ist eine negative Externalität — und genau das ist der Grund, warum BIP-110 entstanden ist.

BIP-110: Die Gegenmobilisierung mit „harter“ Deadline

Im Dezember 2025 startete die Signalisierungsperiode für BIP-110 — Reduced Data Temporary Softfork[3].

Kernziel: Limitierung auf 256 Bytes maximale zusammenhängende Daten, was Non-Monetäre „Blobs“ faktisch unterbindet.

Das Revolutionäre: BIP-110 nutzt eine unconditional activation clause.

Traditionelle Soft Forks (SegWit, Taproot) brauchten ~90% Miner Signaling. Das gab Minern de facto Veto-Power. BIP-110 ändert das[3]:

55% Signaling in einem 2016-Block-Fenster → Aktivierung nach 2 Wochen
ODER: September 2026 (Block 965.664) → Unconditional Activation, unabhängig von Signaling

Das ist nicht „Miner Governance“ — das ist User Sovereignty.

Luke-Jr. (Knots-Maintainer) baute das ein, um dem Narrativ „Core-Entscheidungen sind gegen Nutzer immun“ entgegenzuwirken[3]. Miner können Signaling beschleunigen — aber nicht verhindern.

Teil 4: Die Knots-Alternative und der Filtering-Mythos

Bitcoin Knots: Strikte Filter, oder symbolisches Theater?

Luke Dashjr’s Bitcoin Knots ist nicht ein Fork von Core, sondern eine Policy-alternative Implementation. Knots setzt auf alte Defaults[2]:

OP_RETURN Limit: ~42 Bytes (statt 100KB)
Multiple OP_RETURN Outputs: Disabled
Full-RBF: Disabled by default (vs. Core: enabled)
Consensus: 100% identisch mit Core

Die Adoption explodierte: 5% → 21% der Nodes zwischen April und Oktober 2025 liefen auf Knots. [2]

Aber funktioniert das Filter überhaupt?

Nein — unter realen Bedingungen nicht:

Miner umgehen es via Direct Submission: Marathon, Slipstream und andere Pools laufen private Mempool-Policies. Sie nehmen Daten-Transaktionen direkt von Nutzern an, ob Knots sie relayed oder nicht[2].
Non-Knots Nodes relayed trotzdem: Nur 21% der Nodes laufen Knots. Die anderen 79% (Core, Btcpay, Full-RBF) relayed die gefilterten Transaktionen weiter.
Ökonomisches Inevitability: Ein Miner, der Daten-Spam filtert, während Core-Nodes ihn relayen, verliert einfach Gebühren an einen Pool, der das nicht tut[7].

Das ist nicht Zensur vs. Freiheit — das ist Ökonomie vs. Wunschdenken.

Die unbequeme Wahrheit über Knots

Knots ist nicht ineffektiv. Es ist symbolisch optimal:

Es signalisiert klare Werte: „Bitcoin ist Geld, nicht Datenspeicher“
Es gibt Node Betreibern Kontrolle — auch wenn diese Kontrolle nicht global bindend ist
Es ist transparent und nicht-koercive (jeder kann Knots oder Core laufen)

Aber es verhindert nicht wirklich Blockchain-Spam, solange 79% der Nodes + die meisten Miner anders konfiguriert sind[2].

Das erklärt auch, warum die Attacken auf Knots-Nutzer so persönlich und nicht sachlich sind[2]: Die Gegenseite weiß, dass die Argumente verloren sind. Filter sind effektiv, wenn sie koordiniert sind. Das erfordert aber Konsenssoftforks wie BIP-110.

Teil 5: BIP-110 und die Ökonomie von Mining Pools

Template-Kontrolle als zentralisierender Hebel

Ein zentrales Argument von BIP-110-Unterstützern: Die Kontrolle über Block Templates ist der echte Machtmechanismus[3][7].

Große Mining Pools (Foundry, Slipstream, Binance Pool) bauen ihre eigenen Block Templates. Sie können Daten-Transaktionen vor dem Broadcasting filtern. BIP-110 zwingt diesen Filter auf die Consensus-Ebene — also verbindlich für alle Miner[3].

Warum Miner das fürchten:

Profitabilität-Squeeze: Mit BIP-110 können Non-Monetäre Daten nicht mehr >256 Bytes sein. Daten-Speicherung wird wieder unprofitabel.
Fee-Premium-Erosion: Heute zahlen Daten-User Premium-Gebühren, weil es knapp ist. Mit konsensuellen Limits gibt es kein Knappheits-Rent mehr.
Die „Slipstream-Problematik“: Marathon’s Slipstream nimmt Transaktionen direkt an (out-of-band), umgeht die gesamte Relay-Netzwerk. Mit BIP-110 auf der Consensus-Ebene funktioniert das nicht mehr[7].

Das ist das reale Konflikt-Zentrum — nicht „Zensur vs. Freiheit“, sondern „Wer kontrolliert Block-Space-Allokation?“

Der Kipppunkt: Dezentralisierte Template-Kontrolle

Die Ironie: Stratum v2 und DATUM (zwei Protokolle für dezentralisierte Template-Negotiation) würden Knots + Policy-Filtering unterstützen, statt zu bekämpfen[7].

Wenn Miner ihre Block-Templates via DATUM selbst bauen (statt von Pools zu nehmen), gewinnen sie Kontrolle zurück. Aber nur, wenn die Consensus-Ebene (OP_RETURN Limits) kohärent mit der Mempool-Ebene funktioniert[7].

Deshalb kombiniert BIP-110 zwei Ebenen:

Consensus: Limitierung auf max. 256 Bytes (unmöglich zu umgehen)
Mempool: Node Policies können dann lokal durchgesetzt werden, ohne „böse Miner“ fürchten zu müssen

Teil 6: Vier unbeantworteten Fragen — Und warum die Antworten zeigen, dass Core Unrecht hat

Frage 1: Welchen Vorteil hat die Aufhebung der 80-Byte OP_RETURN Filter von Core v30 für den Node-Betreiber?

Antwort: Für den einzelnen Node Betreiber: Keinen. Absolut keinen. Siehe [1][5].

Ein Node Runner will:

Geringe Bandbreite
Geringe CPU
Geringe Speicherlast
Keine illegalen Risiken

Core v30 verschärft alle vier Punkte. Ein Node Betreiber, der das bevorzugt, wechselt einfach zu Knots — und viele tun das gerade [2].

Fazit zu Frage 1: Die Änderung nützt dem Node Betreiber nicht. Sie nützt nur Daten-Spammern und Minern, die mit Daten Gebühren verdienen wollen.

Frage 2: Wenn Filter doch eh „wirkungslos“ sind, weshalb hebt Core das Limit auf?

Antwort: Das ist die Crux. Core argumentiert: „Filter sind ineffektiv, also brauchen wir sie nicht“ [4].

Das ist falsch, aus zwei Gründen:

Filter sind jetzt effektiv, weil fast alle Nodes sie haben: Wenn 99,4% der Transaktionen die Filter respektieren, ist das nicht „wirkungslos“ — das ist Koordination [2]. Filter schaffen Anreize, keine Blockaden.
Core hebt das Limit auf, um die Koordination zu zerstören: Damit Daten-Spammer Ihre Gebühren senken können und Knots-Filter irrelevant werden. Das ist Strategische Policy Änderung zur Gunsten des Daten-Speicher-Sektors.

Fazit zu Frage 2: Die Aufhebung ist nicht neutral. Sie favorisiert eine Daten-Speicher-Industrie über Bitcoin’s Monetären Incentive.

Frage 3: Warum hielten sich 99,4% der Transaktionen an die Filter?

Antwort: Das ist das Gegenbeweis zu „Filter sind wirkungslos.“

99,4% Compliance bedeutet, dass Miner selbst filtering anwenden[2]. Sie wissen, dass non-standard Transaktionen mit Propagation-Latenzen kämpfen. Das ist de facto wie eine Gebühr — oder eine Filterung auf der Miner-Seite. Die Filter sind also nicht tot. Sie sind in der Ökonomie eingebettet.

Fazit zu Frage 3: Die hohe Compliance zeigt, dass Filter real funktionieren. Core v30 zerstört diese Koordination absichtlich.

Frage 4: Die Knots Implementation will mit voller Node-Kontrolle den Status Quo erhalten. Wo haben sie Unrecht?

Knots-Position [2]:

Erhalt der bewährten OP_RETURN-Filter seit 2014: ✓ Sinnvoll
Volle Node-Kontrolle über Mempool Policy: ✓ Klassischer Bitcoin-Gedanke
Ablehnung von „neutraler“ Standardisierung für Daten-Speicherei: ✓ Technisch berechtigt

Core’s Position:

„Filter sind neutral, wir machen die Politik nicht“: ✗ Das ist heuchlerisch. Ein Jahrzentelanges Limit heimlich aufzuheben ist auch Politik.
„Miner wollen das“: ? Einige ja, aber nicht alle. Und „Miner wollen es“ ist nicht gleich „Nutzer wollen es“.

Teil 7: Die tiefere Schicht — Template-Kontrolle und Dezentralisierung

Das Stratum-v2 und DATUM Problem

Hier wird es subtil. Es gibt zwei Szenarien[7]:

Szenario A (Status quo):

Mining Pools bauen Block Templates zentral
Sie können Daten-Transaktionen filtern
Mit Core v30: Können sie es, aber andere Pools nicht
Resultat: Asymmetrische Macht

Szenario B (mit Stratum v2/DATUM):

Miner bauen Block Templates selbst
Sie können selbst policy-optionen anwenden
Mit BIP-110: Consensus macht Daten-Speicherei teuer
Mit Core v30: Daten-Speicher zahlen gleich — Miner sind indifferent

Das ist der echte Kampf: Wer kontrolliert die Template-Negotiation?

BIP-110 macht Template-Dezentralisierung wahrscheinlicher, weil die Consensus-Ebene die Daten-Profite zerstört. Damit müssen Pools Miner ansonsten überzeugen — nicht nur Policy-Defaults reichen[7].

Core v30 macht Template-Dezentralisierung weniger wahrscheinlich, weil zentrale Pools weiterhin Daten-Gebühren verdienen können[7].

Das ist auch ein Dezentralisierungs-Argument für BIP-110.

Teil 8: Legale und reputationale Risiken für Node Betreiber

Ein Argument, das Nick Szabo und Luke Dashjr vorgebracht haben: Archival Nodes könnten illegale Inhalte speichern [2][6]. Das ist nicht paranoid:

BSV hat dokumentierte CSAM-Inhalte auf der Blockchain[2]
Mit 100KB OP_RETURN-Limits ist das realistisch möglich
Ein Node Betreiber, der willentlich ein Kind mit CSAM betreibt, kann strafrechtlich haftbar sein[2]

Das ist nicht „Zensur-FUD“ — sondern ein reeles juristisches Risiko.

Mit BIP-110 (256-Byte Max) wird das speichern großer Dateien consensus-level unmöglich. Das reduziert das Risiko für Node Betreiber erheblich.

Ein weiteres Argument für BIP-110 liegt ernetu auf der Nutzer-Seite.

Teil 9: Warum sich Spammer gegen Knots „vereinigen“ — Die Ökonomie der Opposition

Die Antwort ist reine Ökonomie:

Akteur	Interesse	Strategie gegen Knots
Marathon (Slipstream)	Daten-Gebühren-Revenue	Diskreditierung von Filtern, „Zensur“-Narrative
Inscription Services	Billiges Blockspace	„Bitcoin sollte offen sein“, Ad-hominem Attacken
Rune-Trader	Spekulativ Profit	Normalisierung von Daten-Storage
Pseudo-Libertäre	Ideologische Blindheit	„Knots ist Zensur“ (falsch)

Keiner dieser Gruppen hat technische Argumente gegen Knots[2]. Deshalb griffen sie zu:

Persönliche Attacken gegen Luke Dashjr
Falsche Äquivalenzen: („Filter = Zensur“)
Red Herring Attack: („Aber die Miner können dies umgehen“)

Das sind Verzweiflungs-Manöver. Die technischen + ökonomischen Argumente bleiben auf Knots-Seite[2].

Fazit: Bitcoin und die Frage nach Protokoll-Integrität

Das tiefere Problem

Bitcoin ist nicht mehr neutral. Das ist ein Mythos, den Core 2025 dekonstruiert hat, indem sie das OP_RETURN-Limit aufhoben.

Jede technische Entscheidung ist eine normative Entscheidung[6]:

Ein niedriges OP_RETURN-Limit sagt: „Bitcoin ist Geld“
Ein hohes Limit sagt: „Bitcoin ist auch Datenspeicher“

Core v30 hat sich entschieden. Bitcoin Knots hat sich anders entschieden. BIP-110 zwingt die Entscheidung auf die Consensus-Ebene [3].

Die Lösung: BIP-110 + Knots + Dezentralisierte Templates

Hier das mögliche Szenario für 2026–2027[3][7]:

Nodes signalisieren BIP-110 (Über 55% nötig bis September 2026)
Miner: Wir können Daten-Gebühren nicht halten, wenn Consensus-Ebene sie unmöglich macht
Integrationen: Kleine Miner + Privacy-Pools signalisieren BIP-110
Dezentralisierung: Mit Template-Dezentralisierung (Stratum v2) wird Miner-Kontrolle verteilter
Status quo: Knots wird Standard, Core v30 zum „Experimental Branch“

Das ist nicht Zensur. Das ist Koordination auf realen Anreizen.

Bitcoin gehört der Gemeinschaft

Bitcoin gehört niemandem. Core kann nicht entscheiden, dass OP_RETURN limitlos sein soll, ohne Consensus der Nutzer[2].
BIP-110 erzwingt diese Consensus-Ebene. Mit September 2026 als harter Deadline[3].
Das ist keine Fork-Drohung sondern Nutzer Souveränität mit Rückgrat.

Literatur und Quellen

[1] OAK Research. (2025, November 16). „An update on OP_RETURN, Bitcoin Core v30, and the Core vs Knots War.“ https://oakresearch.io/en/analyses/fundamentals/update-op-return-bitcoin-core-v30-core-knots-war
[2] BitRef / Coin Dance. (2025). „Bitcoin Node Distribution.“ Various sources tracking Knots adoption surge from 5% to 21% (April–October 2025).
[3] Renaud Cuny. (2026, January 18). „Issue #6: BIP-110 — The Countdown Has Started.“ Substack. https://renaudcuny.substack.com/p/issue-6-bip-110-the-countdown-has
[4] ProtoS. (2025, August 14). „Three sneaky changes in Bitcoin Core v30 are confusing node operators.“ https://protos.com/three-sneaky-changes-in-bitcoin-core-v30-are-confusing-node-operators/
[5] ForkLog. (2025, October 12). „Bitcoin Core Developers Release Controversial Update.“https://forklog.com/en/bitcoin-core-developers-release-controversial-update/
[6] Blockworks. (2025, July 20). „Bitcoin is still money, 8 years on from the Blocksize War.“ https://blockworks.co/news/bitcoin-blocksize-war
[7] Bitcoin Optech. (2025, December 19). „Bitcoin Optech Newsletter #385: 2025 Year-in-Review — Mempool Policy and Template Control.“ https://bitcoinops.org/en/newsletters/2025/12/19/
[8] Bitfinex. (2025, September 4). „Why is Bitcoin Knots Becoming so Popular?“ https://blog.bitfinex.com/education/why-is-bitcoin-knots-becoming-so-popular/
[9] Nick Szabo. Twitter / X. (2025). Various warnings on Core v30 legal exposure risks.
[10] Luke Dashjr. (2023, December 7). Twitter statement on OP_RETURN philosophy. https://x.com/LukeDashjr/status/1733226675171962886
[11] Bitcoin Knots. Official Documentation. (2025). Policy defaults and implementation rationale.
[12] BIP-110 Specification. (2025). „Reduced Data Temporary Softfork.“ https://bip110.dev
13 https://www.reddit.com/r/Bitcoin/comments/1kab15o/bitcoin_cores_github_mods_have_been_banning_users/
14 https://github.com/bitcoin-core/meta/discussions/18

Dieser Artikel wurde auf Grundlage von Quellen (Oktober 2025–Januar 2026) verfasst. Die Analyse konzentriert sich bewusst auf die Anreize hinter den ideologischen Fronten — nicht weil Ideologie irrelevant ist, sondern weil sie oft die echten Motivationen verschleiert.