blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il 10 agosto 2026, alle 21:05 UTC, è stata unita a un repository GitHub chiamato bitcoin/bips una modifica minuscola. La pull request n. 2245, aperta il giorno prima da Jon Atack, uno dei cinque editor dei BIP, cambiava una sola parola nell’intestazione del BIP 110: il suo stato diventava «Closed», cioè chiuso. Due giorni prima, un soft fork descritto da quel documento aveva spinto una manciata di nodi su una catena che si era fermata quasi subito. La pull request non impediva a nessuno di continuare a usare quelle regole. Registrava soltanto, nell’archivio di ogni Bitcoin Improvement Proposal (i «BIP bitcoin», in breve), che il tentativo era finito.
Anche quella sola parola ha raccolto 32 commenti. Editor e revisori hanno discusso se un soft fork fallito dovesse passare dallo stato «Deployed» (in uso), visto che esisteva un software che lo applicava, prima di poter essere chiuso. Greg Maxwell, sviluppatore di lungo corso, ha contestato l’intero dibattito: «Il repository dei BIP non è assolutamente la governance di bitcoin», ha scritto nella discussione (traduzione nostra). Due giorni dopo l’unione, Greg Tonoski, sostenitore del BIP-110, ha obiettato che le regole si erano attivate all’altezza indicata nella specifica e che i nodi che le applicavano ancora erano liberi di farlo.
Bitcoin non ha consiglio di amministrazione, amministratore delegato né voto, eppure le sue regole sono cambiate, nel modo più visibile con SegWit nel 2017 e con Taproot nel 2021. Ogni cambiamento è passato dagli stessi livelli: un documento pubblico, un codice che pochi maintainer uniscono, un metodo per attivare le regole e migliaia di operatori che decidono che cosa far girare. Quando i livelli non sono d’accordo, nasce uno scontro.
Questa lezione segue la nostra lezione sui layer 2 e sulle sidechain di bitcoin, che mostrava quanto si possa costruire senza toccare le regole di base. Un richiamo prima di proseguire: un soft fork restringe soltanto le regole, quindi i nodi non aggiornati continuano a seguire la catena finché la maggior parte della potenza di calcolo applica le nuove regole, mentre un hard fork le allarga o le cambia e lascia indietro i nodi non aggiornati. La nostra guida a soft fork, hard fork e divisioni della catena spiega entrambi, mostra come segnalano i miner e racconta la divisione del BIP-110 dell’8 agosto 2026 blocco per blocco. Qui si parla di chi ha deciso, e come.
Governance bitcoin: chi controlla Bitcoin, quattro poteri e nessun proprietario
Un buon modo di leggere la governance di Bitcoin è separare quattro poteri che spesso si confondono. Gli sviluppatori propongono modifiche e scrivono il codice. I nodi completi, gestiti da chiunque, controllano ogni blocco in base alle regole del software che i loro proprietari hanno scelto di installare. I miner ordinano le transazioni nei blocchi e, durante un soft fork, segnalano se sono pronti ad applicare le nuove regole. Gli utenti economici (exchange, custodi, esercenti, chi detiene bitcoin) decidono quale catena chiamano bitcoin e accettano come pagamento. Nella pratica nessun gruppo è riuscito a imporre un cambiamento agli altri tre, e le modifiche arrivano lentamente.
La nostra lezione su che cosa fa un nodo e perché conta spiega il lato dell’applicazione delle regole. In breve: una regola esiste solo quando il software che le persone usano davvero la applica. Un codice che nessuno installa non cambia nulla, e un blocco che i nodi rifiutano non vale niente per il miner che l’ha prodotto.
Dentro il progetto si descrive questo equilibrio con parole diverse. Il README del repository dei BIP dice che «in ultima analisi l’accettazione e l’adozione spettano agli utenti di Bitcoin» (traduzione nostra) e rimanda a una pagina sulla «maggioranza economica». Una dichiarazione firmata nel giugno 2025 da 31 contributori di Bitcoin Core afferma che la rete è definita dai suoi utenti e che «i contributori di Bitcoin Core non sono nella posizione di imporre» quali siano (traduzione nostra), riferendosi alle politiche che gli utenti applicano. I sostenitori del BIP-110 danno più peso agli operatori dei nodi: Tonoski, nella pull request del BIP 110, ha detto che circa 18.000 nodi di validazione completa non respingevano il soft fork, una cifra da lui fornita senza fonte. Altri indicano la potenza di calcolo, che nell’agosto 2026 ha deciso di fatto quale catena continuava a crescere. Nessuna di queste posizioni è una dottrina ufficiale, perché non esiste un ufficio che possa emanarla.
Il confronto con la governance a token della finanza decentralizzata è istruttivo: lì i possessori di un token di governance votano e uno smart contract esegue il risultato. Bitcoin non ha un token del genere né un voto on-chain. I suoi «voti» sono scelte di software fatte una macchina alla volta.
Cos’è un BIP bitcoin e come nasce, vive e muore
Un Bitcoin Improvement Proposal, o BIP, è un documento di progettazione. Descrive una modifica al protocollo, al funzionamento del software che ruota attorno a Bitcoin o al processo stesso, in un formato fisso con intestazione, motivazione, specifica e una sezione sulla retrocompatibilità. Alcuni numeri sono familiari anche a chi non ne ha mai letto uno: il BIP 39 è lo standard che trasforma il segreto di un wallet nelle 12 o 24 parole di una seed phrase, e il BIP 141 è il documento principale di SegWit. Il BIP 39, di gran lunga il più noto a chi usa un wallet, è una proposta tra oltre 200 nell’elenco del repository.
Un repository pubblico dove pubblicare non vuol dire approvare
I BIP vivono nel repository bitcoin/bips su GitHub. Il suo README fissa l’ordine delle cose: l’autore descrive prima l’idea sulla mailing list bitcoindev, raccoglie osservazioni e apre una pull request solo quando la bozza ha fatto progressi sostanziali. Gli autori non scelgono il proprio numero. Lo assegna un editor dei BIP quando la proposta rispetta i criteri editoriali, e la pubblica unendo la pull request.
Il README è esplicito su che cosa significhi la pubblicazione. Avere un BIP nel repository «non indica che sia una buona idea, che abbia il consenso della comunità o che stia per essere adottato», dice (traduzione nostra), e gli editor devono pubblicare con larghezza e restare fuori dalle decisioni prese a nome della comunità. Quando gli editor non si accordano sulla pubblicazione di una proposta controversa, si applica l’opzione prudente e la proposta viene chiusa. I cinque editor elencati nel BIP 3 al 9 novembre 2026 sono Bryan Bishop, Jon Atack, Mark «Murch» Erhardt, Olaoluwa Osuntokun e Ruben Somsen.
Draft, Complete, Deployed, Closed: il ciclo di vita del BIP 3
Il processo è descritto a sua volta da un BIP. Per quasi nove anni è stato il BIP 2, scritto da Luke Dashjr e assegnato nel febbraio 2016, con stati come Proposed, Final, Rejected, Withdrawn e Replaced. Il suo successore, il BIP 3, «Updated BIP Process», scritto da Murch e assegnato il 9 gennaio 2025, ha oggi lo stato Deployed, mentre il BIP 2 è segnato come Closed. Le vecchie etichette compaiono ancora negli articoli più datati e vanno lette come storia.
Il BIP 3 mantiene quattro stati. Un Draft è una proposta in lavorazione; se si ferma per un anno o lascia senza risposta le osservazioni, chiunque può proporne la chiusura, e questa avviene a meno che gli autori non dichiarino entro quattro settimane che intendono proseguire. Complete significa che gli autori ritengono solida la specifica e raccomandano l’adozione; un BIP di specifica, per arrivarci, richiede un’implementazione di riferimento funzionante e vettori di test, e Complete è lo stato finale della maggior parte dei BIP informativi andati a buon fine. Deployed è riservato a un BIP consolidato e di cui è dimostrato l’uso attivo, e «una volta Deployed, il BIP è considerato definitivo» (traduzione nostra). Closed copre ciò che ha solo interesse storico. Niente viene cancellato: un BIP chiuso resta nell’archivio con una riga di registro delle modifiche che ne spiega il motivo.
La regola su Deployed è ciò su cui si è discusso nella pull request del BIP 110. Il BIP 3 ammette come prova di uso attivo «un progetto consolidato che ha distribuito il supporto al BIP in versioni del software per la mainnet» (traduzione nostra), e Knots, un programma per nodi, aveva distribuito le regole; ammette anche che i criteri di attivazione di un soft fork siano soddisfatti sulla rete, cosa che sulla catena principale non era avvenuta. Murch, che in un primo momento aveva accettato il passaggio da Deployed, il 10 agosto ha cambiato posizione scrivendo che considerare un tentativo di attivazione fallito come un dispiegamento «sembra un po’ strano» (traduzione nostra). La pull request è stata riscritta per andare direttamente a Closed e unita quella sera. Il registro delle modifiche del BIP riporta ora, alla versione 1.0.1 datata 9 agosto 2026, «Mark as Closed, following a chain split with stalled mining» (segnato come chiuso, dopo una divisione della catena con estrazione ferma).
Non tutti i BIP toccano le regole
Solo una minoranza dei BIP modifica il consenso, come il BIP 141 per SegWit o i BIP 340 e 341 per le firme Schnorr e Taproot, tutti Deployed. Altri sono standard che i wallet seguono senza alcun fork, come il BIP 39 e il BIP 32 per i wallet gerarchici deterministici. Il BIP 3 divide i documenti in tre tipi: Specification, Informational (dove sono archiviati i metodi di attivazione BIP 9 e BIP 8) e Process, come lo stesso BIP 3. La tabella del repository assegna a ogni proposta un livello, un tipo e uno stato, ed è il modo più rapido per capire a che punto sia.
Chi scrive il codice: Bitcoin Core, i suoi maintainer e gli altri client
La maggior parte dei nodi raggiungibili usa Bitcoin Core, il software discendente del client originale di Satoshi Nakamoto. Cambiare Bitcoin, in pratica, significa di solito cambiare Bitcoin Core, e le sue regole per accettare il codice contano quasi quanto il processo dei BIP.
Come una modifica entra in Bitcoin Core
Il file CONTRIBUTING del progetto esordisce dicendo che non esiste «alcun particolare concetto di “sviluppatori di Bitcoin Core” nel senso di persone privilegiate» (traduzione nostra). Chiunque può aprire una pull request; chiunque può rivederne una. I revisori usano un vocabolario breve: un Concept ACK sostiene l’idea, un Approach ACK sostiene l’idea e il modo in cui è realizzata, un NACK la respinge. Un NACK deve avere una motivazione, e il file precisa che i NACK senza ragioni possono essere ignorati.
Unire il codice è un’altra faccenda. Lo stesso file dice che l’unione di una pull request «spetta ai merge maintainer del progetto» (traduzione nostra), che valutano se rispetta i principi del progetto, i suoi standard e «il consenso generale dei contributori». Per le modifiche al consenso l’asticella è più alta: queste patch devono essere precedute da un’ampia discussione sulla mailing list, avere un BIP numerato e godere di un consenso tecnico largamente percepito. Il BIP è un presupposto, non un biglietto d’ingresso: una proposta numerata può restare per anni senza essere unita.
Una manciata di merge maintainer e nessun aggiornamento automatico
Il progetto ha un piccolo gruppo di maintainer che detengono chiavi in grado di unire codice nel repository principale. Protos ha riferito nel gennaio 2026 che sei persone detenevano chiavi fidate di questo tipo, ma i resoconti pubblici su chi le detenga sono cambiati più di una volta nel corso del 2026, ed è meglio controllare l’elenco sulle pagine del progetto che nelle cronache giornalistiche. Non cambia invece il limite del loro potere: unire un codice in Bitcoin Core non lo installa da nessuna parte.
La dichiarazione dei contributori del giugno 2025 lo dice chiaramente: il progetto evita gli aggiornamenti automatici, quindi «nessuna entità può imporre unilateralmente modifiche agli utenti di Bitcoin Core» (traduzione nostra). Ogni operatore decide quando aggiornare, se aggiornare o se passare a un altro software. Per questo le vecchie versioni restano in uso per anni.
Bitcoin Core e Knots, btcd e libbitcoin: il confronto
Bitcoin Core non è l’unico nodo completo. Bitcoin Knots, il cui maintainer principale è Luke Dashjr, si basa sul codice di Bitcoin Core con opzioni aggiuntive, molte delle quali riguardano quali transazioni un nodo inoltra, come -datacarriercost. Nel maggio 2026 Knots ha pubblicato due build affiancate: la 29.3.knots20260507, le cui note di rilascio dicono che «non supporta il prossimo aggiornamento di rete BIP110 (RDTS)» (traduzione nostra), e la 29.3.knots20260508, che includeva il BIP-110 (chiamato RDTS da Knots) e chiedeva agli utenti dei server di aggiungere consensusrules=rdts alla configurazione. Le versioni successive hanno mantenuto quelle regole. Le note della 29.5.knots20260508, l’ultima versione elencata sul sito di Knots il 9 novembre 2026, descrivono anche un «long coinbase maturity softfork» (soft fork a maturità lunga della coinbase) che ritarda il momento in cui i coin appena estratti possono essere spesi; Bitcoin Core non ha una regola simile.
btcd è un’implementazione indipendente di nodo completo scritta in Go, e libbitcoin è un insieme separato di librerie C++ con un proprio nodo. Entrambi sono molto meno diffusi sulla rete.
Quanti nodi usino ciascun software si può solo stimare, perché un nodo annuncia da sé la propria stringa «user agent», che può essere modificata, e i nodi che non accettano connessioni in entrata o stanno dietro Tor spesso sfuggono. La tabella seguente è un conteggio delle stringhe user agent in un’istantanea del crawler Bitnodes (btcnodes.io), non un censimento.
| Software (stringa user agent) | Nodi | Quota |
|---|---|---|
| Stringhe che contengono «Knots» | 2.066 | 9,9% |
| Altre stringhe «/Satoshi:» (Bitcoin Core) | 18.701 | 89,8% |
| Altri client (btcd e altri) | 65 | 0,3% |
| Totale nodi raggiungibili | 20.832 | 100% |
| Stringa singola più comune: /Satoshi:32.1.0/ | 4.323 | 20,8% |
| Stringa Knots più comune: /Satoshi:29.3.0/Knots:20260507/ | 1.387 | 6,7% |
Fonte: istantanea dell’API di Bitnodes del 9 novembre 2026, ore 08:56 UTC, conteggio di Coindaro. Gli user agent sono dichiarati dai nodi stessi.
Le stringhe dicono qualcosa anche sull’episodio BIP-110. Nella stessa istantanea, 1.413 stringhe Knots portavano l’etichetta 20260507, la build che lasciava fuori il BIP-110, contro 4 con l’etichetta 20260508 delle build che lo includevano. Una stringa è autodichiarata e non prova quali regole un nodo applichi, ma suggerisce che la maggior parte dei nodi Knots raggiungibili sia rimasta sulla versione senza il soft fork.
Altri rilevamenti danno numeri diversi. Un’istantanea del 18 ottobre 2026 del Karlsruhe Institute of Technology, usata nel nostro servizio sui nodi Bitcoin Core non più aggiornati, contava 1.096 stringhe Knots su 9.691 peer, circa l’11%. I tracker usano metodi diversi e raggiungono nodi diversi, quindi la differenza tra due di essi non è una tendenza.
Chi paga gli sviluppatori
Non c’è un’azienda bitcoin che paghi gli sviluppatori di Bitcoin. I contributori sono finanziati da un mosaico di organizzazioni non profit, aziende e borse di ricerca. OpenSats, ente di beneficenza statunitense 501(c)(3) con un consiglio di nove persone, dichiara sul proprio sito di aver assegnato 21.646.000 dollari a progetti liberi e open source e di aver inviato circa 24,6 miliardi di sat a 252 beneficiari in 40 paesi, cifre mostrate senza data e lette il 9 novembre 2026; Bitcoin Core è tra i progetti elencati. Brink, fondata nel 2020 con il sostegno finanziario di John Pfeffer e Wences Casares, dichiara di essere finanziata al 100% da donazioni e gestisce un programma di borse per nuovi contributori e finanziamenti per ingegneri di protocollo già affermati.
Altri contributori lavorano per aziende. Chaincode Labs descrive il proprio scopo in una riga: «esiste per sostenere Bitcoin» (traduzione nostra). Spiral, chiamata Square Crypto fino al cambio di nome del 1° dicembre 2021, si presenta come un’iniziativa di Block per il bene comune e, nell’annunciare il nuovo nome, ha scritto che deve essere indipendente dal proprio benefattore aziendale. Le aziende donano anche tramite queste organizzazioni: il 16 ottobre 2026 OpenSats ha annunciato la prima donazione nell’ambito del sostegno ricorrente di Strive al suo Red Team Fund. Non esiste un conteggio pubblico e autorevole degli sviluppatori finanziati di Bitcoin Core.
Dove si discutono le proposte: mailing list, forum e GitHub
Quasi tutto il confronto avviene in tre luoghi. La mailing list bitcoindev è la più antica. Dopo case precedenti che comprendevano SourceForge e la Linux Foundation, è passata a Google Groups, con una migrazione annunciata dal moderatore Bryan Bishop in un’email datata 9 febbraio 2024; il suo archivio è replicato fuori da Google, su gnusha.org e mirror.b10c.me, e si può quindi leggere senza account. Il forum Discourse delvingbitcoin.org ha come slogan «A place to dig deep into Bitcoin» (un posto per scavare a fondo in Bitcoin), con categorie su progettazione del protocollo, implementazione ed economia, e molte discussioni di progettazione ora cominciano lì. GitHub ospita la revisione del codice vera e propria, nel repository bitcoin/bitcoin per Core e in bitcoin/bips per i documenti.
Seguire una proposta nella pratica richiede pochi passaggi, nessuno dei quali ha bisogno di permessi:
- Trova il numero del BIP e il suo stato nella tabella del README di bitcoin/bips, e leggi l’intestazione e il registro delle modifiche del documento.
- Cerca il nome della proposta nell’archivio di bitcoindev e su delvingbitcoin.org per leggere gli argomenti a favore e contro, con le risposte degli autori.
- Cerca una pull request di implementazione in Bitcoin Core o in un altro client e verifica se include parametri di attivazione per la mainnet o solo per le reti di prova.
- Leggi la newsletter settimanale di Bitcoin Optech (in inglese) e le sue pagine tematiche, come quella sull’attivazione dei soft fork, che riassumono le discussioni con i link.
- Controlla quale versione del tuo software per nodi stai usando, perché è quella a decidere quali regole il tuo nodo applica.
Come si attiva un soft fork bitcoin: i metodi a confronto
Accordarsi su una modifica è metà del problema. L’altra metà è attivarla senza spaccare la catena. I soft fork di Bitcoin sono stati attivati di solito contando i segnali dei miner nel campo versione dei blocchi, il meccanismo che la nostra guida ai fork illustra. Dopo ogni scontro è cambiato chi può fermare il conteggio: i miner o gli operatori dei nodi.
Il BIP 9, di Pieter Wuille, assegnato nell’ottobre 2015, è il progetto di base: 29 bit di versione utilizzabili, una finestra con inizio e scadenza, e fallimento se la scadenza arriva per prima. Nel 2017 ha mostrato che una minoranza della potenza di calcolo poteva bloccare una modifica non segnalandola. Il BIP 8, di Shaolin Fry e Luke Dashjr, conta in altezze di blocco e aggiunge un’opzione chiamata lockinontimeout, o LOT: con LOT impostato su true i miner devono segnalare nell’ultimo periodo, così la modifica si consolida entro la scadenza qualunque cosa vogliano. Il BIP 8 ha lo stato Complete; un dispiegamento di Taproot con LOT=true, il BIP 343, è ora Closed, e il suo registro delle modifiche cita «l’assenza di dispiegamenti noti» (traduzione nostra).
| Metodo | Soglia | Orologio | I miner possono bloccarlo? | Usato per |
|---|---|---|---|---|
| BIP 9, bit di versione | 95% (1.916 blocchi su 2.016) | Timestamp, con scadenza | Sì: fallisce alla scadenza | Dispiegamento di SegWit 2016-2017 |
| BIP 148, soft fork attivato dagli utenti | Nessuna: i nodi rifiutano i blocchi senza segnale dal 1° ago 2017 | Data fissa | No, se abbastanza nodi e acquirenti seguono | Forzare la segnalazione di SegWit, 2017 |
| BIP 91, attivazione a soglia ridotta | 80% (269 blocchi su 336) | Timestamp | Sì, sotto l’80% | Consolidare SegWit, luglio 2017 |
| BIP 8 con LOT=true | Configurabile | Altezze di blocco | No: segnalazione obbligatoria alla fine | Mai dispiegato sulla mainnet |
| Speedy Trial (variante del BIP 9) | 90% (1.815 su 2.016) | Dal 24 apr all’11 ago 2021, altezza minima di attivazione | Sì, entro una finestra breve | Taproot, 2021 |
| BIP-110 (BIP 9 modificato) | 55% (1.109 su 2.016), poi segnalazione obbligatoria | Altezze di blocco da 961.632 | Solo con la divisione della catena | BIP-110, agosto 2026: fallito |
Fonti: BIP 8, 9, 91, 110, 148, 341 e 343 nel repository bitcoin/bips, letti il 9 novembre 2026.
Emergono due schemi. I metodi che lasciano ai miner la possibilità di bloccare una modifica (BIP 9, Speedy Trial) non hanno mai spaccato la catena quando sono falliti: la modifica semplicemente non è avvenuta. I metodi che la impongono (BIP 148, BIP 8 con LOT=true, la segnalazione obbligatoria del BIP-110) funzionano solo se la maggior parte dell’economia e della potenza di calcolo li segue, e spaccano la catena se non succede. Come SegWit e Taproot abbiano poi cambiato le transazioni lo spiega la nostra lezione su SegWit e Taproot; qui conta solo la strada verso l’attivazione.
Tre scontri sulle regole di Bitcoin, con le date
| Data | Evento |
|---|---|
| 22 giu 2015 | Assegnato il BIP 101 (blocchi da 8 MB, soglia del 75% dei miner); distribuito in Bitcoin XT ad agosto |
| 12-13 set 2015 | Workshop Scaling Bitcoin, Montréal |
| 6-7 dic 2015 | Scaling Bitcoin, Hong Kong: Pieter Wuille presenta Segregated Witness |
| 23 mag 2017 | Pubblicato il New York Agreement: SegWit all’80% sul bit 4, un hard fork a 2 MB entro sei mesi |
| 21-23 lug 2017 | Il BIP 91 si consolida (blocco 476.784) e si attiva (blocco 477.120) |
| 1° ago 2017 | Data di inizio del BIP 148; Bitcoin Cash si separa |
| 9 ago 2017 | SegWit consolidato (periodo che inizia al blocco 479.808) |
| 24 ago 2017 | SegWit attivo, blocco 481.824, ore 01:57 UTC |
| 8 nov 2017 | Hard fork SegWit2x sospeso |
| 13 giu 2021 | Taproot consolidato (periodo che termina al blocco 687.455, ore 20:06 UTC) |
| 14 nov 2021 | Taproot attivo, blocco 709.632, ore 05:15 UTC |
| 27 apr 2025 | Aperta la pull request n. 32359 per eliminare i limiti OP_RETURN di Bitcoin Core (chiusa senza unione il 12 maggio) |
| 6 giu 2025 | Dichiarazione di 31 contributori di Bitcoin Core sulla politica di inoltro |
| 9 giu 2025 | Unita la pull request n. 32406 «policy: uncap datacarrier by default» |
| 10 ott 2025 | Rilasciato Bitcoin Core 30.0 con il nuovo valore predefinito |
| 3 dic 2025 | Assegnato il numero BIP 110 |
| 8 ago 2026 | Segnalazione obbligatoria del BIP-110 al blocco 961.632; la catena di minoranza si ferma |
| 10 ago 2026 | BIP 110 segnato come Closed (unita la pull request n. 2245) |
Fonti: testi dei BIP, scalingbitcoin.org, cronache di maggio e novembre 2017, note di rilascio di Bitcoin Core e GitHub, orari dei blocchi da mempool.space, letti il 9 novembre 2026.
2015-2017: la guerra sulla dimensione dei blocchi e SegWit
Il primo scontro riguardava la capacità. I blocchi di Bitcoin erano limitati a 1 MB, e un fronte voleva alzare il tetto con un hard fork. Il BIP 101, di Gavin Andresen, assegnato il 22 giugno 2015, proponeva blocchi da 8 MB da gennaio 2016, con raddoppio ogni due anni, attivati quando 750 blocchi su 1.000 segnalavano. Il testo spiega la soglia del 75% come un modo per evitare che un grande mining pool avesse un veto di fatto. Bitcoin XT, un client alternativo, lo distribuì nell’agosto 2015. Non si avvicinò mai all’attivazione, e il BIP 101 è oggi Closed.
Seguirono due workshop Scaling Bitcoin, a Montréal nel settembre 2015 e a Hong Kong in dicembre, dove Pieter Wuille presentò Segregated Witness, un soft fork che spostava i dati delle firme fuori dalla parte del blocco conteggiata dal vecchio limite. SegWit fu distribuito con il BIP 9 in Bitcoin Core nel 2016, ma la segnalazione dei miner rimase per mesi molto al di sotto del 95%, mentre molti grandi miner sostenevano blocchi più grandi.
Nel 2017 due pressioni sbloccarono lo stallo. Gli operatori dei nodi e alcune aziende si strinsero attorno al BIP 148, il soft fork attivato dagli utenti descritto nella nostra guida ai fork. Il 23 maggio 2017, dopo un incontro tenuto attorno alla conferenza Consensus di New York, un gruppo di aziende e miner pubblicò il New York Agreement, che abbinava l’attivazione di SegWit all’80% sul bit 4 a un hard fork a 2 MB entro sei mesi. Il BIP 91, di James Hilliard, realizzò la prima metà con una soglia dell’80% su 336 blocchi e fu attivo dal 23 luglio. Il riepilogo di Bitcoin Optech su quel periodo osserva che quanto abbia pesato ciascuna pressione è ancora oggetto di discussione.
SegWit si consolidò il 9 agosto e divenne attivo il 24 agosto 2017; il fronte dei blocchi grandi aveva già lanciato Bitcoin Cash il 1° agosto. La seconda metà dell’accordo, l’hard fork a 2 MB noto come SegWit2x, fu sospesa l’8 novembre 2017 con un’email di Mike Belshe, amministratore delegato di BitGo, cofirmata da altri cinque sostenitori, che scrisse di non aver «costruito un consenso sufficiente per un aggiornamento pulito della dimensione dei blocchi in questo momento» (traduzione nostra). Le aziende e i miner che avevano firmato a maggio non avevano modo di far eseguire ai nodi la seconda metà.
2021: Taproot e il compromesso «Speedy Trial»
Taproot, l’aggiornamento che ha aggiunto le firme Schnorr e un nuovo tipo di output, incontrava poche obiezioni tecniche. Lo scontro riguardava il metodo. Un fronte voleva il BIP 8 con LOT=true, perché i miner non potessero ritardarlo; un altro voleva LOT=false, perché un’attivazione fallita non potesse spaccare la catena. Il BIP 343 registra che il compromesso, soprannominato Speedy Trial, fu proposto da Russell O’Connor e illustrato sulla mailing list da David Harding: una finestra breve, una soglia del 90% e un’altezza minima di attivazione, così che l’economia avesse mesi per aggiornarsi dopo il consolidamento.
La versione 0.21.1 di Bitcoin Core lo distribuì, i miner superarono la soglia a metà giugno 2021 e Taproot divenne attivo a novembre senza divisioni. Taproot ha poi reso meno costoso scrivere le iscrizioni di Ordinals, Runes e BRC-20, preparando il terzo scontro.
2025-2026: OP_RETURN, Bitcoin Core v30 e BIP-110
Il terzo scontro è nato da un’impostazione dei nodi, non da una regola di consenso. Bitcoin Core inoltrava transazioni con al massimo 83 byte in un output OP_RETURN, un limite di policy e non una regola di validità: i miner potevano includerne di più grandi, e alcuni lo facevano. Il 27 aprile 2025 Peter Todd aprì la pull request n. 32359 per rimuovere quei limiti; fu chiusa senza essere unita il 12 maggio. Una seconda, la n. 32406, «policy: uncap datacarrier by default», aperta il 2 maggio e unita il 9 giugno 2025, è quella che le note di rilascio di Bitcoin Core 30.0 citano.
Bitcoin Core 30.0, rilasciato il 10 ottobre 2025, ha portato il valore predefinito di -datacarriersize a 100.000 byte, il che in pratica elimina il tetto perché prima si raggiunge la dimensione massima della transazione, e ha consentito più output OP_RETURN per transazione. Gli operatori possono ancora impostare -datacarriersize=83 per ripristinare il vecchio limite. Prima del rilascio, 31 contributori avevano spiegato le proprie ragioni in una dichiarazione datata 6 giugno 2025: la policy di inoltro dovrebbe prevedere ciò che i miner estrarranno, anziché cercare di bloccare transazioni con una domanda costante. Aggiungevano: «Questo non significa approvare o giustificare l’uso non finanziario dei dati» (traduzione nostra).
I critici, molti dei quali utenti di Knots, sostennero che la modifica invitava più dati non finanziari nei blocchi, e alcuni operatori cambiarono software per i nodi. Alcuni portarono poi la disputa dalla policy al consenso. Il BIP 110, «Reduced Data Temporary Softfork», dello pseudonimo Dathon Ohm, ebbe un numero il 3 dicembre 2025. Proponeva di trasformare per circa un anno i limiti sui dati in regole di consenso, con una soglia del 55% e segnalazione obbligatoria dal blocco 961.632. Knots lo distribuì in una build separata; Bitcoin Core no.
I miner non lo seguirono. L’8 agosto 2026 i nodi che applicavano il BIP-110 si divisero su una catena che si fermò, come racconta blocco per blocco la guida ai fork. Il 12 agosto Murch contava quattro blocchi sulla punta di minoranza contro 533 sulla catena principale, e scrisse nella pull request del BIP 110 che il dispiegamento «è stato nettamente respinto dalla rete Bitcoin» (traduzione nostra). Tonoski e altri sostenitori hanno mantenuto la loro posizione: il soft fork si era attivato come specificato.
Le proposte di soft fork bitcoin in discussione a novembre 2026
Si discute di diversi soft fork, e il repository mostra a che punto sia ciascuno. Nessuno ha parametri di attivazione per la mainnet in una versione rilasciata di Bitcoin Core al 9 novembre 2026, e nessuno è in programma.
| BIP | Che cosa farebbe | Stato nel repository |
|---|---|---|
| BIP 54, Consensus Cleanup (Antoine Poinsot, Matt Corallo) | Corregge il bug timewarp, limita il tempo di validazione del blocco nel caso peggiore, rende non valide le transazioni da 64 byte, impedisce le transazioni duplicate | Complete |
| BIP 119, CHECKTEMPLATEVERIFY (Jeremy Rubin) | Nuovo opcode che fissa in anticipo gli output della transazione che spende un coin | Draft |
| BIP 348, CHECKSIGFROMSTACK (Brandon Black, Jeremy Rubin) | Opcode in tapscript che verifica una firma su dati arbitrari | Draft |
| BIP 347, OP_CAT in tapscript (Ethan Heilman, Armin Sabouri) | Reintroduce la concatenazione degli elementi dello stack in tapscript, con limite di 520 byte | Complete (dal 1° marzo 2026) |
| BIP 360, Pay-to-Merkle-Root (P2MR) | Nuovo tipo di output simile a Taproot ma senza il percorso della chiave, come difesa da futuri attacchi quantistici | Draft |
| BIP 361, Post Quantum Migration and Legacy Signature Sunset (Jameson Lopp e altri) | Fine graduale dell’invio verso, poi della spesa da, output vulnerabili ai computer quantistici | Draft (Informational) |
Fonte: intestazioni di ciascun BIP nel repository bitcoin/bips, lette il 9 novembre 2026.
Il BIP 54 è quello andato più avanti. I suoi autori dicono che raggruppare più correzioni ammortizza il costo fisso di dispiegare un soft fork, e il limite di 2.500 operazioni di firma che Bitcoin Core 30.0 ha aggiunto alla propria policy di inoltro è stato introdotto, secondo le note di rilascio, per preparare un possibile dispiegamento del BIP 54. Una pull request che implementa il BIP 54 «senza attivazione sulla mainnet» è stata aperta in Bitcoin Core il 24 luglio 2026 ed era ancora aperta il 9 novembre 2026. I tempi di attivazione sono questione di stime personali, non di un piano.
Le proposte legate al calcolo quantistico sono le più contese. Il BIP 361 non sta in piedi da solo: seguirebbe l’adozione di un tipo di output post-quantistico, non ancora specificato, e la sua prima fase vieterebbe di inviare fondi a indirizzi vulnerabili ai computer quantistici. Frederic Fosco, cofondatore di OP_NET, ha detto a Decrypt nell’aprile 2026 che un congelamento imposto dal protocollo «è confisca, punto e basta»; Lopp, citato nello stesso articolo, ha detto della proposta: «L’ho scritta perché l’alternativa mi piace ancora meno» (traduzioni nostre). CTV e CHECKSIGFROMSTACK sono spesso discussi insieme come pacchetto di covenant, con sostenitori e oppositori sulla mailing list e su delvingbitcoin.org. Ogni proposta avrebbe inoltre bisogno di un proprio metodo di attivazione.
Le correzioni di sicurezza non richiedono un soft fork
Non ogni modifica passa da questi meccanismi. Le correzioni di bug che non toccano il consenso vengono rilasciate come qualsiasi aggiornamento software, e gli operatori le installano oppure no. Il 22 ottobre 2026 Bitcoin Core ha unito la pull request n. 1281 sul proprio sito, aggiungendo alla politica di sicurezza una classe di bug «facilmente individuabili»: i bug che si possono trovare con uno sforzo minimo, per esempio con un semplice prompt a un modello di IA, vengono corretti in tutte le versioni mantenute e divulgati subito, senza l’embargo dei livelli Low, Medium, High e Critical. Il nostro servizio sulla nuova politica di divulgazione ne dà i dettagli.
Bitcoin Core 32.0 è arrivato il 27 ottobre 2026, e la pagina del ciclo di vita del progetto riporta la stessa data come fine vita della serie 29.x, per cui le linee mantenute sono ora 32.x, 31.x e 30.x. Poiché Bitcoin Core non si aggiorna da solo, le vecchie versioni restano in uso: nel rilevamento del 18 ottobre studiato nel nostro servizio sui nodi non aggiornati, circa quattro nodi Bitcoin Core raggiungibili su dieci usavano linee che il progetto non correggeva più. Non supportato non vuol dire compromesso, ma le correzioni non raggiungono più quelle macchine.
Che cosa significa la governance di Bitcoin per chi detiene bitcoin e per chi gestisce un nodo
Per chi tiene i coin su un exchange o in un wallet senza nodo, quasi tutto questo avviene fuori dalla vista. Il custode o il fornitore del wallet decide quale software usare e, in una divisione contesa, quale catena accreditare. Soft fork come SegWit e Taproot non hanno richiesto alcuna azione a chi detiene bitcoin: i vecchi indirizzi hanno continuato a funzionare e le nuove funzioni erano facoltative.
Per chi gestisce un nodo, il software scelto è la propria posizione sulla policy e, in un soft fork conteso, può decidere quale catena si segue. Usare Bitcoin Core o Knots, impostare -datacarriersize o lasciare il valore predefinito sono scelte legittime, e la nostra guida passo passo per far funzionare un nodo Bitcoin spiega la configurazione. Prima di installare una versione che applica nuove regole di consenso, leggi quali regole aggiunge, da quale blocco e che cosa succede se la maggior parte dei miner non le segue: i nodi BIP-110 dell’agosto 2026 sono finiti su una catena che quasi nessun altro usava. L’altra abitudine che conta è tenere il software su una linea ancora mantenuta.
Le divisioni sollevano anche questioni fiscali, che la guida ai fork tratta per gli Stati Uniti (IRS, Revenue Ruling 2019-24) e per il Regno Unito. L’episodio BIP-110 ha lasciato qualche blocco su una catena ferma e nessuna moneta scambiata nota. In Italia, secondo la brochure dell’Agenzia delle Entrate sulla legge di bilancio 2025, le plusvalenze su cripto-attività realizzate dal 1° gennaio 2026 sono tassate al 33%, senza soglia di esenzione; le regole generali sono nella nostra guida alla tassazione delle criptovalute in Italia.
La prossima data da tenere d’occhio non è un’altezza di blocco. È il momento in cui una versione di Bitcoin Core, o di un altro client, distribuirà parametri di attivazione per la mainnet per una delle proposte qui sopra. Fino ad allora restano documenti e pull request.
