Vor ein paar Tagen veröffentlichte ein Bitcoin Core Entwickler eine Änderungsanfrage, um das standardmäßige Limit für Daten in OP_RETURN-Outputs aufzuheben. Eine Diskussion unter Entwicklern und größeren Teilen der Bitcoin-Community folgte, die teilweise recht hitzig und schwer zu verfolgen wurde. Während die Bitcoin Core Maintainer sich scheinbar geeinigt haben, die vorgeschlagene Änderung umzusetzen, kritisieren andere den mangelnden Konsens und mögliche Folgen für das Netzwerk.

In diesem Artikel wollen wir einen Schritt zurücktreten und hilfreichen Kontext zum allgemeinen Konzept der Datenspeicherung auf der Bitcoin-Blockchain geben – also Daten, die nicht direkt etwas mit einer Bitcoin-Zahlung zu tun haben. Wir betrachten dafür verschiedene Ansätze, wie dies erreicht werden kann, wie OP_RETURN tatsächlich funktioniert und worum es in der aktuellen Diskussion wirklich geht. Los geht’s!

Willkürliche Daten auf der Bitcoin-Blockchain

Die Idee, beliebige Daten auf der Bitcoin-Blockchain zu speichern, ist so alt wie das Netzwerk selbst. In den letzten Jahren wurde die Debatte darüber jedoch durch wachsendes Interesse (und Widerstand) gegen die Speicherung großer Mengen an Texten, Bildern oder sogar Videos auf der Blockchain angeheizt.

Die Diskussion, ob ein Datensatz „Spam“ oder eine “ökonomische Transaktion“ ist, kann schnell subjektiv und sogar ein wenig philosophisch werden. Natürlich gibt es viele Transaktionen, bei denen die ökonomische Relevanz offensichtlich ist, etwa eine Zahlung an die Adresse eines bekannten Händlers oder eine Auszahlung von einer Exchange. Manche bezeichnen diese Zahlungen als „echte“ Bitcoin-Transaktionen. Aber so einfach ist es nicht immer. Ist eine Transaktion von und zu deiner eigenen Wallet ökonomisch relevant? Woher weißt du, dass eine Bitcoin-Adresse eine „echte Adresse“ ist und keine versteckte Nachricht? Gibt es überhaupt einen Unterschied?

Spam… überall!

Das Bitcoin-Protokoll bietet viele Stellen, an denen man „nicht-transaktionsbezogene“ Daten speichern kann. Beispielsweise können Miner die Coinbase-Transaktion nutzen, um eine Textnachricht zu speichern – das prominenteste Beispiel stammt von Satoshi Nakamoto selbst, im Genesis-Block:

The Times 03/Jan/2009 Chancellor on brink of second bailout for bank

Andere missbrauchen direkt öffentliche Schlüssel und Adressen zur Datenspeicherung. Normalerweise geht man davon aus, dass ein öffentlicher Schlüssel von einem privaten Schlüssel abgeleitet wurde, den irgendjemand auch tatsächlich besitzt. Aber woher will man das wissen? Niemand kann einen daran hindern, eine Textnachricht in ein paar öffentliche Schlüssel zu codieren und eine kleine Menge Bitcoin an diese zu senden. Genau das tun Nutzer des STAMP-Protokolls – und vergrößern so das Bitcoin UTXO-Set mit Outputs, die niemals ausgegeben werden können.

Zwei Standard-Outputs, wobei Transaktion B eine willkürliche Nachricht anstelle eines Public-Key-Hashes enthält

Aber das ist noch nicht alles: Das Ordinals-Protokoll, das 2023 populär wurde, nutzt die „Witness“-Erweiterung von Bitcoin-Blöcken – dort, wo man normalerweise digitale Signaturen findet – zur Speicherung sehr großer Datenmengen. Es gibt sogar einen finanziellen Anreiz, diesen Teil eines Bitcoin-Blocks zu nutzen, da durch die Art und Weise, wie Speicherplatz bei SegWit-Transaktionen berechnet wird, ein effektiver Gebührenrabatt entsteht. Block 774628 beispielsweise war fast 4 MB groß und enthielt ein einziges hochauflösendes Bild von Julian Assange.

Das Durchscrollen der Witness-Daten dieser Transaktion kann eine Weile dauern!

Es wird schnell klar: Will man willkürliche Daten auf der Bitcoin-Blockchain speichern, kann man das definitiv tun. Es gibt dafür mehrere Möglichkeiten, und die einzige praktische Grenze ist die maximale theoretische Blockgröße von 4 MB. Und dabei haben wir OP_RETURN noch nicht einmal erwähnt!

Eine unbequeme Wahrheit?

Die meisten Felder in Bitcoin-Transaktionen und -Blöcken, die nicht direkt durch Protokollregeln definiert werden, können mit beliebigen Daten gefüllt werden, unabhängig von ihrem eigentlichen Zweck. Das ist eine unvermeidbare Tatsache, denn ob Daten relevant sind, hängt von subjektiver Interpretation ab – was insbesondere in einem unregulierten und dezentralen Netzwerk wie Bitcoin nicht immer möglich ist.

Ob man das Speichern willkürlicher Daten auf der Bitcoin-Blockchain nun gut findet oder nicht – es macht keinen wirklichen Unterschied. Da man es praktisch nicht verhindern kann, kann man argumentieren, dass es bessere und schlechtere Wege gibt, „Spam“ auf der Blockchain zu speichern. Schauen wir uns das etwas genauer an.

OP_RETURN

Trotz des kompliziert klingenden Namens ist OP_RETURN wohl eine der am einfachsten zu verstehenden Befehle der Bitcoin-Skriptsprache – denn er tut im Grunde nichts. Wenn eine Bitcoin-Node eine Transaktion überprüft und auf einen OP_RETURN Output stößt, markiert sie diesen sofort als ungültig und macht weiter.

Auf den ersten Blick mag diese „Funktion“ nutzlos erscheinen, aber es gibt zwei Hauptgründe für die Verwendung von OP_RETURN Outputs:

  • Coins verbrennen: An einen OP_RETURN Output gesendete Bitcoin sind für immer gesperrt und können nicht mehr ausgegeben werden. Es ist eine nachweisbare Methode, Coins zu „verbrennen“, was gelegentlich aus rechtlichen Gründen nützlich sein kann – oder einfach aus Spaß, wenn man eine Wette verloren hat. Deshalb muss man beim Erstellen von Transaktionen mit OP_RETURN sehr vorsichtig sein, seine Coins nicht versehentlich unbrauchbar zu machen.
  • Daten als irrelevant markieren: Beim Speichern willkürlicher Daten dient OP_RETURN als ein früher Hinweis für Bitcoin-Nodes: „Du kannst den Rest ignorieren“. Da die Ausgabe immer ungültig ist, gibt es keinen Grund, ihren Inhalt zu speichern. Das ist ideal für sogenannte „pruned nodes“, also Nodes, die nicht die gesamte Blockchain speichern. Diese können OP_RETURN Outputs gefahrlos ignorieren und müssen ihn nicht in ihr UTXO-Set aufnehmen – was Speicherplatz spart.

Erinnern wir uns daran, wie schwer es sein kann, die Relevanz von Daten zu beurteilen: OP_RETURN gibt Nutzern die Möglichkeit, diese Entscheidung selbst zu treffen und sie dem Netzwerk mitzuteilen. Das ist effizienter als viele der zuvor genannten Alternativen. Auch wenn OP_RETURN Outputs zur Gesamtgröße der Blockchain beitragen, werden sie nicht in das UTXO-Set aufgenommen – Nodes müssen sie also nicht dauerhaft “im Hinterkopf” behalten.

Nodes können die Nachricht nach der ersten Überprüfung ignorieren und löschen.

Mempool Richtlinien

Aber was hat es mit dem anfangs erwähnten OP_RETURN „Limit“ nun auf sich?

Bitcoin Core enthält viele Einstellungen und Konfigurationsmöglichkeiten, die das Verhalten einer Nodes im Netzwerk beeinflussen und in der Regel einen vorab festgelegten Standardwert haben. Einige davon betreffen die Frage, ob die Node eine neue Transaktion weiterleiten und in ihrem lokalen Mempool speichern soll – diese Regeln nennt man oft Mempool Richtlinien (en. mempool policies). Wichtig ist: Ob eine Transaktion gültig ist und in einen neuen Block aufgenommen werden kann, ist eine komplett andere Frage, die durch Konsensregeln bestimmt wird und mit dieser Diskussion nichts zu tun hat.

Zum Zeitpunkt dieses Artikels hat Bitcoin Core ein Standardlimit von 80 Bytes für Daten in OP_RETURN Outputs – dies konnte bisher aber jederzeit individuell geändert werden. Das bedeutet lediglich, dass eine Node standardmäßig keine Transaktion mit einem OP_RETURN-Outputs über 80 Byte (oder dem eingestellten Wert) weiterleitet und in ihren Mempool aufnimmt. Wenn diese Transaktion aber in einem neuen Block enthalten ist, akzeptiert die Node sie trotzdem, da das Limit keine Konsensregel ist.

Kurz gesagt: Es ist derzeit ziemlich schwierig, Transaktionen mit großen OP_RETURN Outputs zu veröffentlichen, weil fast alle Nodes sie aufgrund des Standardlimits nicht weiterleiten werden. Aber dieses Limit hat seine Grenzen:

  • Keine Konsensregel: Da Transaktionen mit größeren OP_RETURN Outputs unter den Konsensregeln gültig sind, können Miner sie trotzdem freiwillig in Blöcke aufnehmen. Eine einzelne Transaktion kann sogar mehrere OP_RETURN Outputs beliebiger Größe enthalten.

    Das geht, indem man entweder direkt Miner kontaktiert oder sich mit Nodes verbindet, die diese Richtlinie nicht durchsetzen – so erreicht die Transaktion die Miner. Miner haben in der Regel immer ein finanzielles Interesse, Transaktionen mit hohen Gebühren aufzunehmen, unabhängig von ihrem Inhalt oder Kontext. Es reicht, wenn ein einziger Miner dazu bereit ist, die Transaktion aufzunehmen. Durch diesen Aspekt erhält das Bitcoin-Netzwerk auch die Eigenschaft der Zensurresistenz.
  • Alternative Methoden: Es gibt viele Möglichkeiten, große Datenmengen zu speichern, die noch schwerer zu verhindern sind – etwa Inscriptions im “Witness” oder öffentliche Schlüssel und Hashes in Standard-Outputs. Der Missbrauch von Standard-Outputs zur Speicherung willkürlicher Daten ist technisch fast unmöglich zu verhindern und kann schnell zu einem Katz-und-Maus-Spiel führen, in dem immer mehr Regeln zu immer absurderen Methoden führen, um die Regeln zu umgehen.

Abschaffung des Limits

Das Hauptargument für die Abschaffung des 80-Byte-Limits ist also seine Ineffektivität: Es verhindert nicht wirklich das Speichern von Daten auf der Blockchain, wie andere – teils schlimmere – Methoden zeigen. Man könnte das Limit auch erhöhen, aber die gleichen Argumente würden für beliebig höhere Limits ebenfalls gelten – weshalb die Core-Entwickler für eine vollständige Abschaffung plädieren.

Ein aktives Limit für OP_RETURN-Outputs fördert aktiv die Nutzung schlechterer Alternativen, was zu ineffizienten Anreizen führt. Besserer Zugang zu OP_RETURN kann die Ressourcenauslastung für Node-Betreiber und die Effizienz des Netzwerks also verbessern. Schon vor über zehn Jahren argumentierten die Release-Notes von Bitcoin-Core ähnlich:

Diese Änderung ist keine Befürwortung der Datenspeicherung in der Blockchain. OP_RETURN erzeugt einen Output, der nachweislich nicht ausgegeben werden kann, um Daten-Speicherstrategien zu vermeiden – von denen einige bereits existierten – bei denen willkürliche Daten wie Bilder als Outputs gespeichert wurden, die niemals ausgegeben werden können, was das UTXO-Set aufbläht.

Jetzt, wo wir die Hintergründe besser verstehen, schauen wir uns auch die Gegenseite an!

Was spricht gegen die Änderung?

Befürworter betonen Effizienz und technische Pragmatik, doch die Debatte hat auch Gegenargumente hervorgebracht, die über technische Details hinausgehen. Kritiker äußern sowohl philosophische als auch praktische Bedenken – sie fragen, ob die Änderung mit den langfristigen Zielen von Bitcoin vereinbar ist und ob das Problem der willkürlichen Daten wirklich adressiert.

Ein Finanznetzwerk 

Die meisten Kritiker wollen Bitcoin als Finanzprotokoll bewahren und seine Nutzung als allgemeine Datenbank verhindern. Aus dieser Sicht riskiert die Aufhebung des Limits, nicht-finanzielle Nutzung zu normalisieren und ein falsches Signal über den Zweck von Bitcoin zu senden. Auch wenn technisch unbedenklich, könnte sie neue Anwendungsfälle hervorbringen, die den ursprünglichen Zweck von Bitcoin verwässern und die Anforderungen für Nodes erhöhen. Skeptiker bezweifeln auch, ob die Änderung die negativen Auswirkungen von Spam überhaupt verringert.

Warum die Option entfernen?

Viele halten es auch für akzeptabel, das Standardlimit zu entfernen – aber nicht, die Möglichkeit zur individuellen Begrenzung komplett zu streichen. Da es bereits eine funktionierende Lösung gibt, um eigene Limits für OP_RETURN zu setzen, gibt es wenig Grund, Nutzern diese Möglichkeit zu nehmen. Mempool Richtlinien sollten individuell konfigurierbar bleiben – getreu dem Motto „dein Node, deine Regeln“.

Bedenken zum Prozess

Auch die Art und Weise der Einführung wurde kritisiert. Die Geschwindigkeit, mit der die Änderung in die nächste Version von Bitcoin Core übernommen werden soll, sowie die Entfernung zugehöriger Konfigurationsoptionen, werfen Fragen auf. Auch wenn die Konsensregeln unverändert bleiben, sehen Kritiker in der Änderung von langjährigen Standards ohne breiten Konsens ein Risiko für Vertrauen und Präzedenzfälle.

Im Zweifelsfall lieber nicht

Für viele geht es letztlich um Vorsicht. Die Änderung könne das Problem nicht lösen, Nebeneffekte haben und fände keine breite Unterstützung. In solchen Fällen sei es vernünftiger, die aktuelle Politik beizubehalten, Optionen offenzulassen und die Debatte später mit besseren Lösungen oder breiterem Rückhalt neu aufzurollen. In einem System wie Bitcoin, das auf Stabilität und Vorhersagbarkeit beruht, ist das Festhalten am Status quo oft die risikoärmste und klügste Option.

Der Schutz vor Spam

Im Allgemeinen hat das Bitcoin-Netzwerk einen sehr effektiven Schutzmechanismus gegen Spam: den freien Gebührenmarkt für Transaktionen. Mit einer konstanten Menge an Speicherplatz (etwa 2–3 MB alle zehn Minuten) regelt die Nachfrage nach Transaktionen automatisch ihre Priorität – ohne zentrale Entscheidungsträger. Genau wie Angebot und Nachfrage den Bitcoin-Preis bestimmen, bestimmt der Gebührenmarkt den Preis einer Transaktion. Keine einzelne Entität kann dies langfristig manipulieren – denn niemand hat unendlich viele Bitcoin, um dafür zu bezahlen.

Zusammenfassung

Wie bei vielen Bitcoin-Debatten gibt es kein Richtig oder Falsch – nur Kompromisse. Die vorgeschlagene Änderung verbessert den technischen Umgang mit willkürlichen Daten, wirft aber berechtigte Fragen nach langfristigen Anreizen, Kultur und Entscheidungsprozessen auf. Ob als pragmatische Verbesserung oder als riskanter Präzedenzfall gesehen – die Debatte zeigt, wie komplex es ist, ein dezentrales System mit unterschiedlichen Interessen aufrechtzuerhalten.

Stell dir eine Zukunft vor, in der ein Großteil der Welt regelmäßig Bitcoin-Transaktionen erstellt. Große Unternehmen und vielleicht sogar Staaten müssen ihre Coins bewegen. Private Nutzer eröffnen und schließen ihre Lightning-Kanäle regelmäßig. Kurz: Bei hoher Transaktionsnachfrage sind auch die Gebühren sehr hoch. Man kann argumentieren, dass es auf lange Sicht kaum einen Markt für „nutzlose“ Daten auf der Blockchain geben wird. Genau wie der Markt entscheidet, ob Bitcoin wertvoll ist, entscheidet der Gebührenmarkt, ob eine Transaktion wertvoll ist.

Vor diesem Hintergrund könnte die Entscheidung, die OP_RETURN-Begrenzung zu entfernen oder beizubehalten, geringere Auswirkungen haben, als man zunächst denken würde. Ziel der Abschaffung ist in erster Linie ein effizienterer Umgang mit größeren Datenmengen. Oder anders gesagt: das „geringere Übel“ im Vergleich zum Missbrauch von normalen Outputs zu wählen.

Das Thema ist außerdem ein gutes Beispiel dafür, wie sich Debatten in der Bitcoin-Entwicklung entwickeln können – vielleicht auch hin zu einer größeren Vielfalt an Bitcoin-Implementierungen und einem besseren Verständnis dafür, wie Mempool Richtlinien und Konsensregeln tatsächlich funktionieren. Was auch immer passiert: Jeder wird seine Node-Software nach eigenen Vorstellungen wählen und konfigurieren können – denn genau darum geht es schlussendlich bei Bitcoin.


Du hast noch keine BitBox?

Deine Kryptowährungen sicher zu halten muss nicht schwer sein. Die BitBox02 Hardware Wallet speichert die privaten Schlüssel deiner Kryptowährungen offline. So kannst du deine Coins sicher verwalten.

Die BitBox02 gibt es auch als Bitcoin-only-Version mit einer radikal fokussierten Firmware: weniger Code bedeutet weniger Angriffsfläche, was deine Sicherheit weiter verbessert, wenn du nur Bitcoin speicherst.

Hol dir eine in unserem Shop!‌


Die BitBox-Produkte werden von Shift Crypto, einem privaten Unternehmen mit Sitz in Zürich, Schweiz, entwickelt und hergestellt. Unser Team aus Bitcoin-Entwicklern, Krypto-Experten und Sicherheitsingenieuren entwickelt Produkte, die unseren Kunden eine stressfreie Reise vom Anfänger zum Meister der Kryptowährung ermöglichen. Die BitBox02, unsere Hardware-Wallet der zweiten Generation, ermöglicht es den Nutzern, Bitcoin und andere Kryptowährungen zu speichern, zu schützen und mit Leichtigkeit zu handeln – zusammen mit der dazugehörigen Software, der BitBoxApp.