Kann man die BRC-20-Token stoppen, weil sie die Blockchain verstopfen?

Die Flut der BRC-20-Token beschäftigt viele Bitcoin-User – und auch die Entwickler. Sie diskutieren daher, ob und wie man einschreiten kann, um den „Spam“ zu unterbinden. Aber die Optionen sind nicht besonders rosig …

Natürlich kann man es so oder so sehen. Die einen sehen die Flut der BRC-20-Token als Angriff, der es erschwert, Bitcoins zu benutzen. Die anderen sehen darin die Rettung von Bitcoin, indem die Token den Minern neue Einnahmen durch Gebühren erschließen.

Man kann es so oder so sehen, aber wenn man mal annimmt, dass es ein Angriff ist, ein DoS- oder Spamangriff: Kann man es stoppen? Wenn ja: Wie – und zu welchen Preis?

Damit sind wir mitten drin in einer Diskussion, die mit einiger Verspätung in der Mailing-List der Bitcoin-Entwickler tobt.

Ali Sherief eröffnete die Debatte mit einer klaren Ansage: Die „wertlosen Token […] gefährden die flüssige und normale Nutzung des Bitcoin-Netzwerks“ als dezentrale Währung. Wenn das Volumen in den nächsten Wochen nicht sinke, fragt Ali – „sollen wir dann handeln?“

Parallel dazu stellte jemand auf der Stackexchange-Seite von Bitcoin dieselbe Frage: Sind die BRC-20-Transfers ein DoS-Angriff auf Bitcoin? Und was kann man machen, um ihn zu stoppen?

Nun – was kann man tun? Welche Optionen gibt es? Und sind sie überhaupt valide?

Konsens und Politik

Das Bitcoin-Urgestein Luke Dashjr, seit langem bekannt als Freund der Zensur von Spam, stimmt sofort zu: Man hätte schon vor Monaten handeln sollten. Bitcoin Core filtere Spam vom ersten Tag an, es war ein Fehler, die Spamfilter nicht auf Taproot auszudehnen. Er plädiert dafür, dass die Nodes BRC-20-Transfers als Spam zurückweisen.

Ali schlägt in seiner Eröffnung zwei Methoden vor. Man könnte:

– die Lücken in Taproot schließen, die die Inscriptions ermöglicht haben, oder
– eine Art Zensur bei auf der Ebene der Nodes einführen, indem man ihnen die Option gibt, alle nicht-standard Taproot-Transkationen zu löschen. Also der Spamfilter von Luke.

Michael Folkson kategorisiert diese beiden Methoden: „Wir haben zwei theoretische Optionen: Eine Änderung des Konsens und eine der Policy“. Eine Konsens-Änderung würde es Minern nicht länger erlauben, bestimmte Transaktionen in einen Block zu packen, beispielsweise die Arten von Taproot-Transaktionen, wie sie die BRC-20-Token verwenden. Das wäre die erste Methode von Ali. Es würde eine Softfork verlangen, welcher nur die Miner zustimmen müssten. Wenn sie glückt, wäre der Spuk sofort vorbei, da kein BRC-20-Transfer mehr bestätigt würde.

Die Änderung der Policy dagegen würde von den Nodes ausgehen und den Konsens nicht berühren: Die Nodes könnten die Option haben, bestimmte Transaktionen zu blockieren. BRC-20-Transfers wären weiterhin möglich, würden aber erschwert. Diese Methode würde vermutlich länger dauern, bis sie Wirkung zeigt, und selbst dann wohl weniger durchgreifend wirken.

Warum es so schwierig ist, BRC-20-Token zu zensieren

Aber geht das überhaupt? Kann man die Transaktionen, die BRC-20-Token verwenden, überhaupt blocken?

Grundsätzlich ist das schwierig. Denn Taproot wurde ja eben genau dafür entwickele, solche Eingriffe zu verhindert: Taproot integriert einen Hashbaum in jede Art von Transaktion; die Hashes in den Blättern des Baumes definieren die verschiedenen validen Möglichkeiten, einen Output auszugeben. Sie liegen zunächst nur als Hash vor und werden erst enthüllt, wenn der Output auch ausgegeben wird. Das „Setup unter der Haube“ einer Transaktion bleibe im Dunkeln, erklärte uns Bitcoin-Core-Entwickler Mark Erhardt: „Ob es eine normale Adresse ist, ein Lightning-Channel oder ein Multisig-Setup, ist nicht mehr zu sehen.“ Und, möchte man nun ergänzen: Ob es ein BRC-20-Transfer ist.

Und wie bitte sehr soll man etwas unterbinden, das man nicht identifizieren kann?

Man könnte freilich Blacklists schreiben, sobald ein bestimmtes BRC-20-Token sich enthüllt hat. Das könnte funktionieren, würde aber einen sehr gefährlichen Kurs einschlagen: man würde regelmäßig aktualisierte Blacklists umsetzen. Das kommt Zensur so nahe, und benötigt so sehr zentale Parteien, dass es niemand ernsthaft diskutiert.

Eine andere Option wäre es, ein Limit für die Daten im Hashbaum zu setzen bzw. ein Limit für die Geheimnisse, die man enthüllt, um die als Hash gespeicherte Bedingung einzulösen. Das könnte eine patente Methode sein, um zu verhindern, dass jemand über die Ordinal Inscriptions hochauflösende Bilder auf der Blockchain ablegt. Aber es würde BRC-20-Token kaum berühren, da diese relativ wenige Daten brauchen. Ein Datenlimit, das hier greift, würde auch viele interessante Multisig-Konstruktionen mit abschaffen, womöglich sogar Lightning-Operation.

Dennoch gibt es zahlreiche Ansätze, um den Token-Transfers dennoch Herr zu werden, ob auf der Ebene der Miner oder der Nodes: Man könnte den Script-Befehl „FALSE IF“ verbieten, auf dem die Inscriptions basieren. Oder man könnte Transaktionen verbieten, deren Gebühren den Output übersteigen, da dies ja nur bei Transaktionen Sinn ergibt, die nicht Bitcoin, sondern etwas anderes überweisen.

Keine Medizin ohne Nebenwirkung

Allerdings zeigen sich bei allen diskutierten Optionen Nebenwirkungen. Verbietet man Transaktionen, bei denen die Gebühren über dem Output liegen, verhindert man auch, dass jemand während einer Gebührenspitze Lightning Channels schließt. Das wiederum würde Tor und Tür für Betrug öffnet. Wenn man dagegen den einen Script-Befehl verbietet, könnten die Inscriptions einfach einen anderen verwenden, womit man in einem endlosen Spiel des Vor und Zurücks, der Aktion und Reaktion wäre.

Ohnehin könnte es zwecklos sein, es nur zu versuchen, meint Peter Todd. Eine „Policy-Änderung“ würde daran scheitern, dass die Miner mit den Inscriptions Geld verdienen und sie daher auch mit eigenen Nodes propagieren könnten. Auch andere User, die Inscriptions mögen, würden Nodes laufen lassen, die keine Filter anwenden. Die Policy würde ins Leere laufen; ein Teil des Netzwerks würde zwar die Inscriptions blocken, solange sie unbestätigt sind, aber sie kurz darauf in den Blöcken zwingend herunterladen.

Aber auch eine Zensur durch die Miner würde das Problem nicht wirklich lösen. Selbst wenn man Token durch Taproot verhindert, auf welche Weise auch immer, könnte man BRC-20 auch mit OP_Return und jeder beliebigen anderen Methdoe abwickeln, Daten auf der Blockchain abzulegen.

Auch Michael Folkson sieht es ähnlich. „Ich denke nicht, dass man etwas tun kann oder sollte.“ Zu dieser Feststellung sei bereits Andrew Poelstra im Januar gekommen, als man in der Mailing-List ein Limit für die Ordinals Inscription diskutierte.

Gibt es eine perfekte Koexistenz?

Und ohnehin, meint ein Entwickler namens Jaroslaw, geht die Diskussion am Thema vorbei: Nicht die Spam-Transaktionen – also die BRC-20-Token — sind das Problem, sondern dass sie normale Transaktionen so teuer machen; die BRC-20-Transaktionen derzeit sind sogar die Lösung für ein Problem, über das die Entwickler ungern reden: die langfristige Finanzierung der Sicherheit des Netzwerks.

Auf Stackexchange bringt Aleksandr Kwaskoff eine Variante ins Spiel, die dem vielleicht am ehesten gerecht wird: Wenn man einmal die Abwärtskompatibilität und andere Konsequenzen ausklammere, dann wäre es möglich, „nur noch 10 Prozent der Blöcke für Nicht-Standard-Transaktionen zu reservieren“. In dem Fall würden die Inscriptions und Token mit hohen Gebühren um einen kleinen Teil der Blöcke konkurrieren, was den Minern schöne Einnahmen beschert, während normale User nicht betroffen sind. Alternativ, so Kwaskoff, könne man auch etwas einführen, dass Ordinals-Transaktionen sehr viel teurer macht und sie womöglich auf Lightning oder ein anderes Netzwerk treibt.

Das klingt nach einer perfekten Lösung. So wie SegWit einen Rabatt für die Witness-Daten eingeführt hat, um Anreize für eine langfristig schonende Nutzung von Bitcoin zu setzen, könnte man eine Verteuerung für die Witness-Daten der BRC-20-Transfers einführen, um den Minern neue Profite zu erhalten, ohne die User dabei zu sehr einzuschränken. Falls das möglich ist.

Solche Optionen verlangen vermutlich eine Hardfork und die etwas zentralplanerische Entscheidung, wie viel Prozent in den Blöcken angemessen für andere Transaktionen sind. Und welche anderen Arten von Transaktionen betrifft das auch noch? Kann man nach Taproot überhaupt noch von Standardtransaktionen sprechen, da das Upgrade ja explizit den Zweck hatte, solche Unterschiede einzustampfen?

Es ist also schwierig. Selbst wenn die Entwickler sich dafür entscheiden, hart gegen die BRC-20-Token vorzugehen, sind die Erfolgsaussichten gering, dass sie sich auf ein Vorgehen einigen.