Il BIP "Reduced Data Temporary Softfork" propone di disabilitare temporaneamente varie funzionalità di Bitcoin nel consenso. Ho esaminato la blockchain per quantificare l'impatto potenziale, identificando le transazioni storiche che violano ciascuna di queste regole. 🧵↓

Regola n. 1: "I nuovi scriptPubKey che superano i 34 byte sono non validi, a meno che il primo opcode sia OP_RETURN, nel qual caso sono validi fino a 83 byte." Questo influisce su tutti gli output P2PK e P2MS, così come su un numero ridotto di SPK non standard.

Regola n. 2: "OP_PUSHDATA* con payload superiori a 256 byte sono non validi, tranne per il push redeemScript in scriptSigs BIP16." Presumo che questo si applichi solo ai push di dati *eseguiti*, quindi ho escluso i push all'interno delle buste di iscrizione taproot, delle quali ce ne sono davvero molte.

Regola n. 3: "La spesa di versioni di witness (o Tapleaf) non definite (cioè, non Witness v0/BIP 141 né Taproot/BIP 341) è invalida." Ci sono poco più di 54k transazioni con numeri di versione non definiti (per lo più utilizzando output falsi per aggirare il limite di op_return).

Tuttavia, i BIP 141 e 341 definiscono lunghezze specifiche per i programmi witness: - v0, lunghezza 20 (P2WPKH) - v0, lunghezza 32 (P2WSH) - v1, lunghezza 32 (P2TR) come scritto, il RDTS sembra vietare tutte le altre lunghezze di programma, inclusi gli ancoraggi P2A (v1, lunghezza 2).

Regola n. 4: "Gli stack di testimoni con un'annessa Taproot sono non validi." Fino ad ora, 11 transazioni hanno allegato un'annessa agli spend di taproot, per lo più per jpegs.

Regola n. 5: "I blocchi di controllo Taproot più grandi di 257 byte (un albero di Merkle con 128 foglie di script) sono non validi." Ci sono ~32k ovviamente spese di taproot con embedding di dati con una profondità del blocco di controllo di oltre 100 (labitbus e simili). Ma anche un pugno di spese "legittime" a profondità inferiore.

Regola n. 6: "I Tapscripts che includono gli opcode OP_SUCCESS* ovunque (anche non eseguiti) sono non validi." Ci sono due spese storiche di taproot che includono opcode OP_SUCCESS: la transazione di Burak, il lightning-breaker, e questa sciocca demo di OP_CAT.

Regola n. 7: "I Tapscripts che eseguono l'istruzione OP_IF o OP_NOTIF (indipendentemente dal risultato) sono non validi." Questo mira a disabilitare l'"involucro di iscrizione", che è stato utilizzato in oltre 104 milioni di transazioni finora.

Tuttavia, RDTS va oltre la disabilitazione dell'involucro di iscrizione, vietando completamente OP_IF e OP_NOTIF. Circa 70 transazioni non di iscrizione hanno utilizzato OP_IF negli script taproot. Molte sono esperimenti in stile bitvm, ma ci sono anche esempi di utilizzo finanziario più diretto.

Ad esempio, ci sono un paio di spese che utilizzano questo template di script "multisig in decadimento", che usa più OP_IF.

La cosa più preoccupante è che ci sono più spese da un wallet che utilizza questo template di script HTLC dietro un punto NUMS bip341 (disabilitando il percorso della chiave) Lo script utilizza OP_IF per scegliere tra un ramo che richiede due firme e un preimmagine hash, oppure una firma dopo un timeout relativo.

I sostenitori di RDTS hanno respinto le preoccupazioni relative alla confisca riguardanti OP_IF e i grandi blocchi di controllo in taproot, affermando che gli utenti possono sempre spendere tramite il keypath. Tuttavia, circa 560k transazioni hanno speso output taproot dove il keypath era provabilmente disabilitato.