Fermata #245 - OP_FRACTURE

Vi ricordate gli Ordinals? Sono tornati.

O meglio, sono parte di un dibattito che si è fatto molto più ampio e che in questi giorni sta facendo volare gli stracci tra i contributor di Bitcoin Core e la community, sia su GitHub che su X.

Riassumiamo prima cosa siano gli Ordinals, spiegati nella fermata #80 e poi facciamo chiarezza su quanto accaduto nelle ultime ore.

Gli Ordinals sono un protocollo che consente di “iscrivere” dati arbitrari (immagini, video, testi) direttamente sulla blockchain di Bitcoin associandoli a singoli satoshi. In breve, sfruttando gli upgrade SegWit e Taproot, gli utenti possono nascondere dati nel campo delle transazioni riservato alle firme crittografiche e rendere così la blockchain un deposito di contenuti multimediali. Va da sé che ogni nuova Inscription occupa prezioso spazio nei blocchi, riducendo la capacità per transazioni finanziarie.

I problemi principali che questo crea sono due, come racconta Turtlecute, Bitcoin Analyst di Braiins, ai microfoni di Bitcoin Train:

• Crescita dell’UTXO set
  Bitcoin Core mantiene un database (UTXO set) per verificare rapidamente la validità dei fondi ricevuti. Questo database ha raggiunto circa 14 GB e la sua dimensione è triplicata negli ultimi 3-4 anni. Il problema è che gli spammer non usano i campi predisposti per i dati arbitrari, ma preferiscono altri metodi più efficienti o economici (ad esempio, transazioni Taproot con molti output). Questo comporta un aumento dell’UTXO set che ogni nodo deve mantenere, aumentando i requisiti hardware e rendendo più costosa la gestione di un nodo. I developer vorrebbero mantenerlo il più contenuto possibile.

• Abuso della mempool e dei servizi out of band
  Chi crea Ordinals spesso sfrutta servizi out of band come Slipstream, Mempool Accelerator, ecc. In questo modo, inviano le transazioni direttamente ai miner, eludendo le regole standard del client Bitcoin Core. Questo comportamento mina alcune funzioni del protocollo, come la stima corretta delle commissioni, fondamentale ad esempio per chiudere i canali Lightning. Se i nodi non vedono più tutte le transazioni nella loro mempool, diventano incapaci di fare stime accurate.

La proposta di Peter Todd: togliere il limite a OP_RETURN

In questo contesto, il developer Peter Todd ha formalizzato su GitHub la pull request #32359, proponendo di rimuovere i limiti arbitrari attualmente imposti sugli output OP_RETURN di Bitcoin Core. In pratica, si tratta di eliminare il vincolo che oggi permette solo output con al massimo 80 byte di dati.

Todd argomenta che queste restrizioni sono ormai obsolete: come spiegato anche da Turtlecute, si possono mandare le transazioni direttamente ai miner. La Pull Request propone quindi di togliere il limite all’ampiezza dell’OP_RETURN.

Todd indica che la norma è spesso discussa come disincentivo per scrivere dati arbitrari sulla blockchain, ma finora non ha scoraggiato nessuno: gli utenti semplicemente bypassano il disincentivo estraendo i dati in modi diversi. In secondo luogo, Todd fa notare che al momento solo i miner hanno potere di far valere il vincolo: questo perché il limite non è una regola di consenso, ma solamente una policy di default di Bitcoin Core: se anche il tuo nodo la implementa, rigettando gli OP_RETURN più pesanti, qualora una mining pool li accettasse e li inserisse nei propri blocchi, il tuo nodo sarebbe comunque costretto a memorizzarli una volta confermato il blocco.

Le posizioni e la miccia della discordia

Gran parte dei contributor di Bitcoin Core è a favore della rimozione del limite. Sul fronte opposto il capofila è probabilmente Luke Dashjr che ha già chiaramente definito l’idea «utter insanity».

A parere di chi vi scrive l’opinione più misurata, come spesso accade, è quella di Gregory Maxwell, cofondatore di Blockstream ed ex sviluppatore di Bitcoin Core.

Maxwell concorda che le limitazioni incentivano pratiche peggiori, come l’invio diretto delle transazioni ai miner, aumentando la centralizzazione. Questo comportamento, sostiene, danneggia Bitcoin perché spinge verso una maggiore dipendenza dalle grandi mining pool. Per Maxwell, una policy non dovrebbe mai essere più restrittiva di ciò che di fatto viene già minato. Imporre limiti superiori crea frizione, rallenta la propagazione dei blocchi e incentiva l’uso di scorciatoie private.

Bitcoin è già progettato per gestire lo spam - dice - e l’uso della capacità di blocco per contenuti ritenuti “inutili” non è in sé un bug, ma una caratteristica inevitabile in un sistema aperto.

Il disastro comunicativo dei Core Dev

La vera frattura tra i gli sviluppatori e la community più ampia, però, non è sorta a causa del dibattito sul merito della proposta di Peter Todd, quanto sulle modalità di moderazione dei commenti su GitHub.

I toni, già piuttosto accesi, dei commenti contrari alla proposta, capitanati da quelli di Luke Dashjr e Bitcoin Mechanic di Ocean Pool, hanno portato gli sviluppatori a iniziare a bannare e mutare utenti su GitHub, tra cui lo stesso Mechanic. Ma la moderazione non si è scagliata solamente contro i commenti più diretti.

Spiega Turtlecute: “Anche chi, come me, ha espresso un’opinione moderata e rispettosa, dicendo che nessuna delle opzioni è chiaramente superiore e che forse è meglio mantenere lo status quo, si è visto cancellare il commento. Al contrario, chi in passato aveva contribuito a Core ha visto il proprio commento mantenuto. Non si può forse parlare di censura vera e propria, ma la gestione del confronto è stata sicuramente maldestra. Questo ha innescato una reazione a catena: gli utenti bannati hanno postato screenshot su Twitter, scatenando una rivolta digitale”.

Come se non bastasse, nelle ultime ore i commenti su GitHub sono stati completamente bloccati, salvo sbloccarli un attimo per far commentare un Core Developer e poi ribloccarli nuovamente: mossa che ha messo ancora più benzina sul fuoco.

In buona sostanza, la frattura tra gli sviluppatori e la community sembra profonda e, ad oggi, la situazione è bloccata. Da una parte c’è un forte consenso tra i developer Core per implementare la proposta; dall’altra, la community è furiosa e minaccia di abbandonare Core per soluzioni alternative, come Bitcoin Knots, o di boicottare lo sviluppo.

La pull request di Peter Todd è quindi al momento in stallo. Da un lato, l’implementazione è tecnicamente valida, anche se non è detto che migliorerebbe il comportamento degli spammer. Dall’altro, ignorare il malcontento e implementare la pull request nel prossimo aggiornamento di Bitcoin Core potrebbe causare una sollevazione popolare.

Se la polarizzazione dovesse acuirsi senza un compromesso, non è da escludere che alcuni attori possano decidere di emergere con nuovi client, come il già esistente Bitcoin Knots a cui alcuni protagonisti del dibattito hanno già dichiarato di essere passati. Questo risolverebbe il problema dello spam su Bitcoin?

Niente affatto.