BIP-110 verso la segnalazione obbligatoria con un sostegno minimo dei miner

Cosa sta succedendo

Bitcoin si avvicina alla fase di applicazione di BIP-110, un soft fork controverso che limiterebbe per circa un anno alcune forme di archiviazione di dati sulla rete tramite nuove regole di consenso. Intorno al blocco 961.632, atteso in prossimita del 9 agosto 2026, i nodi che eseguono il software BIP-110 dovrebbero iniziare a rifiutare qualsiasi blocco che non segnali il sostegno alla modifica.

La proposta, dal titolo ufficiale Reduced Data Temporary Softfork, e stata redatta da Dathon Ohm e attribuisce la bozza originale e la consulenza allo sviluppatore Luke-Jr. Il suo obiettivo dichiarato e limitare a livello di consenso la dimensione di diversi campi dati, per scoraggiare grandi inserimenti di dati come le inscription Ordinals.

Come dovrebbe funzionare l'attivazione

BIP-110 usa una versione modificata del metodo di segnalazione BIP9. I miner indicano la loro disponibilita impostando il bit 4 nei blocchi che estraggono, sotto il nome di deployment "reduced_data". Per un lock-in anticipato volontario devono segnalare almeno 1.109 dei 2.016 blocchi di un periodo di retarget, cioe il 55 per cento.

La proposta non si ferma qui. Durante il periodo di retarget dal blocco 961.632 al blocco 963.647, la segnalazione diventa obbligatoria per i nodi BIP-110: quei nodi rifiutano qualsiasi blocco che non imposti il bit 4. Il lock-in segue non oltre il blocco 963.648, le regole diventano attive al blocco 965.664, atteso intorno al 1 settembre 2026, e scadono da sole dopo 52.416 blocchi, circa un anno dopo.

A che punto e il sostegno

La segnalazione dei miner e rimasta bassa per tutto il deployment. A fine luglio 2026 i dashboard di monitoraggio indicavano un sostegno di pochi punti percentuali, e nessun periodo di retarget si e avvicinato ai 1.109 blocchi richiesti per un lock-in volontario al 55 per cento. Il sostegno e arrivato soprattutto dalla pool Ocean e da miner indipendenti piu piccoli, mentre le grandi pool non hanno segnalato.

BIP-110 include una regola di grandfathering: le monete confermate prima dell'attivazione potranno ancora essere spese secondo le regole precedenti per tutta la durata del deployment. I nuovi limiti si applicano agli output creati a partire dall'attivazione.

Un bug segnalato nel client di attivazione

Il 17 luglio 2026 un report pubblicato su BlockSlop ha descritto un difetto riproducibile nel percorso di aggiornamento del client di attivazione basato su Knots. Secondo il report, un nodo che abilita l'applicazione delle regole su una data directory esistente puo conservare un blocco che un nodo BIP-110 sincronizzato da zero rifiuta. Due nodi che eseguono regole identiche potrebbero quindi essere in disaccordo su quale sia la catena valida. Il caso e stato riprodotto su regtest ed e accompagnato da una correzione proposta.

Contesto e cosa succede ora

Se al momento dell'inizio della segnalazione obbligatoria il livello di segnalazione restera vicino a quello attuale, i nodi BIP-110 rifiuterebbero i blocchi prodotti dalla maggior parte dell'hashrate della rete e seguirebbero solo il piccolo numero di blocchi che segnalano, cosa che a quel punto puo creare una spaccatura della catena. Sviluppatori come Adam Back e Jameson Lopp hanno avvertito pubblicamente che i parametri di attivazione rischiano una spaccatura di questo tipo.

L'autore della proposta ha sostenuto che BIP-110 ha gia il consenso, un'affermazione che secondo i critici non trova riscontro nei dati di segnalazione on-chain. Per la meccanica dietro il rischio di spaccatura, la soglia insolitamente bassa e cosa significherebbe una catena BIP-110 separata, vedi l'approfondimento in BIP-110 spiegato.