"Reduced Data Temporary Softfork" BIP foreslår midlertidig å deaktivere ulike Bitcoin-funksjoner i konsensus. Jeg har undersøkt blokkjeden for å kvantifisere den potensielle innvirkningen, ved å identifisere historiske transaksjoner som bryter med hver av disse reglene. 🧵↓

Regel #1: "Nytt utdataskriptPubKeys som overstiger 34 byte er ugyldige, med mindre den første opkoden er OP_RETURN, i så fall er opptil 83 byte gyldige." Dette påvirker alle P2PK- og P2MS-utganger, samt et lite antall ikke-standard SPK-er.

Regel #2: "OP_PUSHDATA* med nyttelaster større enn 256 byte er ugyldige, bortsett fra redeemScript-pushen i BIP16 scriptSigs." Jeg antar at dette bare gjelder *utførte* datapushes, så jeg har ekskludert pushes i taproot-inskripsjonskonvolutter, som det er veldig mange av.

Regel #3: "Å bruke udefinerte vitneversjoner (eller Tapleaf) versjoner (dvs. ikke vitne v0/BIP 141 eller Taproot/BIP 341) er ugyldig." Det er litt over 54k transaksjoner med udefinerte versjonsnummerutganger (for det meste bruker falske utganger for å omgå op_return-grensen).

BIPs 141 og 341 definerer imidlertid spesifikke vitneprogramlengder: - v0, lengde 20 (P2WPKH) - v0, lengde 32 (P2WSH) - v1, lengde 32 (P2TR) som skrevet, ser RDTS ut til å forby alle andre programlengder, inkludert P2A-ankere (v1, lengde 2).

Regel #4: "Vitnestakker med et Taproot-anneks er ugyldige." Så langt har 11 transaksjoner lagt ved et vedlegg til taproot-utgifter, for det meste for jpeg-filer.

Regel #5: "Taproot-kontrollblokker større enn 257 byte (et merkle-tre med 128 skriptblader) er ugyldige." Det er ~32k åpenbart data-innebygging taproot-utgifter med kontrollblokkdybde på 100+ (labitbus og lignende). Men også en håndfull "legitime" utgifter på lavere dybde.

Regel #6: "Tapscripts inkludert OP_SUCCESS* opkoder hvor som helst (selv uutført) er ugyldige." Det er to historiske taproot-utgifter, inkludert OP_SUCCESS opcodes: Buraks lynbrytertransaksjon og denne dumme OP_CAT-demoen

Regel #7: "Tapscripts som utfører OP_IF eller OP_NOTIF instruksjon (uavhengig av resultat) er ugyldige." Dette tar sikte på å deaktivere "inskripsjonskonvolutten", som har blitt brukt av over 104 millioner transaksjoner så langt.

RDTS går imidlertid utover å deaktivere inskripsjonskonvolutten, og forbyr OP_IF og OP_NOTIF helt. Omtrent 70 ikke-inskripsjonstransaksjoner har brukt OP_IF i taproot-skript. Mange er eksperimenter i bitvm-stil, men det finnes også eksempler på mer enkel økonomisk bruk.

For eksempel er det et par utgifter som bruker denne "decaying multisig" skriptmalen, som bruker flere OP_IFs

Det mest bekymringsfulle er at det er flere utgifter fra en lommebok som bruker denne HTLC-skriptmalen bak et bip341 NUMS-punkt (deaktivering av nøkkelbanen) Skriptet bruker OP_IF til å velge mellom en gren som krever to signaturer og et hash-forhåndsbilde, eller én signatur etter et relativt tidsavbrudd

RDTS-tilhengere har avvist bekymringer knyttet til konfiskering knyttet til OP_IF og store kontrollblokker i taproot ved å hevde at brukere alltid kan bruke via nøkkelbanen i stedet. Imidlertid har omtrent 560k transaksjoner brukt taproot-utganger der nøkkelbanen beviselig ble deaktivert.