Entwickler hebt erhebliche Risiken im vorgeschlagenen Bitcoin Reduced Data Soft Fork hervor

Überprüfung der Transaktionsdaten zeigt, dass RDTS wichtige Bitcoin-Anwendungsfälle blockieren könnte

Ein neuer Softfork-Vorschlag, der darauf abzielt, übermäßige Daten Speicherung auf der Bitcoin-Blockchain einzudämmen, stößt in letzter Zeit auf scharfe Kritik. Am Mittwoch veröffentlichte der unabhängige Analyst und Mempool.space-Entwickler Mononaut eine Einschätzung, die den möglichen Kollateralschaden skizziert, den das Regelwerk verursachen könnte.

Der als Reduced Data Temporary Softfork (RDTS) bekannte Vorschlag führt eine Reihe von Konsensbeschränkungen ein, die darauf abzielen, datenintensive Transaktionen zu reduzieren – ein Unterfangen, das Entwickler als notwendig erachten nach dem Bitcoin Core v30 Update, das die Begrenzungen von OP_RETURN-Daten entfernt hat.

RDTS würde für etwa ein Jahr gelten, falls aktiviert, und scriptPubKeys auf 34 Bytes beschränken, OP_RETURN-Ausgaben auf 83 Bytes begrenzen, Taproot-Kontrollblöcke einschränken, undefinierte Zeugenversionen verbieten und ganze Kategorien von Tapscript-Logik deaktivieren. Befürworter des BIP argumentieren, die Maßnahmen wirken als Notbremse gegen willkürliche Datenuploads, die Betreiber von Knoten rechtlich gefährden könnten, wenn illegales Material in die Kette eingebettet wird.

Mononauts Beurteilung quantifiziert jedoch die praktischen Auswirkungen dieser Beschränkungen, indem er die historische Blockchain-Aktivität überprüft, um zu sehen, welche realen Transaktionen die vorgeschlagenen Regeln verletzt hätten. Seine Erkenntnisse deuten auf erhebliche Störungen hin. Allein unter dem scriptPubKey-Größenlimit wären alle Pay-to-Public-Key (P2PK)- und Multisig (P2MS)-Ausgaben ungültig. Diese Einschränkung betrifft auch eine kleine Anzahl von nicht standardisierten Ausgaben in vergangenen Transaktionen.

Eine der umfassenderen Regeln – das Ungültigmachen von OP_PUSHDATA-Operationen mit Nutzdaten über 256 Bytes – würde keine Inskriptionsumschläge betreffen, vorausgesetzt, dass nur ausgeführte Pushes qualifizieren. Mononaut betonte jedoch, dass undefinierte Zeugenversionen mehr als 54.000 historische Transaktionen betreffen würden, von denen viele unkonventionelle Ausgaben verwendeten, um OP_RETURN-Datenbeschränkungen zu umgehen. Da die Längen der Zeugenversionen in BIPs 141 und 341 streng definiert sind, würde der Vorschlag, wie geschrieben, sogar einige gültige moderne Formate wie P2A-Anker blockieren.

Lesen Sie auch: Bitcoin Core-Entwickler fügen kontroverse Richtlinienänderungen zusammen: Steht eine Abspaltung bevor?

Mononaut erklärte, dass RDTS auch Zeugenstapel mit einem Taproot-Anhang ungültig macht. Obwohl selten, merkt der Mempool.space-Entwickler an, dass mindestens 11 Transaktionen einen Anhang für datenintensive Zwecke verwendet haben. Eine bedeutendere Kategorie, so betonte Mononaut, sind große Taproot-Kontrollblöcke: Etwa 32.000 vergangene Ausgaben enthalten Kontrollblöcke mit einer Tiefe von über 100, die oft zum Einbetten von Daten verwendet werden, aber auch einige nicht datenbezogene Experimente basieren auf kleineren, legitimen Konfigurationen, die deaktiviert würden. Eine aktive Adresse gibt konsequent bei einer Kontrollblocktiefe von 11 aus, die unter RDTS abgelehnt würde.

Die strengsten Punkte des Vorschlags – das Verbot von OP_SUCCESS* und jeglicher Tapscript-Ausführung von OP_IF oder OP_NOTIF – gehen weit über Inskriptionsumschläge hinaus. Mononaut hebt zwei historische OP_SUCCESS-Transaktionen hervor, darunter Buraks transaktionsbrechende Lightning-Transaktion, und etwa 70 nicht-Inspektions-OP_IF-basierte Taproot-Ausgaben. Einige davon sind finanzielle Primitive, darunter abnehmende Multisig-Vorlagen und Hash-Time-Locked-Contract (HTLC)-Designs. Einige stammen von Wallets, die absichtlich ihren Schlüsselpfad deaktiviert haben, sodass das Ausgeben über den Skriptpfad der einzige Weg ist, um Gelder zu bewegen.

RDTS-Befürworter haben argumentiert, dass Benutzer mit betroffenen Skripten auf das Ausgeben über Schlüsselpfade zurückgreifen könnten. Doch Mononauts Daten widerlegen diese Annahme direkt: Etwa 560.000 historische Taproot-Ausgaben stammen von Ausgaben, deren Schlüsselpfad nachweislich deaktiviert war, was OP_IF und ähnliche Funktionen als essentiell statt optional macht.

Unterstützer des temporären Softforks behaupten, dass RDTS eine kurzfristige Schutzmaßnahme sei, die dazu dient, Bitcoins Geldnutzwert zu erhalten, rechtliche Gefahren zu vermeiden und die Belastung der Knoten durch die Begrenzung der Datenspeicherung zu verringern. Kritiker erwidern, dass umfassende Beschränkungen des Tapscript-Verhaltens das Risiko de facto Zensur einführen, gültige Transaktionstypen deaktivieren und bestehende Anwendungen unterbrechen.

Die Debatte spiegelt frühere Streitigkeiten über inskriptionsbedingtes Datenwachstum wider und spiegelt tiefere Meinungsverschiedenheiten darüber wider, ob Bitcoin strikt monetär bleiben sollte oder weiterhin experimentelle Anwendungen beherbergen sollte. Da der Vorschlag noch im Entwurfstadium ist, wird die Diskussion unter Entwicklern, Forschern und Teilnehmern des Ökosystems fortgesetzt.

FAQ ❓

• Was ist RDTS?
  Ein temporärer Softfork-Vorschlag, der mehrere Bitcoin-Skript- und Datenfunktionen einschränkt.
• Warum wird RDTS diskutiert?
  Befürworter wollen Datenmissbrauch eindämmen, während Kritiker sagen, dass es gültige Transaktionen deaktiviert.
• Was hat Mononaut herausgefunden?
  Seine Analyse zeigt, dass viele historische Transaktionen unter RDTS-Regeln fehlschlagen würden.
• Wie lange würde RDTS dauern?
  Der Vorschlag sieht ein einjähriges Aktivierungsfenster vor, falls er angenommen wird.