De "Verminderde Gegevens Tijdelijke Softfork" BIP stelt voor om tijdelijk verschillende Bitcoin-functies in consensus uit te schakelen. Ik heb de blockchain onderzocht om de potentiële impact te kwantificeren, door historische transacties te identificeren die elk van deze regels schenden. 🧵↓

Regel #1: "Nieuwe output scriptPubKeys die 34 bytes overschrijden zijn ongeldig, tenzij de eerste opcode OP_RETURN is, in welk geval tot 83 bytes geldig zijn." Dit heeft invloed op alle P2PK en P2MS outputs, evenals een klein aantal niet-standaard SPK's.

Regel #2: "OP_PUSHDATA* met payloads groter dan 256 bytes zijn ongeldig, behalve voor de redeemScript push in BIP16 scriptSigs." Ik neem aan dat dit alleen van toepassing is op *uitgevoerde* data pushes, dus ik heb pushes binnen taproot inscriptie-enveloppen uitgesloten, waarvan er heel veel zijn.

Regel #3: "Het uitgeven van niet-gedefinieerde getuigen (of Tapleaf) versies (d.w.z. niet Witness v0/BIP 141 of Taproot/BIP 341) is ongeldig." Er zijn net iets meer dan 54k transacties met niet-gedefinieerde versienummeruitgangen (voornamelijk met nepuitgangen om de op_return limiet te omzeilen).

Echter, BIPs 141 en 341 definiëren specifieke lengtes van het witness-programma: - v0, lengte 20 (P2WPKH) - v0, lengte 32 (P2WSH) - v1, lengte 32 (P2TR) zoals geschreven, lijkt RDTS alle andere programm lengtes te verbieden, inclusief P2A-ankers (v1, lengte 2).

Regel #4: "Getuigenstapels met een Taproot-annex zijn ongeldig." Tot nu toe hebben 11 transacties een annex aan taproot-uitgaven gehecht, voornamelijk voor jpegs.

Regel #5: "Taproot controleblokken groter dan 257 bytes (een merkle-boom met 128 scriptbladeren) zijn ongeldig." Er zijn ~32k duidelijk data-embedden taproot-uitgaven met een controleblokdiepte van 100+ (labitbus en soortgelijke). Maar ook een handvol "legitieme" uitgaven op lagere diepte.

Regel #6: "Tapscripts met OP_SUCCESS* opcodes ergens (zelfs ongeëxecuteerd) zijn ongeldig." Er zijn twee historische taproot-uitgaven met OP_SUCCESS opcodes: Burak's lightning-breaker transactie en deze domme OP_CAT demo

Regel #7: "Tapscripts die de OP_IF of OP_NOTIF instructie uitvoeren (ongeacht het resultaat) zijn ongeldig." Dit is bedoeld om de "inscriptie envelop" uit te schakelen, die tot nu toe in meer dan 104 miljoen transacties is gebruikt.

Echter, RDTS gaat verder dan het uitschakelen van de inschrijvingsenvelop, door OP_IF en OP_NOTIF volledig te verbieden. Ongeveer 70 niet-inschrijvings transacties hebben OP_IF gebruikt in taproot-scripts. Veel zijn bitvm-stijl experimenten, maar er zijn ook voorbeelden van meer rechttoe rechtaan financiële toepassingen.

Bijvoorbeeld, er zijn een paar uitgaven die deze "vervallende multisig" scripttemplate gebruiken, die meerdere OP_IFs gebruikt.

Het meest verontrustend is dat er meerdere uitgaven zijn vanuit een portemonnee die deze HTLC-scripttemplate achter een bip341 NUMS-punt gebruikt (de sleutelpad uitschakelend) Het script gebruikt OP_IF om te kiezen tussen een tak die twee handtekeningen en een hash-preimage vereist, of één handtekening na een relatieve timeout

Voorstanders van RDTS hebben zorgen over confiscatie met betrekking tot OP_IF en grote controleblokken in taproot van de hand gewezen door te beweren dat gebruikers altijd via het sleutelpad kunnen uitgeven. Echter, ongeveer 560k transacties hebben taproot-uitgangen uitgegeven waarbij het sleutelpad aantoonbaar uitgeschakeld was.