Dopo il fallimento del BIP-110, il prossimo soft fork di Bitcoin si appresta ad affrontare una resa dei conti

Il BIP-54, formalmente noto come “Consensus Cleanup”, apporterebbe quattro modifiche circoscritte alle regole fondamentali di Bitcoin. La proposta è pensata per colmare vecchie vulnerabilità e casi limite insoliti, non per aggiungere nuovi modi di utilizzare Bitcoin. I suoi sostenitori sostengono che questa distinzione sia importante: si tratta di manutenzione preventiva per una rete che ora vale molto di più rispetto a quando molte delle sue regole sono state scritte.

Gli autori della proposta sono Antoine Poinsot, un collaboratore di Bitcoin Core associato a Chaincode Labs, e Matt Corallo, uno sviluppatore di lunga data di Bitcoin. Corallo ha sollevato per la prima volta l’idea generale nel 2019. Poinsot ha ripreso e ampliato il lavoro tra la fine del 2023 e l’inizio del 2024, e la proposta ha ricevuto la designazione formale BIP-54 nell’aprile 2025. La specifica è stata contrassegnata come completa nel maggio 2026, al termine delle fasi di test e implementazione.

La proposta mira a colmare quattro vecchie lacune

La prima correzione è volta ad affrontare un potenziale attacco di tipo “timewarp” alla difficoltà di mining di Bitcoin. Bitcoin ricalcola la difficoltà di mining ogni 2.016 blocchi, all’incirca ogni due settimane, per mantenere la produzione di blocchi vicina a un blocco ogni dieci minuti. La maggioranza della potenza di mining della rete potrebbe sfruttare il modo in cui Bitcoin misura il tempo in quei periodi, utilizzando timestamp manipolati per far sembrare che i blocchi vengano prodotti più lentamente di quanto non avvenga in realtà.

Nel tempo, ciò potrebbe far diminuire la difficoltà di mining. In un caso estremo, un aggressore in possesso della maggioranza dell’hash rate – ovvero la potenza di calcolo utilizzata per minare Bitcoin – potrebbe portare la difficoltà al suo livello più basso in circa 38-40 giorni. Ciò potrebbe teoricamente consentire all’attaccante di produrre blocchi molto più velocemente del normale, creare rapidamente nuove monete, espandere il database della rete relativo alle monete non spese e compromettere i contratti di pagamento basati sul tempo, come quelli utilizzati dal protocollo di secondo livello, il Lightning Network.

Il BIP-54 aggiungerebbe limiti di timestamp all’inizio e alla fine di ogni periodo di 2.016 blocchi. Le regole hanno lo scopo di bloccare il classico metodo “timewarp” e una variante correlata nota come attacco Murch-Zawy, lasciando inalterato il mining ordinario.

Il BIP-54 mira inoltre a proteggere gli operatori di nodi più piccoli

La seconda modifica riguarda i “poison block”, blocchi validi progettati deliberatamente per richiedere un tempo insolitamente lungo per la verifica da parte dei computer. Alcuni script di transazione Bitcoin più datati possono richiedere minuti o addirittura ore di elaborazione su hardware standard. Un malintenzionato potrebbe utilizzarli per rallentare la rete, aumentare la probabilità che i miner sprechino risorse su blocchi obsoleti e rendere più difficile per gli utenti gestire nodi Bitcoin indipendenti. Il BIP-54 limiterebbe le transazioni più vecchie, precedenti a Segregated Witness (SegWit), a 2.500 operazioni di firma legacy. Le operazioni di firma sono i controlli crittografici utilizzati per dimostrare che qualcuno è autorizzato a spendere bitcoin. Le transazioni normali ne utilizzano molte meno, e le transazioni SegWit e Taproot non sarebbero soggette a questo limite. I sostenitori stimano che la modifica potrebbe ridurre il carico di verifica nel caso peggiore di circa 40 volte in alcuni casi.

La terza modifica risolve un problema nell’albero di Merkle di Bitcoin, il sistema che raggruppa le transazioni in un unico riepilogo per ogni blocco. Una transazione della lunghezza esatta di 64 byte può assomigliare a una parte interna di tale struttura. Ciò crea un modo per falsificare una prova che potrebbe indurre alcuni portafogli con verifica semplificata dei pagamenti (SPV) ad accettare una transazione che non è mai stata confermata.

Il BIP-54 renderebbe semplicemente non valide le transazioni da 64 byte. Tali transazioni sono da anni non standard e vengono utilizzate raramente. I sostenitori della proposta sostengono che vietarle risolva il problema di fondo in modo più netto rispetto all’aspettarsi che ogni portafoglio leggero utilizzi una soluzione alternativa.

Una norma definitiva potrebbe semplificare il futuro di Bitcoin

La quarta modifica riguarda le transazioni coinbase, ovvero quelle transazioni speciali attraverso le quali i miner ricevono i bitcoin appena emessi e le commissioni di transazione. Nei primi anni di Bitcoin, transazioni coinbase identiche apparivano in più di un blocco, il che causava la scomparsa degli output non spesi della transazione precedente. Bitcoin ha aggiunto dei controlli per impedire che ciò si ripetesse, ma tali controlli aumentano la complessità della convalida dei blocchi.

Il BIP-54 richiederebbe che le nuove transazioni coinbase includano impostazioni legate all’altezza del blocco, ovvero alla sua posizione nella blockchain. Ciò garantirebbe l’unicità in futuro e potrebbe alla fine consentire ai nodi di rimuovere i vecchi controlli sulle transazioni duplicate. La modifica potrebbe semplificare la convalida e supportare progetti futuri volti a ridurre l’onere di archiviazione legato alla gestione di un nodo completo.

La posizione di F2pool rende più difficile l’attivazione

Le argomentazioni tecniche a favore del BIP-54 non hanno posto fine al dibattito politico. Wang Chun, cofondatore del principale mining pool F2pool, ha dichiarato il 10 agosto di non sostenere la proposta. Ha spiegato che F2Pool aggiorerebbe i propri nodi di mining se il BIP-54 raggiungesse la maggioranza richiesta attraverso un processo di attivazione standard BIP-9, ma il pool non invierà alcun segnale in tal senso in anticipo.

L’obiezione di Chun, già espressa ad aprile su X, riguarda principalmente la procedura e le priorità. Egli ha sostenuto che raggruppare quattro modifiche insieme equivale a includere misure non correlate in un unico disegno di legge. Ritiene che molti dei rischi siano troppo remoti per giustificare il coordinamento, gli aggiornamenti software e l’attenzione della comunità necessari per un soft fork, che modifica le regole di Bitcoin in un modo che i software più vecchi potrebbero non essere in grado di applicare.

I sostenitori vedono il raggruppamento in modo diverso. Essi sostengono che ogni modifica al consenso comporti un costo sociale elevato, quindi combinare diverse correzioni difensive può ridurre il numero di difficili interventi di attivazione a livello di rete. Affermano inoltre che l’aumento di valore di Bitcoin offra agli aggressori ulteriori motivi per esplorare punti deboli che un tempo sembravano puramente teorici.

Il fallimento del BIP-110 aggiunge nuova cautela

Il dibattito arriva subito dopo il fallimento del BIP-110, una proposta separata che mirava a limitare temporaneamente i dati non finanziari memorizzati nelle transazioni Bitcoin. La proposta prendeva di mira pratiche associate alle iscrizioni Ordinals, ai dati OP_RETURN di grandi dimensioni e ad alcune forme di archiviazione dei dati basate su Taproot. La sua soglia di attivazione più bassa non è riuscita ad attirare un sostegno significativo da parte dei miner, e una small chain che applicava la proposta si è arenata dopo aver prodotto solo una manciata di blocchi. Quell’episodio non rende il BIP-54 una proposta simile. Il BIP-54 non aggiunge né rimuove funzionalità di script generiche, né rappresenta un percorso verso i covenant o l’OP_CAT, proposte che amplierebbero le opzioni di spesa programmabili di Bitcoin. Tuttavia, il BIP-110 ha dimostrato quanto rapidamente un aggiornamento controverso possa trasformarsi in un dibattito più ampio su chi debba decidere il futuro di Bitcoin.

Il BIP-54 è già attivo per i test su Bitcoin Inquisition, un ambiente di test basato su Signet, e le attuali versioni di Bitcoin Core hanno adottato le relative misure di protezione. Alcuni pool di mining, tra cui MARA e ViaBTC, hanno iniziato volontariamente a generare transazioni coinbase compatibili. Tuttavia, i parametri formali di attivazione non sono stati ancora definiti e il voto sulla mainnet rimane aperto.

La domanda successiva è se gli sviluppatori, la comunità, le aziende, gli operatori di nodi e i miner possano concordare sul fatto che risolvere rischi noti ma raramente sfruttati valga un ulteriore sforzo di coordinamento a livello di hard fork. I lettori dovrebbero prestare attenzione a una proposta formale di segnalazione BIP-9, a ulteriori annunci sulla prontezza dei miner e al fatto che la resistenza di F2pool possa impedire l’ampio sostegno che gli aggiornamenti di Bitcoin hanno tradizionalmente richiesto.