Se in queste settimane hai aperto X e ti sei imbattuto in centinaia di profili con “#BIP-110” nel nome, hai visto solo la schiuma. Sotto c’è una domanda seria che riguarda chiunque gestisca un nodo Bitcoin: il 7 agosto 2026 si apre la finestra di attivazione di un soft fork che una minoranza vuole imporre al resto della rete. I numeri dicono che non passerà. Ma la vicenda è il miglior manuale gratuito su come Bitcoin decide — e su cosa significa davvero “governance” quando nessuno comanda.

Da dove nasce lo scontro

Tutto parte da ottobre 2025, quando Bitcoin Core v30 ha alzato il limite di default sui dati inseribili in un output OP_RETURN: da circa 80 byte a 100.000, di fatto togliendo il tetto. Non era una regola di consenso, era politica di relay: quali transazioni il tuo nodo accetta in mempool e ritrasmette ai peer. I manutentori hanno motivato la scelta in modo pragmatico — il limite non funzionava più. Chi voleva scrivere dati sulla catena lo faceva comunque attraverso i witness Taproot, oppure con canali peggiori come il bare-multisig, che gonfia permanentemente il set UTXO. Rimuovere un filtro inefficace, hanno sostenuto, rende la mempool un’anteprima più onesta di ciò che i miner mineranno davvero.

Una parte della comunità ha letto la cosa in modo opposto: i default di un nodo sono una dichiarazione di valori, e allentare il filtro equivale ad accettare che la timechain diventi un archivio di JPEG. È una posizione legittima. Molti operatori sono passati a Bitcoin Knots, il fork di Core mantenuto da Luke Dashjr con politiche di relay restrittive di serie: oggi vale circa il 17% dei nodi.

Cosa propone BIP-110 (e perché sta fallendo)

Finché si parla di relay, ognuno fa a casa propria. BIP-110 alza la posta: propone di trasformare quei limiti in regole di consenso, imponendo via soft fork un tetto stringente ai dati non monetari, con scadenza automatica dopo circa un anno.

Il meccanismo è un BIP9 modificato che si accontenta del 55% dell’hashrate invece del tradizionale 95%. La segnalazione obbligatoria parte al blocco 961.632, previsto intorno al 7 agosto 2026: in quella finestra i nodi BIP-110 rifiuterebbero come invalidi i blocchi che non segnalano. L’attivazione piena era stimata per il 1° settembre.

Il problema è aritmetico. A fine giugno la segnalazione dei miner era allo 0,31% dell’hashrate — circa 5 EH/s su quasi 940 — e a metà luglio CoinDesk la dava sostanzialmente a zero. Il supporto tra i nodi è sotto il 5%. Adam Back ha avvertito che, in queste condizioni, il rischio concreto è che il BIP-110 si auto-forki fuori dalla rete anziché attivarsi. La sua posizione sul principio è netta: ciò che viene forzato senza consenso va respinto, perché è esattamente da questo che dipende l’immutabilità di Bitcoin.

Cosa dovresti fare se hai un nodo

Prima cosa, la più importante: Core e Knots applicano regole di consenso identiche. Un blocco valido per uno è valido per l’altro. Non ti “forkerai” scegliendo l’uno o l’altro, e nessuno dei due può cambiare Bitcoin da solo. La differenza vive interamente nel livello di policy.

Seconda: filtrare al tuo nodo non impedisce ai dati di finire in catena. I miner ricevono le transazioni grosse anche via submission diretta o relay privato, saltando del tutto la mempool pubblica. Quando quel blocco arriva, il tuo nodo severissimo lo valida e lo accetta, perché è consensus-valido. Filtrare significa non partecipare personalmente alla propagazione di ciò che disapprovi: è una scelta di valori con un attrito marginale, non uno scudo.

Terza, la parte pratica: se vuoi i default stretti di Knots restando su Core, ti bastano tre righe in bitcoin.conf:

datacarrier=0
permitbaremultisig=0

(oppure datacarrier=1 con datacarriersize=83 per riprodurre il vecchio limite). Riavvia bitcoind, nessun reindex necessario. Qualunque client tu scelga, verifica le firme della release prima di eseguirla: è l’unica parte davvero non negoziabile.

Conclusione

BIP-110 quasi certamente non si attiverà, e la lezione non è “hanno vinto i buoni”. È che Bitcoin resiste anche alle modifiche proposte da chi lo ama: senza consenso ampio, una regola non passa, e nessuna quantità di hashtag nei nomi utente sostituisce l’hashrate. Se hai un nodo, la reazione corretta a queste settimane non è scegliere una tribù, ma capire dove finisce la policy e dove inizia il consenso. Il resto è rumore — e il rumore, a differenza dei blocchi, non lo devi validare.

Fonti: