Critica alla Proposta di Soft Fork RDTS
Lo sviluppatore e analista di Mempool.space, Mononaut, ha pubblicato una critica dettagliata avvertendo che il proposto “Reduced Data Temporary Soft Fork” (RDTS) potrebbe disabilitare transazioni legittime attraverso la rete Bitcoin. Questa nuova proposta di soft fork, progettata per limitare l’eccessivo storage di dati sulla blockchain di Bitcoin, sta attirando forti critiche negli ultimi tempi. Mercoledì, Mononaut ha pubblicato una valutazione che delinea i potenziali danni collaterali che il set di regole potrebbe causare.
Dettagli della Proposta RDTS
La proposta RDTS introduce una serie di restrizioni a livello di consenso destinate a ridurre le transazioni pesanti in dati, uno sforzo che gli sviluppatori affermano sia necessario dopo l’aggiornamento di Bitcoin Core v30, che ha rimosso i limiti sui dati OP_RETURN. Se attivato, RDTS si applicherebbe per circa un anno, limitando gli scriptPubKeys a 34 byte, fissando gli output OP_RETURN a 83 byte, restringendo i blocchi di controllo Taproot, vietando versioni di testimoni non definite e disabilitando intere categorie di logica Tapscript.
I sostenitori del BIP sostengono che queste misure fungano da freno d’emergenza contro caricamenti di dati arbitrari che potrebbero esporre gli operatori di nodi a responsabilità legali nel caso in cui materiale illegale fosse incorporato nella catena. Tuttavia, la valutazione di Mononaut quantifica le conseguenze pratiche di queste restrizioni, esaminando l’attività storica della blockchain per vedere quali transazioni reali avrebbero violato le regole proposte. I suoi risultati suggeriscono una significativa interruzione: sotto il limite di dimensione dello scriptPubKey, tutti gli output pay-to-public-key (P2PK) e multisig (P2MS) sarebbero invalidi. Questa restrizione influisce anche su un numero ridotto di output non standard in transazioni passate.
Implicazioni delle Restrizioni
Una delle regole più ampie, che invalida le operazioni OP_PUSHDATA con payload superiori a 256 byte, non influenzerebbe le buste di iscrizione, assumendo che solo i push eseguiti siano considerati validi. Tuttavia, Mononaut ha sottolineato che le versioni di testimoni non definite influenzerebbero più di 54.000 transazioni storiche, molte delle quali hanno utilizzato output non convenzionali per bypassare i limiti sui dati OP_RETURN. Poiché le lunghezze delle versioni di testimoni sono strettamente definite nei BIP 141 e 341, la proposta, così com’è scritta, bloccherebbe anche alcuni formati moderni validi, come gli ancoraggi P2A.
Mononaut ha dettagliato che RDTS invalida anche gli stack di testimoni contenenti un allegato Taproot. Sebbene rari, lo sviluppatore di Mempool.space nota che almeno 11 transazioni hanno utilizzato un allegato per scopi pesanti in dati. Una categoria più significativa è quella dei grandi blocchi di controllo Taproot: circa 32.000 spese passate includono blocchi di controllo di profondità superiore a 100, spesso utilizzati per l’incorporamento di dati. Anche alcuni esperimenti non legati ai dati si basano su configurazioni più piccole e legittime che verrebbero disabilitate. Un indirizzo attivo spende costantemente a una profondità di blocco di controllo 11, che verrebbe rifiutata sotto RDTS.
Critiche e Sostenitori
Le restrizioni più rigorose della proposta, che vietano OP_SUCCESS e qualsiasi Tapscript che esegue OP_IF o OP_NOTIF, vanno ben oltre le buste di iscrizione. Mononaut evidenzia due transazioni storiche OP_SUCCESS, inclusa la transazione di rottura del lightning di Burak, e circa 70 spese Taproot basate su OP_IF non legate all’iscrizione. Diverse di queste sono primitive finanziarie, inclusi template multisig in decadenza e design di contratti hash-time-locked (HTLC). Alcuni provengono da portafogli che hanno disabilitato intenzionalmente il loro keypath, lasciando la spesa tramite script-path come unico modo per spostare fondi. I sostenitori di RDTS hanno sostenuto che gli utenti con script influenzati potrebbero tornare alla spesa tramite keypath. Tuttavia, i dati di Mononaut sfidano direttamente quell’assunzione: circa 560.000 spese storiche Taproot provengono da output il cui keypath era probabilmente disabilitato, rendendo OP_IF e funzioni simili essenziali piuttosto che opzionali.
I sostenitori del soft fork temporaneo sostengono che RDTS sia una misura protettiva a breve termine progettata per preservare l’utilità monetaria di Bitcoin, prevenire rischi legali e ridurre i carichi sui nodi limitando lo storage di dati. I critici controbattono che ampie restrizioni sul comportamento di Tapscript rischiano di introdurre una censura di fatto, disabilitando tipi di transazioni valide e rompendo applicazioni esistenti.
Il dibattito rispecchia dispute precedenti sulla crescita dei dati guidata dall’iscrizione, riflettendo disaccordi più profondi su se Bitcoin debba rimanere strettamente monetario o continuare ad accogliere usi sperimentali. Poiché la proposta rimane in forma di bozza, la discussione è in corso tra sviluppatori, ricercatori e partecipanti all’ecosistema.
