Sviluppatore Evidenzia Rischi Maggiori nel Proposto Soft Fork di Riduzione Dati di Bitcoin

La revisione dei dati di transazione mostra che RDTS potrebbe bloccare casi d’uso cruciali di Bitcoin

Una nuova proposta di soft fork progettata per ridurre l’archiviazione eccessiva di dati sulla blockchain di Bitcoin sta suscitando forti critiche in tempi recenti. Mercoledì, l’analista indipendente e sviluppatore di mempool.space, Mononaut, ha pubblicato una valutazione delineando i potenziali danni collaterali che il set di regole potrebbe causare.

La proposta, conosciuta come Reduced Data Temporary Softfork (RDTS), introduce una serie di restrizioni a livello di consenso intese a ridurre le transazioni data-heavy—uno sforzo che gli sviluppatori ritengono necessario a seguito dell’aggiornamento Bitcoin Core v30 che ha rimosso i limiti sui dati OP_RETURN.

RDTS sarebbe applicato per circa un anno se attivato, limitando gli scriptPubKeys a 34 byte, fissando i limiti di 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 le misure agiscano come un freno di emergenza contro upload arbitrari di dati che potrebbero esporre gli operatori dei nodi a responsabilità legali se materiale illegale fosse incorporato nella catena.

L’analisi di Mononaut, tuttavia, quantifica le ricadute pratiche di tali restrizioni esaminando l’attività storica della blockchain per vedere quali transazioni reali avrebbero violato le regole proposte. I suoi risultati suggeriscono un’importante interruzione. Sotto il solo limite di dimensione scriptPubKey, tutti gli output pay-to-public-key (P2PK) e multisig (P2MS) sarebbero invalidi. Tale restrizione colpisce anche un piccolo numero di output non standard nelle transazioni passate.

Una delle regole più ampie—invalidare le operazioni OP_PUSHDATA con payload sopra i 256 byte—non influenzerebbe le buste d’iscrizione, assumendo che solo pushes eseguiti si qualifichino. Ma Mononaut ha sottolineato che le versioni di testimoni non definite impatterebbero più di 54.000 transazioni storiche, molte delle quali hanno utilizzato output non convenzionali per superare i limiti di dati OP_RETURN. Poiché le lunghezze delle versioni dei testimoni sono strettamente definite nei BIP 141 e 341, la proposta come scritta bloccherebbe persino alcuni formati moderni validi come gli ancore P2A.

Leggi anche: Gli sviluppatori di Bitcoin Core fondono modifiche di politica controverse: è in arrivo un fork?

Mononaut ha dettagliato che RDTS invalida anche le stack di testimoni contenenti un’appendice Taproot. Sebbene raro, lo sviluppatore di mempool.space osserva che almeno 11 transazioni hanno utilizzato un’appendice per scopi data-heavy. Una categoria più significativa, Mononaut ha sottolineato, sono i grandi blocchi di controllo Taproot: circa 32.000 spese passate includono blocchi di controllo di profondità 100+ spesso usati per l’incorporazione dei dati, ma persino alcuni esperimenti non di dati si basano su configurazioni più piccole e legittime che verrebbero disabilitate. Un indirizzo attivo spende costantemente a profondità di blocco di controllo 11, che verrebbe rifiutato sotto RDTS.

Gli articoli di linea più rigorosi della proposta—vietare OP_SUCCESS* e qualsiasi Tapscript che esegue OP_IF o OP_NOTIF—raggiungono ben oltre le buste di iscrizione. Mononaut evidenzia due transazioni storiche OP_SUCCESS, inclusa la transazione che interrompe il fulmine di Burak, e circa 70 spese basate su Taproot non di iscrizione OP_IF. Alcune di queste sono primitive finanziarie, tra cui modelli multisig decadenti e design HTLC (hash-time-locked contract). Alcuni originano da portafogli che hanno intenzionalmente disabilitato il loro percorso chiave, lasciando come l’unico modo di spendere i fondi.

I sostenitori dell’RDTS hanno argomentato che gli utenti con script colpiti potrebbero ripiegare sulla spesa del percorso chiave. Tuttavia, i dati di Mononaut sfidano direttamente tale presupposto: circa 560.000 spese storiche Taproot provengono da output il cui percorso chiave era dimostrabilmente 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 pericoli legali e ridurre i carichi sui nodi limitando l’archiviazione dei dati. I critici contrappongono che ampie restrizioni sul comportamento di Tapscript rischiano di introdurre una censura de facto, disabilitando tipi di transazioni valide e rompendo applicazioni esistenti.

Il dibattito rispecchia dispute precedenti sulla crescita dei dati guidata dalle iscrizioni, riflettendo disaccordi più profondi sul fatto che Bitcoin debba rimanere strettamente monetario o continuare ad accogliere usi sperimentali. Poiché la proposta rimane in bozza, la discussione è in corso tra sviluppatori, ricercatori e partecipanti all’ecosistema.

FAQ ❓

• Che cos’è RDTS?
  Una proposta di soft fork temporaneo che restringe diverse funzionalità di script e dati di Bitcoin.
• Perché RDTS è oggetto di dibattito?
  I sostenitori vogliono ridurre l’abuso di dati, mentre i critici dicono che disabilita transazioni valide.
• Cosa ha scoperto Mononaut?
  La sua analisi mostra che molte transazioni storiche fallirebbero sotto le regole RDTS.
• Quanto durerebbe RDTS?
  La proposta delinea una finestra di attivazione di un anno se adottata.