BIP-110 spiegato: cosa rivela un soft fork controverso sul consenso di Bitcoin

La domanda sotto il fork

BIP-110 e facile da archiviare sotto la lunga disputa sugli Ordinals e sui dati arbitrari su Bitcoin. Questa cornice manca cio che e davvero in gioco. La proposta non aggiunge un filtro locale che ogni operatore di nodo puo scegliere. Cambia le regole di consenso che decidono quali blocchi appartengono a Bitcoin.

E un tipo di modifica diverso. Un filtro antispam e una preferenza. Una regola di consenso e una definizione. BIP-110 pone una domanda che sta al di sopra del dibattito sui dati: Bitcoin deve solo verificare se una transazione e valida secondo regole neutre, oppure le regole devono anche vietare certi usi dello spazio nei blocchi? E dalla prima ne segue una seconda: fino a che punto puo spingersi una minoranza per imporre la sua risposta preferita?

Questa e un'analisi di quelle domande e della meccanica che le rende urgenti questo mese. CanoeBit non prende posizione sul prezzo di Bitcoin e non fornisce alcuna raccomandazione su cosa chiunque dovrebbe fare. Per lo stato attuale, la tempistica di attivazione e il bug segnalato nel client, vedi la notizia BIP-110 verso la segnalazione obbligatoria.

Cosa limita davvero BIP-110

Per circa un anno, cioe 52.416 blocchi, BIP-110 aggiungerebbe sette regole di consenso. I nuovi script di output sarebbero limitati a 34 byte, con gli output OP_RETURN consentiti fino a 83. I data push e gli elementi witness usati come argomenti di script sarebbero limitati a 256 byte. Le versioni di witness e Tapleaf non definite non potrebbero essere spese, l'annex Taproot sarebbe vietato, i control block sarebbero limitati a 257 byte, e OP_SUCCESS oltre alle istruzioni OP_IF e OP_NOTIF eseguite sarebbero invalide in Tapscript.

La sfumatura importante e che queste regole sono generali. Colpiscono le tecniche su cui oggi si basano le inscription, ma incidono in modo ampio su Script, sui dati witness e su diversi percorsi di aggiornamento di Taproot. La stessa specifica ammette casi ristretti e sperimentali che coinvolgono transazioni Taproot pre-firmate, in cui i fondi potrebbero in teoria essere congelati o persi, pur mettendo grande cura nel proteggere con il grandfathering ogni moneta confermata prima dell'attivazione.

Quindi la proposta non e un pulito "divieto degli Ordinals". E un ampio irrigidimento di come puo apparire una transazione Bitcoin valida, con un piccolo rischio residuo per usi legittimi ma non documentati. E un elemento che vale la pena soppesare, non perche il rischio sia grande, ma perche nessuno puo enumerare ogni costruzione contrattuale gia in circolazione.

Lo steelman: perche la preoccupazione e legittima

La frustrazione dietro BIP-110 non e irragionevole, e vale la pena esporla nella sua forma piu forte prima di smontarla.

I full node devono scaricare e validare ogni blocco. Gli script di output non spesi vivono nell'UTXO set, che i nodi tengono su memoria veloce e non possono potare. Le grandi inscription competono con le transazioni monetarie per lo spazio scarso nei blocchi, possono far salire le commissioni per i pagamenti ordinari, e parte del contenuto incorporato e materiale che gli operatori di nodo preferirebbero non ospitare affatto. Se si crede che il primo scopo di Bitcoin sia essere moneta, vedere il suo spazio nei blocchi riempirsi di dati che gravano per sempre su ogni nodo e una lamentela autentica.

Quel ragionamento e coerente. Il disaccordo non riguarda se l'inserimento di dati abbia dei costi. Riguarda se una modifica di consenso temporanea e a bassa soglia sia lo strumento giusto per affrontarli.

Dove il ragionamento si assottiglia

Due problemi indeboliscono la proposta sui suoi stessi termini.

Il primo e economico. Il progetto originale di Satoshi contiene gia un meccanismo antispam: le commissioni e un limite fisso alla dimensione del blocco. Quando lo spazio nei blocchi si riempie, diventa costoso, e gli usi che non portano alcun ritorno monetario tendono a diventare troppo cari. Non e teoria. Le ondate di inscription si sono raffreddate ripetutamente man mano che le commissioni salivano e l'attivita smetteva di ripagarsi. Una regola di consenso che rende soltanto piu difficile un metodo invita i dati a spostarsi, non a sparire.

Il secondo problema e peggiore, ed e dove la cura potrebbe alimentare la malattia. Se l'archiviazione di dati contigui nei campi evidenti viene vietata, attori determinati possono suddividere i payload in molti piccoli push o mascherarli da normali dati finanziari. Distribuiti su molti output, quei dati possono finire nell'UTXO set, l'unica parte della catena che i nodi non possono potare. Nello sforzo di tenere fuori i dati indesiderati, la modifica rischia di spostarli nel posto piu costoso in cui archiviarli. La proposta non lo nega. Sostiene che la frammentazione e il costo piu alto mandino comunque un messaggio. E un punto reale, ma e un messaggio, non una soluzione.

Come si formerebbe una spaccatura della catena

La meccanica della spaccatura e semplice, e questo e in parte il motivo per cui il rischio e credibile. Dal blocco 961.632, i nodi BIP-110 e i normali nodi Bitcoin applicano regole diverse. Se un blocco imposta il bit 4, entrambi i lati possono accettarlo. Se un blocco non lo fa, i nodi normali lo considerano comunque valido, mentre i nodi BIP-110 lo rifiutano.

In quel momento i due gruppi smettono di seguire la stessa catena. Con la grande maggioranza dell'hashrate che non segnala, la normale catena Bitcoin proseguirebbe quasi indisturbata, mentre i nodi BIP-110 aspetterebbero che uno dei pochi miner segnalanti produca un blocco sul loro ramo. Una seconda catena puo esistere sul piano tecnico. Se conti sul piano economico e una domanda separata, e i dati attuali non suggeriscono che conterebbe.

Due scelte di progettazione acuiscono il pericolo. Non esiste alcuna protezione replay generale, quindi una transazione puo essere valida su entrambe le catene contemporaneamente, un pericolo che i fork passati hanno dimostrato quando gli utenti muovono le monete nelle prime ore. E lo stesso client di attivazione porta con se il bug di aggiornamento riproducibile documentato nel report BlockSlop, in cui due nodi che eseguono le stesse regole possono finire su catene diverse a seconda della storia della loro data directory. Una modifica di consenso il cui stesso client non puo garantire che nodi identici concordino non e matura.

Il numero che decide tutto

La soglia di segnalazione e il centro silenzioso di questa disputa. Taproot, un aggiornamento non controverso e puramente additivo, e stato distribuito con una soglia dei miner del 90 per cento. BIP-110, che rimuove capacita esistenti e puo innescare una spaccatura, fissa la sua asticella al 55 per cento.

Quell'inversione e significativa. La modifica a rischio piu alto chiede meno consenso di quanto ne chiedesse quella a rischio piu basso. La difesa della proposta e che una regola temporanea, di un anno, non ha bisogno di una disponibilita quasi universale. Letta in chiave strutturale, pero, la soglia bassa sembra meno un margine di sicurezza e piu un tentativo di superare un'asticella che un sostegno ampio non riesce a raggiungere da solo. E anche il 55 per cento non e vicino: la segnalazione e rimasta a pochi punti percentuali per tutto il deployment.

Qui l'espressione "segnalazione obbligatoria" invita a un fraintendimento. Non obbliga i miner ad attivare nulla. Significa solo che i nodi BIP-110 rifiuteranno i blocchi non segnalanti a partire da quell'altezza. Se la maggior parte dei miner continua a produrre blocchi normali, quei blocchi restano validi per il resto della rete, e sono i nodi BIP-110 a restare indietro. Un soft fork attivato dagli utenti puo fare pressione sui miner, ma solo quando una credibile maggioranza economica di exchange, custodi, wallet e utenti rifiuta tutto tranne la catena piu severa. Nessuna maggioranza di questo tipo e visibile per BIP-110.

Una catena che arrancherebbe

Supponiamo che una catena BIP-110 separata si formi e mantenga il piccolo hashrate che ora segnala, circa l'uno e mezzo per cento della rete. Erediterebbe l'attuale difficolta di Bitcoin con una frazione della potenza necessaria a soddisfarla.

L'aritmetica non perdona. I blocchi arriverebbero in media circa ogni undici ore invece che ogni dieci minuti, quasi 68 volte piu lentamente. Bitcoin ricalibra la difficolta solo ogni 2.016 blocchi, e a quel ritmo raggiungere il primo aggiustamento richiederebbe nell'ordine di 950 giorni, circa due anni e mezzo. Fino ad allora la catena produrrebbe blocchi occasionali, non una rete di pagamento funzionante. Una catena di minoranza e tecnicamente possibile. Una utilizzabile, con questi numeri, non lo e.

La lettura di CanoeBit, e dove cade

La nostra lettura strutturale e questa: BIP-110 ha molte piu probabilita di produrre una catena di minoranza piccola, lenta e in gran parte ignorata che di cambiare Bitcoin, e il suo progetto di attivazione sostituisce l'affermazione al consenso. Ripetere che una proposta ha il consenso non lo crea. Il consenso emerge quando utenti, miner, sviluppatori e imprese indipendenti convergono volontariamente su delle regole, e quella convergenza qui non e visibile.

Poiche un'analisi onesta nomina le proprie condizioni di fallimento, ecco le nostre. Questa lettura cadrebbe se una quota significativa di hashrate migrasse sul ramo BIP-110, o se grandi exchange, custodi e fornitori di wallet si impegnassero a trattare solo la catena piu severa come Bitcoin. In quel caso esisterebbe una vera maggioranza economica e il calcolo cambierebbe. Cadrebbe anche se le basse cifre di segnalazione fossero mal misurate e la disponibilita reale fosse molto piu alta di quanto mostrano i dashboard. Nessuna di queste condizioni e evidente oggi, ma entrambe sono osservabili, ed entrambe sono cio che osserveremmo per sapere di aver sbagliato.

Il punto piu circoscritto resta valido comunque si risolva il fork. Un dibattito sullo spazio nei blocchi e sull'archiviazione di dati vale la pena di essere fatto. Deciderlo con una modifica di consenso costruita in fretta e a bassa soglia, applicata da un client con un noto bug di divergenza, e un cattivo modo di farlo.