Bitcoin Core hebt OP_Return-Limit auf – und entzündet hitzige Diskussion
Geister. Bild von Quinn Dombrowsky via flickr.com. Lizenz: Creative Commons
Wird Bitcoin zum „wertlosen Altcoin“ und „nicht länger Geld“ durch eine „absolut verrückte“ Änderung? Oder tragen nur Entwickler, die sich nicht durchsetzen konnten, „ihren Frust in die sozialen Medien“, und Leute, die „offensichtlich nicht aufpassen“, blasen sich auf? Die Diskussion, die derzeit um ein geplantes Update von Bitcoin Core, des dominanten Bitcoin-Clienten, tobt, ist hitzig.
Es geht um folgendes: Der Bitcoin-Entwickler Peter Todd hat einen Vorschlag eingebracht – ein „Pull Request“ – das Limit von OP_Return vollständig aufzuheben. Das Pull Request wurde nach einer nicht unkontroversen Diskussion angenommen und wird nun fürs nächste Update eingeplant.
Manche Entwickler, wie Luke Dashjr, sind entsetzt: „Es sollte offensichtlich sein, dass das absolut verrückt ist […] Bin ich der einzige hier, der sich ernsthaft um Bitcoins Überleben sorgt?“ Jason Hughes, ein Entwickler um Bitcoin herum, stimmt Luke zu: „Das ist viel mehr als eine kleine technische Änderung […] Dieses PR einzuführen bedeutet, dass Bitcoin nicht länger eine dezentrale Währung ist. Dass Bitcoin nicht länger Geld ist. Dass Bitcoin nicht länger ein sicherer Wertspeicher ist.“ Der Vorschlag sei „nicht nur ein direkter Angriff auf Bitcoin selbst, er würde seine Natur auf die schlimmstmögliche Art untergraben.“
Andere Entwickler wie Jameson Lopp halten eher das Drama um das PR herum für einen Angriff. „Immer wieder kommt es vor, dass jemand es nicht schafft, mit seinen Argumenten in einer Diskussion um ein Bitcoin Pull Request zu überzeugen, also trägt er seinen Groll in die sozialen Medien. Dann schleichen sich viele Nicht-Core-Entwickler in die Diskussion in der naiven Vermutung, Core sei demokratisch durch eine Wahl regiert.“ Und für Core-Entwickler Matt Corallo zeigt der „Shitstrom“, der derzeit tobt, vor allem, „wer tatsächlich Ahnung hat und wer seine Information aus zehnter Hand durch diese Seite [Twitter] bekommt.“
Tatsächlich geht in dem Drama und den schrillen Tönen die technische Grundlage unter. Worum geht es genau? Was ist OP_Return – und warum will Core das Limit lösen? Welche Gefahren drohen dadurch – und gäbe es Alternativen?
80 Bytes für Daten auf der Blockchain
Der Script-Code OP_Return erlaubt es, auf eine relativ harmlose Weise Daten auf der Bitcoin-Blockchain abzulegen. Die Core-Entwickler haben dies 2014 erlaubt, nachdem es einen Trend gab, Daten über das UTXO-Set in die Blockchain zu schreiben. OP_Return hat den Vorteil, dass es das UTXO-Set nicht aufbläht und man es relativ unkompliziert von einem Node löschen kann. Dennoch haben die Core-Entwickler ein Limit von 80 Bytes verhängt, um zu verhindern, dass OP_Return allzu sehr missbraucht wird. Bitcoin soll, so die Intention von Core, Geld bleiben, anstatt eine Datenbank für alles mögliche.
Das Limit für OP_Return ist dabei keine konsensrelevante Regel. Wäre sie dies, müsste man sie durch eine Hardfork lösen. Stattdessen ist das Limit eine „Standardregel“. Nodes, die Bitcoin Core benutzen, leiten Transaktionen, die gegen die Regel verstoßen, nicht weiter, akzeptieren es aber, wenn Miner sie in einen Block bringen. Auf diese Weise konnte Core User davon abschrecken, OP_Return weithin zu missbrauchen, da Transaktionen es schwer haben, einen Miner zu erreichen, wenn die meisten Nodes sie blockieren.
Warum aber wollen sie das Limit nun aufheben? Gab es einen Sinneswandel?
„Anreize, Daten auf noch schädlichere Weise zu speichern.“
Die Core-Entwickler wollen weiterhin, dass Bitcoin nur als Geld verwendet wird. Ginge es nach ihnen, würden überhaupt keine Daten auf die Blockchain geschrieben werden. Doch die Realität ist längst eine andere. Auf der einen Seite erlaubt es Taproot in Kombination mit SegWit, bis zu vier Megabyte an Daten in Transaktionen hineinzuschreiben, und dies auf eine Weise, die prinzipiell gar nicht zu löschen ist, da die Inhalte konsensrelevant sind und Teil des UTXO-Sets werden. Auf der anderen Seite bieten manche Miner an, Transaktionen direkt entgegenzunehmen, etwa Mara Slipstream, wodurch die Standardregel der Bitcoin-Nodes einfach umgangen wird.
Das Limit für OP_Return war lange Zeit erfolgreich, in dem Sinn, dass es Token-Protokolle wie Colored Coins oder Mastercoin ausbremste und verhinderte, dass exzessiv Daten auf die Blockchain geladen werden. Mittlerweile aber hat das Limit an Wirkung verloren; es ist längst üblich, dass ein signifikanter Teil des Platzes in den Blöcken durch nicht-monetäre Daten abgegriffen wird.
Darüber hinaus gibt es von Entwicklern gewünschte Anwendungen von OP_Return, die etwas mehr Raum für Daten benötigen. Dies ist etwa die Clementine Bridge von Citrea, einem ZK-Rollup für Bitcoin – also eine weitere Layer2, die aber, anders als Lightning, mit Ethereums Smart Contracts kompatibel wäre. Solche Rollups sind eine elegante Methode, um die Limits von Lightning zu umgehen und weitere Funktionalitäten zu aktivieren, ohne die Blockchain damit selbst zu belasten.
Um aber sicher und dezentral zu funktionieren, braucht Citrea eine Art Watchtower, der in der Lage ist 144 Bytes an Daten in einer Transaktion zu versenden. „Da die OP_Return-Outputs auf 80 Byte beschränkt sind, nutzen sie zwei unausgebbare Taproot-Outputs, um die weiteren 64 Bytes an Daten unterzubringen,“ erklärt Bitcoin Core-Entwickler Antoine Poinsot, der die Diskussion in der Mailing-List angestoßen hatte, „diese Taproot-Outputs werden für immer unausgebbar sein, und jeder einzelne Node wird sie für immer in seinem UTXO-Set behalten.“
Solche Limits der Standardregeln, wie bei OP_Return, können schwere Probleme verursachen, so Poinsot weiter: „Sie verhindern nicht nur nicht, dass die Blockchain genutzt wird, um willkürliche Daten zu speichern, sondern sie setzen auch noch Anreize, die Daten auf eine schädlichere Weise zu speichern.“
„Für den Preis von ein paar Satoshi je Byte kann ein Angreifer nun den Speicher von jedem Full Node vergiften.“
Die Argumente sind an sich plausibel. Dennoch erfährt sie scharfen Widerstand. Etwa von Luke Dashjr: „Ein Bug sollte repariert werden, anstatt dass man dessen Missbrauch begrüßt. Wenn die Angreifer weiterhin Filter umgehen, können wir zurück zu einem Ansatz einer vollen Whitelist gehen. Wir erleben diese Welle der Angriffe seit über zwei Jahren, und der Schaden, der bereits angerichtet wurde, reicht aus, um zu beweisen, dass die Hands-On-Attitüde nicht angemessen ist.“
Luke sieht ein, dass es immer möglich sein wird, Filter zu umgehen und Daten auf die Blockchain zu laden. „Aber es reicht aus, Spam unwillkommen und teuer zu machen. Kein Spam-Filter muss perfekt sein. Jedes Stückchen hilft.“
Ähnlich scharf sieht es Jason Hughes: Es war bisher möglich, Daten in das UTXO-Set zu schreiben, aber es waren kleine Mengen, weshalb es erträglich war, und wenn es Missbrauch gab, fanden die Entwickler einen Weg, ihn abzustellen. „Dies funktionierte ein Jahrzehnt lang. Dann aber gab es leider einen Exploit namens ‚Inscriptions‘, der jedes Limit für willkürliche Daten sprengte … und, um die Sache noch schlimmer zu machen, die Entwickler weigerten sich, den Exploit zu finxen. Und als wäre das noch nicht schlimmer genug, bekommen die Angreifer einen 75-Prozent-Discount für die Transaktionsgebühren.“
Dies geht auf die Struktur von SegWit zurück, die ironischerweise von niemand anderem als Luke Dashjr verbrochen wurde. SegWit bemisst die Größe eines Blocks nicht mehr in Bytes, sondern kalkuliert ein „Gewicht“, in welchem die „Witness-Daten“ viel weniger zählen. Das war gut gemeint, da man die Witness-Daten im Nachhinein leicht prunen kann. Doch durch Taproot wurde es möglich, allerlei Daten – bis hin zu Videos – in die Witness-Daten zu schmuggeln.
„Mit dieser Geschichte im Hinterkopf ist es nutzlos, die Limits für OP_Return zu entfernen“, fährt Jason fort. „Solange man nicht den Inscription-Exploit abstellt, wird niemand OP_Return nutzen […] Was will man mit einem Standard, um Daten zu speichern, wenn der Exploit es vier Mal günstiger macht und vier Mal mehr Daten erlaubt?“ Daten im OP_Return-Feld gehören nicht zu den Witness-Daten, von ihnen bekommt man, selbst wenn es kein Limit mehr gibt, maximal ein Megabyte in einen Block, während die Witness-Daten in Taproot es erlauben, bis zu vier Megabyte große Blöcke zu bilden.
Darüber hinaus sind die Daten in OP_Return im Reintext, während sie in Inscriptions eher verschleiert sind. Alles, was jemand per OP_Return auf die Blockchain bringt, sagen wir, kinderpornographische Bilder oder Terroraufrufe, wird jeder Node im Reintext auf seiner Festplatte ablegen. „Für den Preis von ein paar Satoshi je Byte kann ein Angreifer nun den Speicher von jedem Full Node vergiften.“ Nicht nur speichern die Node-Betreiber verbotene Daten, „sie leiten sie an andere weiter.“
Die Geister, die man selbst geschaffen hat
Technisch gesehen könnte man diese Diskussion vermutlich noch lange weiter führen. Wie immer, wenn es nicht um Technik geht, sondern um Ziele und Politik, wird dies aber zu keiner Lösung führen. Soll man versuchen, Spam und Missbrauch so hart wie möglich zu bekämpfen – oder soll man es vielmehr versuchen, in weniger schädliche Formen zu leiten? Diese Frage ist nicht technisch, sondern ideologisch.
Darüber hinaus dürfte wie seinerzeit bei den Diskussionen zur Blocksize gelten, was Samson Mow ausdrückt: „Bitcoin Core ist keine Demokratie, die durch Abstimmungen regiert wird. Entscheidungen basieren auf einem groben Konsens. Und jedermann kann sehen, dass es keinen Konsens gibt, um die Limits von OP_Return aufzuheben. Das nun durchzudrücken ist ein Weg auf einem schlüpfrigen Pfad.“
Bitcoin-Entwickler wie Antoine Poinsot wollen das aber nicht gelten lassen. Sie halten die Diskonsens für fabriziert und böswillig. „Viele haben die Gelegenheit genutzt, die ihnen mein Vorschlag bot, um sich auf Twitter großzumachen. Sie missbrauchen leichtgläubige Leute, indem sie wilde Behauptungen darüber machen, dass OP_Return-Outputs eine existenzielle Gefahr für Bitcoin sind […] Die Fähigkeit einer parasitären Gruppe, dieses Level an Aufmerksamkeit zu bekommen, sagt sehr viel über die Werte in unserer Community aus. Ich hoffe, Bitcoiner beginnen, kritischer zu denken, und hören auf, sich alle 6 Monate der neuesten Verschwörungstheorie zu verschreiben.“
Kurz gesagt: Bitcoin Core wird von den Geistern verfolgt, die sie selbst geschaffen haben. Das Beschwören eines Konsens, die Ablehnung von nicht-monetären Daten, der SegWit-Rabatt für Witness-Daten, sogar Taproot, das Schnorr-Signaturen einführt – all das sind Produkte einer Ideologie, die damals aufgebaut wurde, um eine Erhöhung der Blocksize zu verhindern. Nun erkennen die Core-Entwickler, dass sie nicht über den Regeln stehen, die sie selbst geschaffen haben.
Entdecke mehr von BitcoinBlog.de - das Blog für Bitcoin und andere virtuelle Währungen
Melde dich für ein Abonnement an, um die neuesten Beiträge per E-Mail zu erhalten.
Ist ja fast wie in alten Zeiten … ich brauch neues Popcorn.
„Der Bitcoin ist tot, es lebe der Bitcoin“
… währenddessen gibts bei BSV grad >100 Millionen Transaktionen/24h auf OP_Return. Da soll noch einer sagen, Bitocin skaliert nicht.
https://whatsonchain.com/stats
Dies ist ein schönes Beispiel dafür, dass (wieder) Entwickler entscheiden, wie dieses ökonomische System gestaltet wird, welche Eigenschaften „das Geld“ hat. Wenn nicht einige Entwickler draufschauen, merken 90% der Nutzer nicht, was passiert.
Durch die enorme Marktdominanz ist der Anbieter Core für Bitcoinsoftware ein zentraler und bestimmender Akteur, auch wenn sich die Leute informal in dedizierten Chaträumen/Maillinglisten synchronisieren. (Soviel zum Thema Dezentralisierung 😉 ). Die Meinung der Nutzer spielt i.d.R. keine Rolle.
Zum Text: Wer bestimmt, was eine konsensrelevante Regel ist? Bedeutet konsensrelevant, dass Blockerzeuger abstimmen, ob ein Block valide ist oder nicht, dann doch, wenn dieser eine Transaktion enthält, die aus Sicht des Miners ungültig ist. Oder ist in diesem Fall die Transaktion für Miner gültig obwohl sie den größeren Wert für ungültig halten? Im Text steht allerdings auch, Miner akzeptierten Blöcke mit Transaktionen, die sie selber nicht akzeptieren? Klingt irgendwie strange. 😉 Liegt es an der Einstufung als Policy? Der Code wurde mW in diesem Kontext auch in den Abschnitt Policies *bewegt*.
Ich lese zum ersten mal etwas von der Standardregel der Bitcoin-Nodes. Welche ist das? Transaktionen können an das Netzwerk und/oder an Miner direkt gegeben werden. Blockerzeuger haben lt Whitepaper die Aufgabe, Transaktionen und Blöcke weiter zu propagieren. Ich sehe das Problem gerade nicht.
Das Limit für OP_RETURN war tatsächlich so erfolgreich, dass dadurch Ethereum (+1000e andere) entstand. /i
Als Befürworter von BSV habe ich natürlich kein Problem mit der Erhöhung der OP_RETURN Datengröße. BSV hatte da schon 2019 einen 17kb Wert (und lebt immer noch). Natürlich gönne ich dem BTC Ökosystem das Narrativ vom digitalem Gold und den nur sehr konservativen Änderungen. Wer keine Limits außer das Protokoll möchte, ist weiterhin gerne in der BSV Welt gesehen ;-).
( Aber auchin der BSV Welt dort gibt es die Unterscheidung zwischen Protokollregeln und Policies (deren Werte wie maximal akzeptierte Blockgröße, maximale Script-Size, etc die unter den Blockerzeugern ausgehandelt werden)) .
Amüsante Notize am Rande: Die Aussage von Lopp „Then you have been deceived by false narratives.“ scheint mir glatt von einem Bigblocker 2017 übernommen geworden zu sein 😉 .
(https://x.com/lopp/status/1917924032487260192)
🙂
@Wolfgang
Meinst du wirklich, du solltest dir ein Urteil über die Entwickler erlauben, wenn dein anschließender Text völlige Ahnungslosigkeit über die Funktionsweise des Systems verrät?
Christoph, hast du die Niederlage deiner Position im Blocksizestrei noch immer nicht verwunden? Das ist doch nun wirklich ein ganz anderes Thema. Was soll der Seitenhieb? Und welche Entscheidung die richtige damals war, sich zu einem beliebigen Altcoin zu machen, indem man das Gesetz, den Code, bricht. Oder sich als Fels in der Brandung zu positionieren, der die Gesetze nicht alle Nase lang wegen einer neuen Mode ändert. Das hat der Markt doch wohl inzwischen eindeutig bewiesen.
@Kai
Kannst du bitte genauer auf diese „Ahnungslosigkeit über die Funktionsweise des Systems“ von Wolfgang eingehen. Ich möchte gern verstehen, was du meinst. Und seit wann ist Code ein Gesetz? Das ist eine ziemlich naive Sichtweise.
> Christoph, hast du die Niederlage deiner Position im Blocksizestrei noch immer nicht verwunden? Das ist doch nun wirklich ein ganz anderes Thema. Was soll der Seitenhieb?
Mich kümmert das Thema der Blocksize schon lange nicht mehr. Es ist, wie es ist. Meine Bemerkung ging eben darum, dass damals gewisse ideologische Mauern gesetzt wurden, gegen die nun die Core-Entwickler selbst stoßen. Daneben liegt schon eine gewisse Ironie darin, dass SegWit eingeführt wurde, um die Nutzung von Bitcoin auf monetäre Transaktionen zu begrenzen, sich nun mit Taproot aber dahin rächt, dass nicht-monetäre Transaktionen einen Rabatt erhalten, während eben der Entwickler, der diese Struktur von SegWit erfunden hat, dies nun am schärfsten beklagt.
@Kai
1) Vielleicht verrät mein Text eher Schwierigkeiten, mich ausreichend gut mit einer Prise Humor, Augenzwinkern verständlich zu machen, gelegentlich Kritik zu äußern und auch in einen Austausch einzusteigen, der mir bei Reflektion über mein Wissen hilft. 😉 Ich kann Aussagen schwer so auf den Punkt bringen, dass sie richtig sind und gleichzeitig richtig verstanden werden. Und perfekt bin ich schon lange nicht. Diese Antwort ist sicher keine Ausnahme. 🙂
2) Ich habe nicht geurteilt. Ich wies darauf hin, dass Entwickler gestalten und entscheiden. Nicht immer ist es bedeutsam, nicht immer bekommt die Außenwelt etwas davon mit. Außenstehende können insbesondere oft die Auswirkungen der Änderungen nicht komplett verstehen. Dies widerspricht sich mit dem verbreiteten Narrativ, dass die „Community“ entscheiden würde oder dass niemand Kontrolle hätte. Ich kritisiere seit langem, dass man diesem Narrativ zu wenig skeptisch gegenüber ist. Und hier haben wir ein wieder Beispiel, wo aber immerhin Entwickler auch „Außenstehende“ aufgerüttelt haben. (Entwickler übersehen allerdings ebenfalls manche Folgen ihrer Handlungen.)
Randnotiz: Das Buch „Hijacking Bitcoin“ wäre auch eine empfehlenswerte Lektüre, wenn auch Ver einiges anders sieht als ich. 🙂
( @Hannes Ich nehme an, die Einschätzung bezieht sich darauf, dass ich mir die Bezeichnung Standard-Regeln der Miner nicht bekannt war, oder dass ich es kurios finde, wenn Miner Blöcke akzeptieren (müssen), obwohl sie die darin enthaltenen (gültigen) Transaktionen selbst nicht akzeptiert hätten. Leider lässt er mich in meiner Blase der Ahnungslosigkeit 😉
)
@Kai
3) Der Bitcoinblog ist eine der wenigen deutschen Quellen, die ich zum Thema Bitcoin & Co gelegentlich konsumiere. „Standard“ verbinde ich in erster Linie gerade in technischen Systemen mit zu befolgenden Spezifikationen grundlegender Eigenschaften, also ein Standard wie das Transmission Control Protocol/Internet Protocol (TCP/IP) ist z.B.
Im Kontext von Minern war für mich dieser Sprachgebrauch zunächst irritierend. Ich kannte und nutzte stattdessen die Bezeichnung Policies. (Die Änderung betrifft im Übrigen u.a. auch die Datei „policy.*“ ). Besonders irritierend liest es sich, wenn es dann Entwickler sind, die über einen „Miner-Standard“ entscheiden. (Aber auch im Sinne von Policies sollten es die Miner sein, die sie anpassen, sie z.B. untereinander aushandeln. Andererseits weiß ich nicht, ob nicht hinter den Kulissen Miner mit den Entwicklern gesprochen haben.) In der Tat schaue ich mir nicht ständig den Code an, der von Core Devs geschrieben wird. Aber ich sollte optimalerweise erst gegenchecken, ob ich was falsch verstanden habe, bevor ich hier antworte. Andererseits ist das hier kein wissenschaftliches Forum, eine gewisse Fehlertoleranz sollten wir uns gegenseitig zugestehen 🙂
4) In „meiner“ Welt ist es durchaus üblich, dass Anforderungen aus Idee, Zielen via Design, Spezifikation dann ihren Weg in die Implementierung finden, gern auch verzahnt in Iterationen. Diese sind nicht immer klar oder explizit. Änderungen sollten ebenfalls diesen Weg gehen. Es war einer der Fehler von Satoshi, dass er damals nie eine explizite Spezifikation erstellt hat, die man dann später mit Versionen abgleichbar als Grundlage hätte verwenden können.
Letztlich sollte Software strukturell möglichst nahe an der Fachlichkeit ausgerichtet sein, wenn sinnvoll/möglich/wichtig. Leider versteht man Bitcoin immer mehr als ein reines Softwareprodukt, bei dem das System durch die Software definiert wird. Aber auch Satoshi hat vorher das System entworfen.
5) Es wirkt auf mich manchmal so, dass manche den Bitcoin-Entwicklern gegenüber regelrecht Ehrfurcht entwickeln. Respekt für Arbeit und Energie, ja. Es sind Menschen mit Kompetenzen. Wie war das? Don’t trust, verify? 😉 Kritische Betrachtung ist sogar angebracht. Entwickler sind oft sehr intelligent und kreativ. Sie neigen dazu, Software auch dann weiterzuentwickeln, wenn es keine Notwendigkeit dafür gibt. Ich kenne da Beispiele, wo exzellente Entwickler eine Verbesserung an Software vorgenommen haben, die der Auftraggeber sofort wieder weghaben wollte. Ja, sogar eines, wo die Entfernung eines offensichtlichen Bugs zu großen Ärger und Kosten geführt hat, weil der Fehler in Prozessen auf Kundenseite eine Geschäftsschuld war und demzufolge in der Software abgebildet zu sein hatte, damit externe Systeme weiter funktionieren. Ich zweifle nicht daran, dass Entwickler verstehen, was im System wie funktioniert. Es müsste eher danach gefragt werden, warum etwas drin/nicht drin ist, oder welche Konsequenzen eine Änderung haben könnte, auf fachlicher Ebene.
Übrigens können auch Änderungen, die nicht die „Konsensregeln“ direkt betreffen, Effekte haben. Kann alles positiv sein.
Wer aber bestimmt, wie das System funktioniert/zu funktionieren hat?
Das war doch mein Ausgangspunkt 😉
6) Bzgl Deines Absatzes an Christoph wäre ich für eine Klarstellung dankbar.
Das klingt, als würdest Du da auf BCH/BSV verweisen. Aber es war doch Core, der den Code signifikant geändert, neue Blockgröße eingeführt (4MB), Transaktionen mit neuen Format eingeführt (Separate Witness), Blockstruktur geändert hat (2-teiliger Block, mit unterschiedlichen Marktanreizen, wenn man die Idee des Blockplatz-Marktes mal annimmt).
Ich denke, Christoph geht recht pragmatisch und gelassen mit der Entwicklung (und mit Kommentaren wie meinen) um. Und er hat schon recht seiner Aussage, die er in der Antwort super auf den Punkt bringt. Nebenbei ist das „Ärgernis der Ordinals“ auch ein weiteres Beispiel für unerwartete Konsequenzen von Änderungen.