Bitcoin Core Update: OP_RETURN-Änderung gescheitert, neuer Vorschlag vorgestellt

In den vergangenen Tagen berichtete Blocktrainer.de bereits mehrfach über die in der Bitcoin -Community entbrannte Debatte um die geplante Aufhebung der Limits für OP_RETURN-Ausgaben in Bitcoin Core. Nachdem der erste Vorschlag (PR #32359) tatsächlich zurückgezogen wurde, hat sich die Diskussion nun auf einen neuen, etwas moderateren Vorschlag verlagert. Ende April wurde auf GitHub der besagte Pull Request #32359 eröffnet. Dabei handelte es sich allerdings nicht um einen völlig neuen Vorschlag, sondern um eine überarbeitete Kopie eines früheren Pull Requests von Bitcoin-Entwickler Peter Todd aus dem Jahr 2022. Todd erklärte, dass er den PR im Zuge einer aufkeimenden Diskussion auf der Mailing-Liste und auf Bitten eines aktiven Bitcoin Core-Entwicklers erneut eingestellt habe. Der PR #32359 sah vor, das bestehende 80-Byte-Limit vollständig aufzuheben und gleichzeitig die Konfigurationsparameter -datacarrier und -datacarriersize zu entfernen. Diese erlauben es Node -Betreibern bislang, die maximale OP_RETURN-Datengröße individuell festzulegen. Die Befürworter der Änderung argumentierten, dass das Limit technisch längst umgangen wird und eher zu ineffizienten Workarounds führe, die das Netzwerk belasten. Der Vorschlag stieß jedoch auch auf Kritik innerhalb der Bitcoin-Community und der Entwicklergemeinschaft. Einerseits etwas überzogen, andererseits aber auch durchaus berechtigt. Es würde im Rahmen dieses Artikels aber zu weit führen, noch einmal alle Pro-und Conta-Argumente aufzugreifen. Wer sich für das Thema interessiert, sollte gegebenenfalls eine von uns produzierte und mit dem Core-Entwickler „Murch“ aufgenommene Podcast-Folge hören, welche die Thematik im Detail aufklärt. Ein zentraler - und für viele Beobachter nachvollziehbarer - Kritikpunkt betraf vor allem die geplante Abschaffung der Konfigurationsmöglichkeiten -datacarrier und -datacarriersize . Diese Optionen erlauben es Node-Betreibern bislang, individuell festzulegen, ob und in welchem Umfang OP_RETURN-Daten akzeptiert und weitergeleitet werden. Kritiker sahen in der ersatzlosen Streichung einen schwerwiegenden Eingriff in die Autonomie der Betreiber und einen möglichen Präzedenzfall für weitere Einschränkungen. Gerade im dezentralen Bitcoin-Netzwerk gilt die Freiheit, eigene Policy-Regeln zu setzen, schließlich als wichtiger Grundsatz. Der Entfall dieser Flexibilität wäre daher aus Sicht vieler Entwickler nicht hinnehmbar gewesen. Am Ende entschied Bitcoin-Core-Entwicklerin Gloria Zhao, den PR #32359 zu schließen. In ihrer Stellungnahme betonte sie, dass ein Konsens bestehe, zumindest die Konfigurationsmöglichkeiten für Node-Betreiber weiterhin beizubehalten. Deshalb werde dieser Vorschlag nicht weiterverfolgt. Bereits wenige Tage nach dem ursprünglichen Vorschlag wurde von Entwickler Greg Sanders (alias instagibbs) ein alternativer Pull Request unter der Nummer #32406 eingereicht. Dieser verfolgt einen deutlich moderateren Ansatz: Das 80-Byte-Limit für OP_RETURN wird standardmäßig aufgehoben . Die Konfigurationsoptionen -datacarrier und -datacarriersize bleiben jedoch bestehen. Node-Betreiber können somit auch künftig individuell entscheiden, ob sie größere OP_RETURN-Daten akzeptieren oder nicht. Ob der neue Vorschlag PR #32406 tatsächlich in Bitcoin Core aufgenommen wird, ist aktuell noch offen. Die Diskussionen auf GitHub und in der Mailingliste laufen weiter. Es zeichnet sich jedoch ab, dass der Ansatz von instagibbs innerhalb der Entwicklergemeinschaft auf deutlich mehr Zustimmung stößt als der ursprüngliche Vorstoß von Peter Todd. Die Debatte zeigt einmal mehr, wie hoch der Anspruch an Konsens und Sorgfalt bei Änderungen am Bitcoin- Protokoll ist. Entscheidungen werden eben nicht leichtfertig getroffen und müssen höchste technische und ethische Standards erfüllen.