Bitcoin Core hebt OP_RETURN-Limit nach kontroverser Debatte auf!
Kurze Einordnung: Was bisher geschah
Die Bitcoin-Entwicklergemeinde diskutierte in den vergangenen Monaten heftig über den sogenannten OP_RETURN-Mechanismus. OP_RETURN erlaubt es, kleine Datenmengen in Bitcoin-Transaktionen einzubetten, ohne die UTXO-Datenbank dauerhaft zu belasten. Diese sogenannten „Datacarrier“-Transaktionen machen es möglich, Informationen außerhalb reiner Bitcoin-Transaktionen dauerhaft zu speichern – zum Beispiel kryptografische Beweise, Hashes oder Referenzen auf externe Daten.
Seit 2014 galt dabei ein Limit von 80 Byte – keine Konsensregel, sondern eine Standardeinstellung der Bitcoin-Core-Software, um Missbrauch und ein Aufblähen der Blockchain zu verhindern. Im Frühjahr dieses Jahres wurde jedoch ein Vorschlag eingereicht, der dieses Limit aufhebt und die zugehörigen Konfigurationsoptionen (-datacarrier, -datacarriersize) entfernen sollte.
Nachdem dieser erste Vorschlag zur vollständigen Entfernung der OP_RETURN-Begrenzung vorerst gescheitert war, wurde nun ein alternativer Pull-Request erfolgreich in den Bitcoin Core Code aufgenommen: PR #32406 hebt das Limit für „Datacarrier“-Transaktionen standardmäßig auf, lässt den Betreibern einer Bitcoin-Node jedoch optional die Möglichkeit, die alten Einstellungen manuell zu konfigurieren. Die Änderung sorgt somit zwar für technischen Spielraum – bleibt aber politisch umstritten.
Nach Abwägung der technischen Argumente für/gegen diese Änderung und unter Berücksichtigung der Einwände bin ich der Meinung, dass die Änderung übernommen werden kann.
Gloria Zhao, Bitcoin-Core-Maintainerin
Interview #20 - Bitcoin Core Update: Was bedeutet die OP_RETURN-Änderung? - mit Murch
Was ändert sich jetzt konkret?
Mit dem gestrigen Merge von PR #32406 wird das bisherige Standardlimit für OP_RETURN-Daten in Bitcoin Core aufgehoben. Technisch bedeutet das:
- Die bisher fest eingestellte Begrenzung der OP_RETURN-Datenmenge – genauer gesagt: der sogenannte -datacarriersize-Wert – wird als Policy-Einstellung gestrichen. Das heißt, der Bitcoin Core Client selbst gibt künftig kein festes Limit mehr vor.
- Stattdessen orientiert sich die zulässige Datenmenge künftig nur noch an den allgemeinen Standardregeln für gültige Transaktionen, wie sie von Bitcoin Core definiert werden. Diese Regeln bestimmen z. B., wie groß eine Transaktion insgesamt sein darf, damit sie vom Netzwerk als „standardkonform“ akzeptiert wird. Wichtig: Es handelt sich hierbei nicht um Änderungen am Konsensprotokoll – also an den fundamentalen Regeln, die alle Bitcoin-Nodes weltweit einhalten müssen.
- Wer weiterhin eine feste Größenbeschränkung für OP_RETURN-Daten setzen möchte – etwa um seinen Knotenpunkt (Node) vor übermäßiger Datennutzung zu schützen –, kann dies über eine einfache Konfiguration weiterhin tun. Die Änderung bedeutet also keinen Zwang für Node-Betreiber, sondern nur eine neue Voreinstellung.
Die Änderung betrifft also ausschließlich die Standardeinstellungen auf Policy-Ebene – das Bitcoin-Protokoll selbst bleibt unverändert. Damit wird mehr Flexibilität für Entwickler und Anwendungen geschaffen, ohne dass alle Nutzer gezwungen sind, das jeweilige Verhalten zu übernehmen. Wer eine konservativere Policy bevorzugt, kann seine Bitcoin-Node auch weiterhin so konfigurieren, dass sie größere OP_RETURN-Daten ablehnt.
Verantwortliche Entwicklerin erklärt die Gründe
Gloria Zhao, Bitcoin-Core-Maintainerin und maßgeblich verantwortlich für den Merge des Pull Requests, hat ihre Beweggründe ausführlich dargelegt. Das Hauptanliegen war es, zu verhindern, dass Nutzer auf besonders schädliche Methoden zum Speichern von Daten in der Blockchain ausweichen müssen, nur weil die bisherigen Regeln für OP_RETURN zu restriktiv waren. Sie erklärte:
Bild: HRF
Der primäre Grund für diesen Pull Request ist, eine Diskrepanz zwischen der Schädlichkeit und Standardness von Datenspeicher-Techniken zu korrigieren. Das (prunbare) OP_RETURN-Feature sollte verfügbar sein, damit Daten nicht in unprunbare Outputs gestopft werden. Während Befürworter des PRs keine Fans von Datenspeicherung als Use Case sind, verursachen die bisherigen Standardmethoden (wie Bare Pubkeys) eine Aufblähung des UTXO-Sets und damit langfristige Kosten für das Netzwerk.
Ein weiterer wichtiger Aspekt für Zhao ist die Stärkung des dezentralen, öffentlichen Marktes für Blockspace, also den Speicherplatz in Bitcoin-Blöcken. Sie betonte, dass restriktive Policy-Regeln wie eben das OP_RETURN-Limit Nutzer dazu zwingen, Transaktionen direkt an Miner zu schicken, was wiederum die Dezentralität des Netzwerks gefährdet:
Diese Restriktionen drängen Menschen – zum Beispiel solche, die das UTXO-Set nicht aufblähen wollen – dazu, Transaktionen direkt an Miner zu schicken. Das schadet der Nützlichkeit des Mempools und erzeugt Zentralisierungsdruck. Wenn große Akteure wie Second-Layer-Anwendungen oder Börsen beginnen, direkte Beziehungen zu Minern aufzubauen, untergräbt das die erlaubnisfreie Struktur von Bitcoin, schwächt die Zensurresistenz und die Privatsphäre der Transaktionsübermittlung und zerstört die schnelle Blockpropagation, von der unser Netzwerk seit Jahren profitiert.
Zhao ging auch auf die Kritik ein, dass Bitcoin Core durch die Änderung bestimmte Use Cases fördern oder unterbinden könnte. Sie hielt dagegen:
Es ist nicht möglich, dass Bitcoin Core bestimmte Arten von Transaktionen am Minen hindert. Bitcoin Core ist Open-Source-Software, die freiwillig von Nutzern – darunter auch Miner – betrieben wird. Die Forderung, Bitcoin Core solle bestimmte Transaktionen verhindern, zeugt von einem Missverständnis der Beziehung zwischen Open-Source-Entwicklern und Nutzern.
Abschließend betonte sie noch einmal, dass OP_RETURN-Transaktionen keine langfristigen Belastungen für das Netzwerk darstellen und die wirtschaftlichen Anreize ohnehin ausreichend sind, um Missbrauch zu verhindern. Sie sieht in der Änderung einen wichtigen Schritt, um Bitcoin weiterhin offen, dezentral und zensurresistent zu halten.
Den Gegnern zum Trotz
Trotz des nun umgesetzten Kompromissvorschlags stieß die Änderung nicht bei allen Leuten in der Bitcoin-Community auf Zustimmung. Zahlreiche Gegner der Entscheidung gaben ihren Unmut lautstark in den sozialen Medien, insbesondere bei 𝕏, zur Kenntnis.
Die Entfernung eines Spam-Filters in der Hoffnung, dass die Spammer von schädlichen gefälschten Pub-Keys auf Op-Return umsteigen, ohne dass dies garantiert ist, ist reines Wunschdenken. […] Es war von Anfang an ein Gaslighting, und das ist eine sehr bittere Pille, die man schlucken muss.
@GrassFedBitcoin, CTO bei Ocean-Mining
Andere wiederum freuten sich über die Entscheidung des Entwickler-Teams von Core. Der bekannte Bitcoiner „Wicked“ erklärte etwas provokant:
Die Aufhebung des Datacarrier-Limit wurde standardmäßig in Core integriert. [Das Core-Team] hat sich nicht dem Willen der technisch ungebildeten, lauten Minderheit gebeugt.
Wicked bei 𝕏
Für viele weitere Personen war die ganze Debatte ohnehin ein „Nothingburger“, der sprichwörtlich viel heißer gekocht wurde, als er gegessen wird. Jameson Lopp, ebenfalls einer der bekanntesten Bitcoin-Entwickler, merkte deshalb an:
Vorausschauend war es ohnehin unvermeidlich. Auf zu wichtigeren Dingen!
Jameson Lopp bei 𝕏
Dennoch bleibt der Schritt umstritten und zeigt einmal mehr, wie sensibel selbst kleine Veränderungen, die nicht einmal den Konsens betreffen, im Bitcoin-Ökosystem diskutiert werden. Die Debatte um den sinnvollen Umgang mit „Daten im Geld“ dürfte damit jedenfalls noch lange nicht beendet sein.
Das könnte dich auch interessieren
Kommentare aus unserem Forum
