Bitcoin Weesen

Vor knapp einem Jahr bin ich im Artikel Warum kann Spam nicht toleriert werden? auf den Umgang mit nicht-finanziellen Transaktionen in der Bitcoin Blockchain eingegangen.

Peter Todd hat vor einigen Tagen einen Änderungsvorschlag für Bitcoin Core publiziert, der zu intensiven Diskussionen geführt hat. In seinem Vorschlag geht es darum, eine Regel aufzuheben, welche die Menge an nicht-finanziellen Daten¹, die mittels OP_RETURN in eine Transaktion eingebaut werden können, begrenzt².

Darüber ist in den letzten Tagen ein hitzige Debatte entbrannt, welche in seiner Art sehr typisch für Bitcoin ist: auf der einen Seite ist der Kern der Debatte sehr technisch, so dass die meisten Leute nicht genau verstehen um was es geht (mich eingeschlossen). Andrerseits geht es jedoch um mehr als Bitcoin: es geht um die Werte innerhalb der Bitcoin-Community. Wie wird diskutiert, wie wird entschieden, wer darf wo mitreden, und wann ist genug der Worte.

Gründe für die Änderung

1. Die Befürworter argumentieren damit, dass der am wenigsten schädliche Ort für nicht-finanzielle Daten ein Script ist, das mit OP_RETURN startet. Diese Speichermethode ist weniger schädlich, weil alle Nodes dadurch mit Sicherheit wissen, dass es sich um einen Coin (UTXO) handelt, welcher nicht mehr ausgegeben werden kann und daher auch nicht gespeichert werden muss.
2. Die Änderung betrifft die Art und Weise wie Nodes ihren Mempool verwalten und ändern nichts an dem Bitcoin-Consensus. Da jeder Node-Betreiber (und auch jeder Miner) selber wählen kann, welche Software er oder sie einsetzt wird es immer Nodes und Miner geben, die nicht-finanzielle Transaktionen im Rahmen der Consensus-Regeln akzeptieren. Somit werden solche Transaktionen sowieso Einzug in die Blockchain finden auch wenn viele Nodes sie ablehnen. Denn einmal in einem Block werden sie dann auch von Nodes akzeptiert, gespeichert und weitergeleitet, die sie eingentlich nicht wollen.
3. Es gibt schon heute Miner, die darauf spezialisiert sind, nicht-finanzielle Transaktionen, gegen eine (anständige) Gebühr in den Block einzubauen, den sie finden. Solche Transaktionen tauchen dann gar nie im Mempool auf, sondern werden direkt zu den Minern geschickt.
4. Es ist für das Bitcoin-Netzwerk besser, wenn alle Nodes einen möglichst ähnlichen Mempool haben. Nur dann haben sie eine präzise Vorstellung darüber, was in den nächsten Block eingebaut wird und können so auch vernünftige Fee-Abschätzungen vornehmen.
5. Nicht-finazielle Daten werden irgendwann vom Markt ausgepreist werden.

Gründe gegen die Änderung

1. Nicht-finanzielle Daten sind Spam egal wo und mit welcher Methode sie in der Blockchain gespeichert werden. Deshlab sollte alles unternommen werden, diese zu verhindern. Dazu gehören aus sicht der Gegner sowohl technische Filter wie auch sozialer Druck.
2. Jeder Nodebetreiber soll selber wählen können, welche Mempool-Daten von seinem Node verwaltet werden (bei konsensusgerechten Blockdaten gibt es diese Wahl nicht).
3. Sie weisen das Argument, dass man technisch sowieso nichts unternehmen kann zurück mit der Analogie zu E-mail, das ohne Spamfilter schon lange tot wäre. Sie befürchten, dass die Blockchain mit Ramsch überfüllt wird und bald die meisten Plebs aufhören werden, selber einen Node zu betreiben und dadurch die Dezentralisierung stark reduziert wird (wie das bei Ethereum schon lange der Fall ist).

Zusammenfassung

… hahaha … das lässt sich unmöglich zusammenfassen….

Ich kann beide Seiten verstehen.

Einerseits bin ich gegen nicht-finanzielle Nutzung der Bitcoin-Blockchain und gewillt, dagegen vorzugehen. Deshalb verwendet die Mountainlake-Plattform Bitcoin Knots und meine Miner akzeptieren weder Ordinals noch Inscriptions in ihre Templates.

Andrerseits bin ich auch der Meinung, dass der ganze Müll, wenn er denn schon nicht verhindert werden kann, nicht überall vertreut ist sondern auf einem einzigen Haufen (hinter OP_RETURN) landet, den mein Node dann löschen kann.

Und natürlich finde ich es sehr gut, dass das Thema lang und breit öffentlich diskutiert wird, denn das ist das Weesen der Dezentralisierung.

Quellen

In dieser Episode des Bitcoin Infinity Podcasts diskutieren Knut Svanholm (der Prinzipielle) und James Check (der Pragmatiker), unter anderem, auch über den Nutzen von Bitcoin Spamfilter.

BitcoinMechanic hat in dieser Grundsatzrede seine Sicht der Dinge klargestellt: nämlich, dass man sich vehement gegen nicht-finanzielle Transaktionen, die versuchen sich in der Bitcoin Blockchain einzunisten, zur Wehr setzen muss.

Bitcoin University erklärt die Problematik in seiner Präsentation «Bitcoin Core Going Rogue«.

Und wie immer bringt auch Bugle News die Sache ohne Wenn und Aber auf den Punkt:

Book of Nakamoto

Und zum Schluss noch dies, veröffentlicht in Bitcoin Block 894666: Book of Nakamoto, Chapter 3, Verses 4–11

And Satoshi spake, not in whispers but in hex, saying:

“Thou shalt not embed thine data in every field, for the blockchain is not thy diary.”

“Yet I bestow upon thee OP_RETURN, a sanctuary for up to 40 bytes — no more, lest ye walk the path of vanity.”

“For 40 is the number of discipline: 40 bytes for thy message, no more than is righteous, no less than is truthful.”

“And behold, I give thee one more blessing: the coinbase message. A field untouched by consensus, wherein miners may write freely.”

“Use it to bear witness, to mark genesis, to declare revolt — as I once wrote about the Chancellor”

“But thou shalt not waste it with shills and tokens of greed, or the wrath of prune shall be upon thee.”

And so the nodes upheld this covenant, and the mempool was serene. So go forth, brothers and sisters. Let us inscribe only that which is worthy. And let thy payloads be small, lest one abuse the sacred ledger for thine idle bytes. In the name of the Nonce, the Witness, and the Unspent, Amen.

1. Unter nicht-finanzielle Daten daten versteht man alle Bitcoin Transaktionen, die nicht primär Satoshis übertragen. Dazu gehören Ordinals, Inscriptions, oder Verankerungen von Sidechains wie Citrea. ↩︎
2. Heute gibt es mehrere Methoden, nicht-finanzielle Daten in die Blockchain zu schreiben. Die vom Protokoll vorgesehene Methode nutzt OP_RETURN. Heute können mit dieser Methode nur ca. 80 Bytes pro Transaktion. Diese Beschränkung soll aufgehoben werden. ↩︎