Soft fork attivato dagli utenti

L'idea inverte il consueto ordine delle operazioni. Invece di attendere che la potenza di hash segnali la propria disponibilità, i nodi che ricevono pagamenti annunciano una data dopo la quale rifiuteranno qualsiasi blocco non conforme. Il BIP-148 fissava quella data al 1º agosto 2017, e alla minaccia credibile che comportava viene ampiamente attribuita la fine di uno stallo nella segnalazione che durava da novembre 2016.

Come funziona

È nella validazione, non nel mining, che una regola viene in ultima istanza applicata, e un soft fork attivato dagli utenti si basa su questo fatto.

Un nodo decide da sé quali blocchi sono validi. Se una parte sufficiente dell'economia, gli exchange, i processori di pagamento e i custodi con cui le persone regolano davvero i pagamenti, esegue un software che rifiuta i blocchi non conformi, allora un miner che produce quei blocchi viene pagato in bitcoin che nessuno accetterà. La ricompensa del blocco vale qualcosa solo se la catena su cui si trova è quella che gli acquirenti riconoscono, quindi l'incentivo punta alla conformità senza che avvenga alcuna votazione.

Il meccanismo è una data, non una soglia. Il BIP-148 richiedeva che dal 1º agosto 2017 ogni blocco segnalasse la disponibilità per SegWit e indicava ai nodi di rendere orfani i blocchi che non lo facevano. Si tratta di un irrigidimento, quindi una catena conforme resta valida per i nodi che non si sono mai aggiornati. Ciò che non elimina è il rischio di divisione: se la maggior parte della potenza di hash continua a minare blocchi non conformi, il lato che applica la regola ha meno lavoro accumulato, e le due catene coesistono finché uno dei due lati non cede.

In seguito il BIP-8 ha trasformato l'approccio in un insieme generale di parametri. Conta i segnali come il BIP-9, ma aggiunge lockinontimeout, di solito scritto LOT. Con LOT impostato su false il deployment semplicemente scade se i miner non raggiungono mai la soglia. Con LOT impostato su true si blocca comunque all'altezza del timeout, il che è un soft fork attivato dagli utenti espresso come flag di configurazione.

Dove lo vedi

La sequenza del 2017 è l'unico esempio completato su bitcoin, e vale la pena conoscerla in ordine. Il BIP-148 fu pubblicato a marzo 2017 da uno sviluppatore che usava il nome Shaolin Fry e fu adottato dagli operatori dei nodi nel corso della primavera. Di fronte a una scadenza ad agosto, a luglio i miner hanno adottato il BIP-91 per rendere obbligatoria tra loro la segnalazione di SegWit. SegWit si è poi bloccato al blocco 479.808 l'8 agosto 2017 ed è diventato applicabile al blocco 481.824 il 24 agosto 2017. La data fissa è arrivata senza una divisione duratura perché l'esito che richiedeva era già stato ottenuto.

L'approccio è riemerso prima di Taproot. Tra la fine del 2020 e l'inizio del 2021 la discussione verteva interamente su se distribuire il BIP-8 con LOT su true o su false, fu pubblicato un client alternativo con LOT su true, e il compromesso fu Speedy Trial, che fissava una finestra breve e nessuna attivazione forzata. I miner hanno raggiunto la soglia a giugno 2021, quindi la questione non è mai stata messa alla prova.

Se detieni bitcoin, la conclusione rilevante è che gestire un tuo nodo è ciò che dà peso a tutto questo. Un soft fork attivato dagli utenti conta gli utenti che validano, e chi ha il saldo interamente su un exchange è rappresentato dal software di quell'exchange, non dal proprio.

Soft fork attivato dagli utenti vs hard fork

Un soft fork attivato dagli utenti irrigidisce le regole; un hard fork le allenta, e la confusione del 2017 derivava dal fatto che entrambi comportavano un rischio di divisione. Con il BIP-148 un vecchio wallet continuava a funzionare e la catena risultante restava valida per ogni versione precedente del software, che è esattamente ciò che un hard fork non può promettere. Il rischio di divisione era temporaneo e dipendeva dal comportamento dei miner, mentre la divisione di un hard fork è prevista fin dal primo blocco incompatibile.