Es gibt mal wieder Drama bei den Bitcoin-Entwicklern. Diesmal geht es darum, ob und auf welche Weise Daten in der Blockchain gespeichert werden sollen. Ich empfehle sehr, den Post ganz durchzulesen, denn das Drama wird oft sehr vereinfacht dargestellt. Es ist etwas komplex, aber es lohnt sich um das Problem zu verstehen.

Peter Todd (vielleicht einigen bekannt dafür, dass ein HBO-Dokumentarfilm letztes Jahr glaubte, ihn als Satoshi enttarnt zu haben, was er selbst energisch bestreitet) hat eine Pull Request in den Bitcoin-Core-Code eingestellt. Eine Pull Request ist sozusagen ein präziser Vorschlag, was geändert werden soll, mit dem gesamten dafür notwendigen (und schon getesteten) Programmcode.

Dazu erstmal etwas Kontext: OP_RETURN ist ein Befehl der Bitcoin-Skriptsprache, dass Nodes und Miner alle Daten hinter diesem Befehl ignorieren, aber erst mal als Teil der Transaktion speichern sollen. Er wurde ca. 2014 eingeführt, um eine für die Nodes schonende Möglichkeit einzuführen, Daten auf der Blockchain zu speichern. Der Platz für Daten hinter dem Befehl OP_RETURN ist derzeit durch sogenannte "Standardness"-Regeln auf 80 Bytes begrenzt. Diese Regeln sind nicht Teil des Protokolls, sondern einfach Standardwerte. Jeder kann diese Werte ändern ohne gegen das Protokoll zu verstoßen.

Wichtig: Bereits vorher gab es schon Ideen und einfache Protokolle, um Daten wie NFTs oder Tokens zu speichern. Dies wurde entweder getan, indem ungenutzte "Felder" der Transaktionen genutzt wurden (z.B. die Sequence-Nummer) oder indem falsche öffentliche Schlüssel (Public Keys) mit falschen Adressen generiert wurden, die diese Daten enthielten.

Diese Mechanismen, die auch von in jüngerer Zeit neu entwickelten Protokollen genutzt werden (z.B. Bitcoin Stamps), haben jedoch das Problem, dass sie die Datenbank der UTXOs, der noch nicht ausgegebenen Coins (präziser: Ausgänge der Transaktionen) mit unnützen Daten vermüllen. Diese UTXO-Datenbank kann (anders als z.B. alte Blöcke) niemals gelöscht werden, da niemand sicher sein kann, dass sich darin nicht noch Coins verbergen, die man noch ausgeben könnte.

Dazu kommt seit 2022 ein von Ordinals bekannter Speichermechanismus, bei dem die Daten stattdessen in den Signaturen, also in den "Inputs" gespeichert werden.

Allgemein wird OP_RETURN als am wenigsten ressourcenhungrige Speicher-Option angesehen, weil die Daten wie gesagt ignoriert werden können. Das Ordinals-Modell ist ebenfalls noch halbwegs ressourcenfreundlich, da es die UTXO-Datenbank nicht nur dann belastet, wenn eine Ordinals-Transaktion ineffektiv durchgeführt wurde und Coins "übrigbleiben". (Edit: präzisiert)

Todds Pull Request hat nun zweierlei im Sinn:

1) Das 80-Byte Limit der Daten hinter OP_RETURN soll aufgehoben werden. Es könnten also theoretisch bis nahezu 100 kB Daten mit dieser Methode in eine Transaktion gespeichert werden (gleich dazu mehr)
2) Der gesamte Code, der dieses Limit ermöglicht, wird entfernt. Die Nodes haben heute (noch) beispielsweise die Option, mit datacarriersize selbst zu bestimmen, wie hoch die erlaubte Datenmenge sein soll. Dies würde, wenn die Pull Request durchkommt, zumindest mit Bitcoin Core ohne Patches nicht mehr möglich (andere Bitcoinclients wie Knots hingegen bieten die Option weiterhin).

(Eine alternative Pull Request, die aber vorerst geschlossen wurde, implementiert nur den ersten Punkt, die Nodes erhalten also weiter auch in Core eine Konfigurationsmöglichkeit für die Datenmenge. Das ist die zweite Option in der obigen Umfrage. Edit: Diese Pull Request wurde inzwischen in den Code integriert.)

Wie oben bereits angesprochen wird dadurch nicht eine Möglichkeit geschaffen, mehr Daten als bisher in Transaktionen unterzubringen. Mit der "Fake Public Keys"-Methode, die etwa Stampchain nutzt, kann man ähnlich hohe Datenmengen speichern. Mit der Ordinals/Taproot-Methode gehen sogar fast 400 kB, weil für Daten in den Signaturen seit dem 2017er Segwit Update vereinfacht gesehen viermal so viel Platz ist, da sie nur 1/4 der "gewichteten Einheiten" (Weight Units) verbrauchen. Sie ist zudem aus dem gleichen Grund billiger was die Fees angeht (wen das interessiert, der sollte sich mit Segwit befassen).

Nun zum Drama (wer in den Kaninchenbau einsteigen will, sollte genug Popcorn bereithalten, vielleicht auch Taschentücher):

Seit der Ordinals-Welle 2023 ist die Stimmung, was das Thema "Daten in der Blockchain" angeht, wegen der damals hohen Transaktionsgebühren aufgeheizt. Eine Gruppe um den Entwickler Luke Dashjr fordert, die Taproot/Ordinals-Methode zu filtern, also den Nodes zu ermöglichen diese Transaktionen einfach nicht mehr zu verarbeiten. Diese Gruppe hat sich auch vehement gegen die Pull Request von Peter Todd ausgesprochen, da dadurch noch ein weiteres Tor für mehr Daten auf der Blockchain aufgestoßen würde (siehe dazu aber oben: heute geht mit anderen Methoden wie den falschen Pubkeys und Taproot-Signaturen schon mehr).

Soweit ein typischer Entwickler-Streit, könnte man meinen. Kommt in jedem Open Source Projekt vor ...

Aber dann gab Peter Todd an, dass der Anlass ein Protokoll einer geplanten Sidechain namen Citrea gewesen sei. Diese habe die "Falsche Pubkeys"-Methode nutzen wollen. Um zu verhindern, dass auch diese Sidechain die UTXO-Datenbank vollmüllt, sollte also laut Todd das OP_RETURN Limit wegfallen. Denn dann könnte Citrea stattdessen die weniger ressourcenhungrige OP_RETURN Methode nutzen.

Peter Todd wird jetzt vorgeworfen, mit der Pull Request nur dem Unternehmen hinter Citrea einen Gefallen tun zu wollen. Dazu kommt, dass eine andere Person 2023 Todd für eine ähnliche Pull Request, die damals zurückgezogen wurde, 1000 US-Dollar gespendet hat. Was unter anderem Samson Mow genüsslich ausgeschlachtet hat, der wohl auf der Seite der Gegner dieser Änderung steht. Todd und womöglich Core wird also Korruption vorgeworfen.

Was meint die deutschsprachige Community? Seid ihr auf dieses Drama schon gestoßen? Oder uninteressant?

>> Hier eine etwas kürzere Pro-Contra-Liste und meine eigene Meinung. <<

Einen englischen Faden dazu gibt es hier.

(Immerhin wissen wir nun, dass Todd wahrscheinlich nicht Satoshi ist. Würde Satoshi mit seinen Millionen BTC 1000$ für eine Pull Request brauchen?  )

Ich kann nicht für die komplette deutschsprachige Community sprechen, aber für mich schon. DANKE, dass du das Thema in unseren Bereich geholt hast.
Im englischen Teil hatte ich zwar schon davon gelesen, aber in unserer Sprache und auch dank des Artikels von cygan verstehe ich nun besser worum es im Detail geht

Eine erste Meinung dazu kann ich noch nicht absenden, da ich sie noch nicht habe. Das Thema ist auch viel zu komplex bzw. mehrschichtig, um das in kurzen Worten zusammenzufassen.
Auch ChatGPT ist sich unsicher

Bin gespannt welche Meinungen es hier geben wird und wie die Leute entscheiden, die es dann auch umsetzen müssen.

Ich dachte ich poste doch noch eine kurze Pro-Contra-Liste um den doch ziemlich langen Eingangspost knapper zusammenzufassen:

Pro Änderung:

- OP_RETURN ist die am wenigsten ressourcenhungrige Methode zur "Datenspeicherung" bei BTC und sollte nicht stärker beschränkt sein als andere Techniken.
- Die Alternativmethode "Fake-Pubkeys" kann leider nicht unterbunden werden. Sie führt zu Lasten für die Nodes, da die Daten für immer und ewig im UTXO-Set gespeichert werden.
- OP_RETURN wird mit der Änderung der ressourcenhungrigeren Methode "Fake-Pubkeys" gleichgestellt (und sogar minimal günstiger, was die Fees angeht)
- Protokolle wie Citrea, die heute Fake-Pubkeys nutzen, könnten auf eine weniger node-belastende Methode umschwenken
- Die Standardness-Regeln werden schon heute von Minern umgangen, wie man an der berühmten 3,9 MB Grafikdatei sah, die Anfang 2023 in der Blockchain auftauchte.
- Wenn die Nodes alle unterschiedliche Konfigurationen haben, wie viele Daten sie erlauben, wird es schwieriger die Fees zu berechnen.
- Es scheint auch einen Effizienzvorteil bei der Block-Verbreitung im Netzwerk zu geben (den habe ich noch nicht ganz verstanden).
- Für Spam wie Ordinals gibt es nur einen begrenzten Markt. Der würde durch die Änderung nicht vergrößert. Zumindest ein Teil davon könnte auf OP_RETURN umschwenken, was auch (etwas) weniger schädlich wäre. [1]

Contra Änderung:

- Die Taproot-Methode ist auch nach der Änderung noch günstiger ist als OP_RETURN. Daher kann bezweifelt werden, dass die Spammer einfach so umschwenken.
- Die Änderung suggeriert, dass es laut den Bitcoin-Regeln "okay" sei, Daten in der Blockchain zu speichern. Spammer könnten sich "bestätigt" sehen und noch mehr Spam einstellen.
- Die Taproot-Methode hat weniger Auswirkungen auf die Transaktionsgebühren (wegen dem Witness-Discount), ein Umschwenken auf OP_RETURN würde also die Fees womöglich noch erhöhen. (Gegenargument: Die Taproot-Methode belastet die Nodes etwas mehr, siehe unten.)
- Man könnte eine Bilddatei von maximal ca. 100 kB am Stück in einem einzelnen Output ohne Tricks speichern. Das könnte auch so verstanden werden, dass Bilder usw. "geduldet" sind.

Eigene Meinung:

- Die Original-PR gefällt mir nicht so gut, ich finde die Nodes sollten die Option behalten, die Datenmenge hinter OP_RETURN in ihren eigenen Mempools zu regeln. Sonst könnten viele z.B. zu Bitcoin Knots überlaufen. Mir würde aber auch eine einfache Erhöhung des Limits auf ca. 1 kB reichen, damit wären zumindest größere Bilddateien, Videos u.ä. zumindest per OP_RETURN weiterhin nicht so einfach möglich.
- Die "Korruptionsvorwürfe" halte ich für irrelevant. Es gibt gute Gründe für Änderungen in diesem Bereich, da die Fake-Pubkeys wirklich Schaden für immer und ewig anrichten.

---

Ja, filtern geht nicht, da steht die Zensurresistenz von Bitcoin entgegen, und das ist auch gut so, sonst könnte man ja auch andere Dinge einfacher filtern (z.B. Adressen) und Bitcoin wäre nicht besser als Fiat in der Hinsicht. Und genau wie du sagst ist die Idee immer, dass Spam ökonomisch unterbunden wird.

Ich denke mit "Mempool-Regeln" meinst du die Standardness-Regeln. Die sind in der Tat von jedem Node weiterhin so konfigurierbar wie er will. Und nur um die geht es hier ja, nicht um Konsensregeln. Es werden nur von der Implementation "Core" eben bestimmte Konfigurationen, in diesem Fall die Limitierung der Datenmenge hinter OP_RETURN, nicht mehr unterstützt. Eventuell besteht deshalb wenn die PR durchkommt die Gefahr (?), dass mehr Nodes Knots und andere Alternativimplementierungen nutzen und die Diskussion um das Protokoll komplizierter wird.

---

[1] Hier auch eine kurze Erklärung: Die Taproot-Methode, die durch Ordinals genutzt wird, speichert die Daten im Feld für Signaturen, dem "Witness". Diese Daten selbst belasten das UTXO-Set nicht. Die Methode kann aber zu Dust-Outputs führen, wenn bei einer Transaktion nicht zeitgleich eine bestimmte Anzahl von Coins (über dem Dust-Limit) transferiert wird. Diese Dust-Outputs bleiben auch womöglich für immer und ewig im UTXO-Set. Kurz gesagt: wenn man die Methode falsch anwendet, belastet sie das UTXO-Set ebenfalls.

interessant finde ich die folgende statistik bzw. webseite.
man erkennt sehr deutlich den sehr großen anstieg der Bitcoin knots (höchtwahrscheinlich nach dem der pull request von Peter Todd eingereicht wurde) der momentan bei über 1600 knots nodes liegt
davor liefen die knots 'unterm radar' und starteten (was ich auch nicht wusste) schon am 01 märz 2016 ihre aktivität (damals mit 2 nodes)
das momentane verhältniss liegt nun bei 20315 Bitcoin core nodes gegenüber 1674 Bitcoin knots nodes: https://coin.dance/nodes


https://coin.dance/nodes/knots

das drama geht weiter...
denn der ursprüngliche und viel diskutierte vorschlag zur abschaffung der OP_RETURN limits wurde geschlossen.
stattdessen verlagert sich die debatte nun auf einen alternativen und etwas moderateren pull request mit der nr. #32406. dieser wurde bereits wenige tage nach dem Peter Todd's vorschlag vom entwickler Greg Sanders (alias instagibbs) mit folgenden ansätzen eingereicht:

• 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.

mehr infos dazu:
https://github.com/bitcoin/bitcoin/pull/32406#issue-3036315607
https://www.blocktrainer.de/blog/op-return-aenderung-gescheitert-neuer-vorschlag-vorgestellt

Es gibt Neuigkeiten:

Die Variante der Pull Request, bei der für OP_RETURN das Standard-Limit abgeschafft wird, aber datacarriersize erhalten bleibt, d.h. die Nodes weiter entscheiden können ob sie per Kommandozeilenargument die Datenmenge für diese Funktion begrenzen, wurde gestern in den Bitcoin-Code integriert.

Ich bin mal gespannt ob das zu weiterem Knots-Wachstum führt. Ich selbst finde die Änderung wie gesagt in Ordnung, aber viele eben nicht. Jetzt ist die Frage, ob das nur "ein paar laute User" sind, oder wirklich ein großer Teil der Full-Node-Betreiber.

Die Möglichkeit das zu konfigurieren scheint aber auf "deprecated" gestellt worden zu sein, es kann also gut sein dass das Feature in einer der nächsten Bitcoin-Versionen ganz rausfällt.