Der "Reduced Data Temporary Softfork" BIP schlägt vor, vorübergehend verschiedene Bitcoin-Funktionen im Konsens zu deaktivieren. Ich habe die Blockchain untersucht, um die potenziellen Auswirkungen zu quantifizieren, indem ich historische Transaktionen identifiziert habe, die gegen jede dieser Regeln verstoßen. 🧵↓

Regel #1: "Neue AusgabescriptPubKeys, die 34 Bytes überschreiten, sind ungültig, es sei denn, der erste Opcode ist OP_RETURN, in diesem Fall sind bis zu 83 Bytes gültig." Dies betrifft alle P2PK- und P2MS-Ausgaben sowie eine kleine Anzahl von nicht standardmäßigen SPKs.

Regel #2: "OP_PUSHDATA* mit Payloads größer als 256 Bytes sind ungültig, außer für den redeemScript-Push in BIP16 scriptSigs." Ich nehme an, dass dies nur für *ausgeführte* Daten-Pushes gilt, daher habe ich Pushes innerhalb von Taproot-Inschriftumschlägen ausgeschlossen, von denen es sehr viele gibt.

Regel #3: "Das Ausgeben von undefinierten Witness- (oder Tapleaf-) Versionen (d.h. nicht Witness v0/BIP 141 oder Taproot/BIP 341) ist ungültig." Es gibt etwas über 54.000 Transaktionen mit Ausgaben ohne Versionsnummer (hauptsächlich unter Verwendung von gefälschten Ausgaben, um das op_return-Limit zu umgehen).

Allerdings definieren BIPs 141 und 341 spezifische Längen für das Witness-Programm: - v0, Länge 20 (P2WPKH) - v0, Länge 32 (P2WSH) - v1, Länge 32 (P2TR) Wie geschrieben, scheint RDTS alle anderen Programmlängen, einschließlich P2A-Anker (v1, Länge 2), zu verbieten.

Regel #4: "Witness-Stacks mit einem Taproot-Anhang sind ungültig." Bisher haben 11 Transaktionen einen Anhang an Taproot-Ausgaben angehängt, hauptsächlich für Jpegs.

Regel #5: "Taproot-Kontrollblöcke, die größer als 257 Bytes sind (ein Merkle-Baum mit 128 Skriptblättern), sind ungültig." Es gibt ~32k offensichtlich Daten einbettende Taproot-Ausgaben mit einer Kontrollblocktiefe von 100+ (labitbus und ähnliche). Aber auch eine Handvoll "legitimer" Ausgaben mit geringerer Tiefe.

Regel #6: "Tapscripts, die OP_SUCCESS* Opcodes irgendwo (auch nicht ausgeführt) enthalten, sind ungültig." Es gibt zwei historische Taproot-Ausgaben, die OP_SUCCESS Opcodes enthalten: Buraks Lightning-Breaker-Transaktion und diese lächerliche OP_CAT-Demo

Regel #7: "Tapscripts, die die OP_IF- oder OP_NOTIF-Anweisung ausführen (unabhängig vom Ergebnis), sind ungültig." Dies zielt darauf ab, das "Inschrift-Envelope" zu deaktivieren, das bisher in über 104 Millionen Transaktionen verwendet wurde.

Allerdings geht RDTS über die Deaktivierung des Einschreibungsumschlags hinaus und verbietet OP_IF und OP_NOTIF vollständig. Etwa 70 Nicht-Einschreibungs-Transaktionen haben OP_IF in Taproot-Skripten verwendet. Viele sind bitvm-artige Experimente, aber es gibt auch Beispiele für einfachere finanzielle Anwendungen.

Zum Beispiel gibt es ein paar Ausgaben, die dieses "verfallende Multisig"-Skript-Template verwenden, das mehrere OP_IFs nutzt.

Am besorgniserregendsten ist, dass es mehrere Ausgaben von einer Wallet gibt, die dieses HTLC-Skript-Template hinter einem bip341 NUMS-Punkt verwendet (deaktiviert den Schlüsselpfad) Das Skript verwendet OP_IF, um zwischen einem Zweig zu wählen, der zwei Unterschriften und ein Hash-Preimage erfordert, oder einer Unterschrift nach einem relativen Timeout.

Befürworter von RDTS haben Bedenken hinsichtlich der Beschlagnahme in Bezug auf OP_IF und große Kontrollblöcke in Taproot zurückgewiesen, indem sie behaupteten, dass Benutzer immer über den Schlüsselpfad ausgeben können. Allerdings haben etwa 560.000 Transaktionen Taproot-Ausgaben verwendet, bei denen der Schlüsselpfad nachweislich deaktiviert war.