SPLIT o:

Come Quello Che Apparentemente Sembra Un Disturbo Di Personalità Multipla, In Realtà è una Opinione Completamente Razionale su BIP148, UASF, SegWit, Bitcoin, la Vita, l’Universo e il Tutto.*

Il Cambiamento è Bene.

Shiva Nataraja (Signore della Danza), divinità hindu spesso indicata come la fonte della nozione occidentale di “distruzione creativa”.

Innovazione significa cambiamento. Cambiamenti continui, veloci e qualche volta drammatici sono gli strumenti che i sistemi complessi utilizzano per evolversi e creare antifragilità per loro stessi (e che, nel lungo periodo, è meglio di una semplice robustezza).

La “Creazione Distruttiva”, come l’ha chiamata Joseph Schumpeter, è il motore responsabile del mantenimento di funzionalità e miglioramento, specialmente nel contesto dell’innovazione e dei cicli economici. Competizione, disruption, e anche fallimento, sono tutti necessari per un progresso serio. I sistemi che sono attualmente caratterizzati dalle peggiori situazioni di stagnazione, inefficienza, obsolescenza, corruzione, fragilità di lungo periodo e di moral hazard, sono solitamente quelli in cui la competizione e la disruption vengono proibiti o rallentati da monopoli legali/violenti, o dove il fallimento è impedito da salvataggi, manipolazione monetaria e altri tipi di distorsioni. Non sorprende che queste situazioni accadono principalmente in settori altamente contaminati da regolamentazioni, politica, spesa governativa, tassazione, etc.

Non c’è alcun dubbio che il settore finanziario (inclusa la più importante industria: quella monetaria) sia l’esempio principale di questa malattia. Bitcoin è nato per essere la cura. Bitcoin porterà tanti cambiamenti, disruption e fallimenti così come tanta creatività. Bitcoin è disruption creativa. Il suo impatto sulla finanza, commercio, e la società si “muoverà veloce e romperà cose”. Lo sta già facendo.

Per fare questo, Bitcoin stesso dovrà cambiare nel tempo, a vari livelli, per diventare più forte ed evolversi dopo ogni attacco che subirà. Solitamente, nel mondo materiale, solo ciò che muore non cambia. Soluzioni da terze parti nasceranno e falliranno, casi d’uso che oggi non possiamo neanche immaginare diventeranno importanti. Ci sarà un grande ricambio di applicazioni, prodotti, servizi, miners, gateway economici e anche di sviluppatori di codice. E questa è una buona cosa, perché, in generale, il cambiamento è bene.

Ma il Cambiamento di Bitcoin-L1 è Male.

Un’illustrazione della parola che narra di un uomo saggio che costruisce la sua abitazione sulla roccia e non sulla sabbia Vangelo di Matteo 7:24–27, con un riferimento a un passaggio di Malachia riguardante l’immutabilità di Dio: “ Perciocchè io sono il Signore che non mi muto, voi, figliuoli di Giacobbe, non siete stati consumati”.

I sistemi complessi si comportano in un modo non-lineare, questo è talvolta controintuitivo e addirittura paradossale. Per trovare un massimo globale, un sistema deve, a volte, esplorare lo spazio lontano dal massimo locale. In generale, la globale antifragilità del sistema richiede un qualche tipo di fragilità nelle sue parti locali; ad ogni modo, qualche volta, per massimizzare l’evoluzione su una scala globale, alcune parti fondamentali del sistema devono raggiungere un livello di statica, quasi immutabile, adamantina robustezza.

Questo è particolarmente vero per i protocolli e gli standard delle infrastrutture aperte. Questa staticità di standard sottostanti non è forzata dalla politica o da forme di violenza, ma da particolari forze di mercato. Le dinamiche di mercato operano in modi molto diversi per i protocolli delle infrastrutture aperte rispetto ai prodotti commerciali. I prodotti possono facilmente essere rimpiazzati, superati, modificati e dimenticati, mentre gli standard tecnici di successo per infrastrutture aperte sono estremamente difficili da cambiare o rimpiazzare.

Un semplice esempio è l’(im)popolare gioco di Facebook, Candy Crush Saga. È stato un successo, ma quanto sarebbe stato difficile da rimpiazzare con altri giochi facebook di qualità superiore? Non tanto, in verità. Sarebbe invece molto più difficile rimpiazzare la piattaforma di Facebook stessa, su cui il gioco è basato, anche con un’alternativa migliore (anche se non impossibile, come è successo con MySpace rimpiazzato da Facebook). Sarebbe ancora più difficile rimpiazzare la piattaforma del World Wide Web, su cui Facebook è basato, e ancora più difficile rimpiazzare il protocollo HTTP, su cui il WWW è basato. La probabilità di modificare il protocollo TCP/IP, il fondamento del HTTP, è vicina allo zero nel futuro prossimo (in verità, anche tentare di “rimpiazzare” la sua versione attuale, l’IPv4, con una nuova migliorata versione, IPv6, sta impiegando decenni e sta risultando alquanto difficile).

Internet è certamente un meraviglioso esempio di un qualcosa che ha portato tanta disruption e cambiamento (basti pensare a Napster, Bittorrent, Uber, AirBnB, Amazon, Wikipedia, WikiLeaks e Bitcoin stesso), ma questo è stato possibile grazie ad una solida, robusta e praticamente immutabile infrastruttura, che ha reso la sperimentazione e il cambiamento sopra di esso, facile e “socialmente scalabile”. La disruption a volte si trova ad affrontare dei nemici potenti, e l’unica ragione per cui è difficile per l’incumbent politico fermare alcuni dei suoi competitor che operano grazie a Internet è perché non è in grado di cambiare, influenzare, distorcere o corrompere facilmente l’infrastruttura sottostante.

Con Bitcoin, l’Internet della Moneta, questo è ancora più vero. I nemici naturali di Bitcoin sono tanti, forti, potenti, influenti, ricchi, con diffuso sostegno intellettuale, culturale e popolare. Per massimizzare le probabilità del suo successo nel causare disruption nella finanza e nell’economia in generale, con una veloce e continua evoluzione su i suoi livelli superiori, Bitcoin deve affidarsi ad un robusto e adamantino livello base (L1), statico, indipendente, resiliente agli attacchi politici, praticamente immutabile. Se il consensus alla base del cuore di Bitcoin si potesse alterare in modo semplice, arriverebbe facilmente alla sua fine: cambiamenti nella programmazione dell’inflazione potrebbero essere promossi e forzati politicamente (Keynesiani: sono ovunque), la privacy e la fungibilità potrebbero venire attaccate ancora più efficacemente di oggi (Il Grande Fratello di Orwell è più forte che mai, con enorme supporto popolare), salvataggi e distorsioni potrebbero comparire per generare un enorme moral hazard e una casta di animali “più uguali” degli altri (per un esempio significativo basta guardare all’hard-fork di Ethereum, utilizzato per cambiare la storia delle transazioni e favorire solo alcuni investitori del contratto The Dao). Per cambiare le cose, Bitcoin deve essere immune al cambiamento quanto possibile, almeno al suo livello fondamentale. L’uomo saggio costruisce la propria casa sulla roccia.

Ma SegWit sul L1 di Bitcoin è Bene.

Parodia di SegWit ispira a “Star Wars: Episode VII”, poster di Phneep (www.phneep.com, @phneep)

La stabilità è una proprietà a cui un oggetto tende e, eventualmente, raggiunge; difficilmente è un punto di partenza, è invece una destinazione specialmente in tecnologia.

Molte infrastrutture tecnologiche e protocolli, anche quelli che sembrano impossibili da cambiare oggi, hanno dovuto cambiare molto durante le loro prime fasi di sviluppo. Internet non è stata un’eccezione: infatti la versione del protocollo IP che usiamo oggi è la 4, non la 1, e questo dice molto.

Bitcoin-L1 è pronto per diventare robusto e statico, in modo da permettere cambiamenti ed evoluzioni attorno a lui e sopra di lui? Nella mente di molti sviluppatori che lavorano sul suo protocollo, la risposta è “non ancora”.

È probabilmente possibile, per il Bitcoin già com’è ora, diventare il fulcro di un sistema finanziario globale, gigantesco, permissionless, aperto e resistente alla censura, ma questo potrebbe essere reso molto più semplice da qualche ultimo cambiamento. Ci sono tante correzioni che alcuni sviluppatori vorrebbero inserire nel L1 di Bitcoin: un cambiamento di proof-of-work per ridurre la centralizzazione del mining, una dimensione del blocco dinamica, un tempo di creazione del blocco dinamica (con ricompensa aggiustata), prontezza per sidechains e/o treechains, merge-mining nativo e supporto per pegging deterministico, emissione di asset generici non-bitcoin, protezione nativa contro il replay, aggiustamenti più regolari nella difficoltà/ricompensa e così via. Alcuni di questi cambiamenti potrebbero avere un immenso impatto sulla natura del Bitcoin, alcuni potrebbero addirittura danneggiarlo, mentre altri cambiamenti sarebbero chiaramente miglioramenti sicuri senza alcun serio svantaggio.

Segregated Witness, o “SegWit”, è un perfetto esempio di questi ultimi: sistema molte criticità, rende il Bitcoin più resistente, veloce, sicuro, più elastico e più efficiente, senza il rischio di rompere niente. SegWit ha molti “pro” e soltanto un “contro”.

SegWit è un aggiustamento singolo, ma ha tanti effetti positivi in tante aree diverse: dal sistemare la malleabilità delle transazioni di terze parti (un difetto del progetto Bitcoin che ha impedito, fino ad adesso, molte applicazioni interessanti di “smart contract”), all’introduzione dello script versioning (che permetterebbe importanti upgrade futuri al codice, come le Schnorr signatures o nuovi potenti op_codes), alla soluzione del problema del “quadratic sighash”, alla firma di valori di input (estremamente utile per gli hardware wallets), a disincentivare meccanismi contro la crescita degli UTXO, ad un aumento di capacità dei blocchi (fino a quattro volte l’attuale).

L’unico “contro” di SegWit è che è un cambiamento, profondo e importante. Ma, se dovessimo scegliere tra gli ultimi cambiamenti al L1 di Bitcoin, prima della sua cristallizzazione in qualcosa di affidabile, stabile e quasi impossibile da manipolare, è chiaro che SegWit sarebbe in cima a questa lista.

Ma SegWit come Fork è Male.

Rappresentazione grafica di “un bitcoin” rotto in due parti da un hard fork contenzioso.

Anche nel caso di un guadagno chiaro e non ambiguo come quello che SegWit apporterebbe, cambiare la validità delle regole in Bitcoin è qualcosa di pericoloso, che dovrebbe essere fatto con estrema cautela e solo se assolutamente necessario.

Come già affermato in precedenza, Bitcoin è progettato e implementato per essere difficile da cambiare, anche da parti importanti dell’ecosistema (sviluppatori, miners, holders, gateway economici), se non c’è un accordo tra tutte le parti.

Anche se i “software forks” sono una tipica e salutare caratteristica dei progetti open-source, in generale, se influenzano le regole su cui il Bitcoin si basa, portano a dei, ben più pericolosi, “consensus forks”, dove i nodi finiscono per seguire regole differenti. Questo potrebbe avere forti implicazioni economiche, così come pesanti conseguenze per la decentralizzazione, la sicurezza e la resistenza alla censura. Se non implementato correttamente, o se non adottato dalla stragrande maggioranza dei nodi “economicamente rilevanti”, un “consensus fork” potrebbe causare una divisione nel network di Bitcoin e dei suoi asset nativi. Questo tipo di divisione potrebbe influenzare negativamente il valore e la sicurezza dei risultanti coin “gemelli”, riducendo gli effetti network (il valore e la sicurezza della somma delle due parti di questa divisione sarebbero di molto inferiori a quelli della catena originale e unica).

Assumendo dei players economici che agiscono in modo razionale, se un cambiamento nel protocollo è contenzioso, quel cambiamento semplicemente non avverrà. Questa è la più importante caratteristica del Bitcoin: senza di essa, la censura e la manipolazione sarebbero eseguibili in modo triviale da un avversario, per esempio, statale. Ogni consensus fork deve essere consensuale, sempre.

Inoltre, ogni consensus fork, specialmente nel caso porti conseguenze a livello economico, deve essere studiato, esaminato, discusso e simulato per anni, e testato intensivamente e per lungo tempo prima di essere distribuito nella rete.

Per ultimo ma non per importanza, ogni consensus fork deve, quando possibile, essere di tipo “soft”: quindi retrocompatibile, nel quale le regole esistenti del Bitcoin non sono violate in alcun modo, ma nuove regole vengono aggiunte, rendendo più stringente il set di regole esistenti, non ampliandolo.

Esistono molti altri pericoli che riguardano gli “hard fork” non-retrocompatibili: sarebbero do fatto garantite pericolose divisioni del network, a meno che non ci sia una reale unanimità tra i nodi economicamente rilevanti (mentre con i soft forks le divisioni avvengono solamente nel caso in cui le regole non ottengano una maggioranza del peso economico e, di conseguenza, del totale dell’hashing power); i cambiamenti che possono essere apportati violando le regole esistenti sono potenzialmente imprevedibili in portata, tipologia ed effetti (mentre, con i soft fork, i gradi di libertà derivanti dall’aggiunta di nuove regole sul sistema soprastante sono minori, e quindi la superficie di attacco inferiore); la finestra temporale per aggiornare diventa critica e può portare all’estromissione dei servizi e degli utenti più lenti nello stare al passo.

È opportuno notare che Bitcoin non ha mai avuto un hard fork permanente nella sua intera storia, mentre molte nuove funzionalità e correzioni sono state implementate via soft fork. Ogni singolo tentativo passato di azzardare un hard fork di fretta e senza un largo consenso è fallito: da Bitcoin XT nell’Agosto 2015 (un fork guidato da Mike Hearn di R3CEV, che prevedeva un incremento di 8 volte della dimensione del blocco, un raddoppiamento automatico dello stesso ogni due anni, una soglia di attivazione più bassa del normale e una penalità controversa per le connessioni TOR), a Bitcoin Unlimited e Bitcoin Classic nel Gennaio/Febbraio 2016.

Quando è stato progettato per la prima volta, nell’Aprile 2015, dallo sviluppatore Bitcoin Core Pieter “Sipa” Wuille, SegWit ha sofferto di quasi tutti questi problemi: era un cambiamento controverso, era un’idea nuova e non testata (con molta pressione da parte delle persone che volevano farla rapidamente), e si pensava potesse essere implementata solo come hard fork.

Ma un Soft Fork Consensuale e Testato è Bene.

Una visualizzazione grafica di un soft fork pacifico, insieme al logo ufficiale di SegWit.

Gli hard fork fatti di fretta e contenziosi sono il male, ma l’attuale proposta di SegWit è esattamente l’opposto.

Ad un certo punto, nello scorso anno, la proposta ha iniziato ad guadagnarsi l’interesse, la trazione e il supporto e alla fine il consenso quasi unanime: le critiche tecniche a quest’idea sono sempre state molte poche, tutte provenienti da osservatori non-tecnici e prevalentemente motivati da ragioni politiche, e ad oggi sono praticamente impossibili da trovare in un dibattito. Esiste ancora opposizione da parte di alcuni miners cinesi (che potrebbe essere spiegata dal fatto che sono fortemente opposti alla privacy e alla fungibilità, che SegWit migliorerebbe ampiamente, direttamente e indirettamente), ma è sempre meno popolare giorno dopo giorno. Anche il consorzio aziendale guidato dall’investitore Barry Silbert (in cui sono inclusi anche molti miners cinesi), che, dopo il fallimento di tutti i tentativi precedenti, sta provando ancora una volta a promuovere un hard fork contenzioso, si impegna comunque per far includere SegWit nel loro client alternativo: questo mostra che il cambiamento in sé non è più contenzioso.

Il fork di SegWit non sarebbe nemmeno “affrettato”: il concetto generale e l’implementazione proposta sono state studiate, discusse ed esaminate apertamente per quasi due anni, il codice attuale funziona perfettamente su una specifica testnet ad-hoc da Dicembre 2015, sulla testnet regolare Bitcoin da Maggio 2016, sul network di Litecoin (che uno potrebbe chiamare: “un’altra, più realistica, testnet di Bitcoin”) da Maggio 2017.

E, per ultimo ma non per importanza, SegWit sarebbe solamente un soft fork: nel tardo Ottobre 2015, lo sviluppatore Core Luke Dashjr ha proposto un metodo che permette di implementare questo aggiornamento in Bitcoin in modo completamente retrocompatibile con tutto il software Bitcoin esistente (anche se il software deve comunque essere aggiornato per comprendere a pieno e utilizzare questo nuovo aggiornamento). Questa implementazione di SegWit è ora in attesa di attivazione, aspetta solo che superi una soglia, sicura e molto conservativa, del 95% di blocchi minati per essere attivato.

Qualche controversia è comunque sorta riguardo a questa scelta di rendere SegWit un soft fork meno pericoloso, ma le ragioni sono più politiche che tecniche.

Prima di tutto, alcuni dei proponenti dei precedenti, falliti, controversi hard fork, hanno speso molto tempo a cercare di convincerci che “un hard fork è più sicuro di un soft”: questo tipo di esposizione pubblica rimane ancora un forte incentivo per loro ad avversare l’idea di SegWit come soft fork (una vaga argomentazione di “debito tecnico” viene usato come scusa in questi casi, ma che non regge ad una semplice comparazione del codice delle due alternative implementazioni).

In secondo luogo, è stato scoperto che la versione soft fork di SegWit, differentemente da quella in hard fork, interferirebbe con una segreta strategia di ottimizzazione sviluppata e possibilmente utilizzata da alcuni miners (una corrispondente strategia di ottimizzazione dichiarata non verrebbe influenzata, ma essendo coperta da un brevetto questi miners hanno dovuto utilizzare una versione non apertamente visibile per bypassare le leggi sui brevetti e riuscire quindi a sfruttare questo vantaggio in segreto).

Ma il Sabotaggio Politico di un Fork Consensuale e Testato è Male.

Non è una sorpresa che gli stessi miners e produttori di ASIC che sono stati accusati di utilizzare questa ottimizzazione segreta, si siano anche esposti politicamente e abbiano rivolto dure critiche all’attuale progetto di scalabilità di Bitcoin Core (che consiste nell’attivazione di SegWit come seguente step naturale), e abbiano anche iniziato a segnalare per bloccare l’attivazione dell’aggiornamento.

Dato che la soglia di segnalazione richiesta per l’attivazione dell’upgrade è stata intenzionalmente fissata molto alta, quest’opposizione politica è risultata sufficiente a mettere in stallo questa proposta di aggiornamento per il futuro prossimo.

Da un lato, potrebbe essere sufficiente semplicemente aspettare, difendere lo status quo di Bitcoin fino a che questa operazione politica contro l’aggiornamento esaurisca le risorse, o fino a che i danni causati dal problema della scalabilità (commissioni alte e lunghi tempi di conferma per le transazioni on-chain, lenta e difficile implementazione di più avanzate soluzioni off-chain) saranno così intensi da far sì che la pressione sul “veto” dei miners sia sufficientemente alta da superare l’incentivo al bloccare l’adozione. Anche se l’attuale rilascio di SegWit scadesse prima che questo succeda, sarebbe possibile aspettare un secondo rilascio, e poi un altro, e così via.

D’altra parte però, la stessa pressione che potrebbe essere usata per spingere i miners a segnalare SegWit, potrebbe essere utilizzata da altri, ben più pericolosi, contenziosi, non testati tentativi di hard forks (e politicamente motivati).

Esiste un’alternativa, che è comunque generalmente considerata sicura e giusta: provare ad attivare gli aggiornamenti basandosi sull’effettivo consenso tra l’utenza, in qualche modo bypassando i sabotaggi politici del processo di segnalazione.

Anche se le soglie dei blocchi minati rappresentano una metrica forte e obiettiva, che è difficile da replicare in più vaghe e ambigue misure di “reale consenso”, esiste un precedente di una soluzione ad un problema simile: il concetto di “rough consensus” (consenso grezzo) come sviluppato nella Internet Engineering Task Force, o “IETF” (Internet stesso, ancora una volta, è una buona metafora per comprendere le dinamiche del suo più giovane e promettente figlio, il Bitcoin). Dentro IETF, i cambiamenti al protocollo venivano adottati basandosi su un meccanismo di consenso, tenendo in considerazione le visioni differenti dei partecipanti, arrivando ad “almeno un consenso generale” sulle questioni tecniche, escludendo le considerazioni politiche e personali, evitando sempre di basarsi su una filosofia del tipo “la maggioranza regna”, utilizzando il “fischiettare invece di votare” e, in particolare far sì che veri e propri prodotti di ingegneria (il codice in esecuzione) superino i progetti teorici. Pieno consenso, o unanimità, era sempre l’obiettivo principale, ma richiederla strettamente avrebbe permesso ad ognuna delle parti interessate di mettere in stallo il processo per usare il loro consenso come prezzo, in cambio di una ricompensa, un riscatto o un compromesso politico.

Anche in Bitcoin ci sono precedenti di metodi per bypassare veti posti da certe parti interessate: come quello utilizzato qualche tempo fa per attivare con successo il soft fork P2SH (BIP16), nonostante l’esistenza di qualche opposizione (in quel caso, però, l’opposizione non era solo politica, ma anche specificatamente tecnica).

Un metodo simile è stato proposto oggi per il soft fork di SegWit, ed è stato chiamato “User Activated Soft Fork”, o “UASF”. L’idea di base dietro a UASF è di rilasciare un client in una data specifica che, nel caso in cui la soglia sicura non sia ancora stata attivata dai miners, inizi a forzare le nuove regole del soft fork, senza tener conto della mancanza di sufficiente segnalazione. Il ragionamento che vi sta dietro è il seguente: se tanti utenti con rilevanza economica inizieranno ad usare questo client, ma la maggioranza del hashing power si rifiuterà di collaborare con loro, Bitcoin si dividerà temporaneamente, portando la maggioranza del valore economico sul fork SegWit. Molti miners, a quel punto, inizieranno a seguire le nuove regole, per poter minare dei Bitcoin che valgano effettivamente qualcosa, assumendo chiaramente che il loro disaccordo sia una mossa politica contingente e non una preoccupazione reale, fondamentale, economica o tecnica. L’interesse personale di molti individui, miners razionali dovrebbe essere in grado di superare le strategie politiche della categoria, e presto questa dinamica dovrebbe generare una reazione a catena, dando più profittabilità ai miners che si trovano sulla catena SegWit e attirando a sua volta altri miners. Ad un certo momento la maggioranza dell’hashing power dovrebbe spostarsi sul fork di SegWit, e a quel punto qualcosa di molto strano accadrebbe: la catena non-SegWit verrebbe “cancellata” con una gigantesca “riorganizzazione” dei blocchi e con enormi perdite finanziarie per i miners non-SegWit (questo perché i blocchi di ogni soft fork verrebbero considerati validi dai nodi classici/legacy, mentre non è vero il contrario, e i client Bitcoin sono programmati in modo da seguire sempre la catena valida con la maggioranza della proof-of-work). Per questa ragione, uno potrebbe ragionevolmente aspettarsi che una maggioranza dell’hashing power si sposti sul fork di SegWit fin dall’inizio, evitando la divisione temporanea e ogni sorta di possibile “reorg”.

È un’interessante strategia di teoria dei giochi, che, ovviamente, non potrebbe essere utilizzata per spingere ogni sorta di soft fork (comprese magari regole che renderebbero il Bitcoin meno prezioso o utile), ma solo per quei tipi di soft fork che tutti sanno essere fondamentalmente benefici al protocollo, indipendentemente dalle strategie politiche che stanno dietro al processo di segnalazione.

Ma avere Cautela nel Superare i Sabotaggi Politici è Bene.

Nicolas Bacca (Bitcoin expert e CTO di Ledger, la più importante compagnia di hardware wallet), il quale considera BIP148 troppo rischioso e mette un simpatico cappello “STATUS QUO” che fa il verso agli ormai famosi cappelli UASF.

Anche considerando UASF come la soluzione migliore per superare l’attuale impasse politica, esistono comunque molti modi diversi di implementarlo.

Attualmente ci sono due differenti proposte di UASF, che si contendono il supporto degli utenti: BIP148 e BIP149.

BIP149 potrebbe sembrare una mossa più cauta: propone di iniziare un secondo processo di attivazione, in un modo più ordinato, solo nel caso in cui l’attuale tentativo di attivazione risultasse un fallimento, a Novembre 2017. Questo secondo processo di attivazione differirebbe nel fatto che, dopo il processo di segnalazione, l’attivazione di SegWit verrebbe autonomamente abilitata dai nodi di questo client, anche senza raggiungere particolari soglie. Questa attivazione, in ogni caso, non includerebbe il rigettare catene costruite su blocchi che non segnalano per SegWit dopo la data chiave: le nuove regole verrebbero forzate solo sui blocchi che contengono dati SegWit, permettendo ai blocchi “non-segnalanti” di essere mischiati nella catena. Dunque, i miners, senza fare nessun cambiamento, costruirebbero blocchi sulla catena SegWit, senza nessuna seria disruption. Per causare una divisione del network, in questo caso, i miners avversi dovrebbero deliberatamente e continuamente rigettare ogni nodo SegWit, o minare blocchi con transazioni SegWit invalide, valide per i nodi legacy ma non per gli aggiornati.

BIP148 è differente: i nodi funzionanti su questa versione inizierebbero a rigettare i blocchi non-segnalanti (inclusi i blocchi segnalanti costruiti sopra altri non-segnalanti) già il 1° Agosto 2017, ben prima della data di scadenza dell’attuale distribuzione di SegWit (questa proposta fa leva proprio su questo rilascio), e inizierebbero da subito a rifiutare ogni catena costruita su blocchi che non segnalassero di essere pronti per SegWit. BIP148 potrebbe sembrare una proposta “affrettata” e “aggressiva”, associata ad una significativa probabilità di miners riluttanti che dividano il network, almeno temporaneamente. Anche se la divisione eventualmente fosse risolta, lo farebbe creando un’enorme e dolorosa ri-organizzazione della catena non-BIP148. Bitcoin Core, tradizionalmente abituata a seguire policy di cambiamenti lenti, sicuri, lisci e minimi, non aderirà a questa proposta (anche se molti sviluppatori del gruppo lo supportano). La via più sicura per andare avanti, in linea teorica, sembrerebbe essere BIP149, e Bitcoin dovrebbe sempre procedere per la via più sicura. Non è così?

Ma Causare Divisioni nel Nome della Cautela è Male.

Qui è dove le implicazioni di teoria dei giochi si fanno interessanti. Certamente, in una situazione in cui gli sviluppatori e gli esperti devono ancora proporre, discutere e scegliere la soluzione soluzione preferita, la scelta più sicura per un UASF sarebbe supportare BIP149.

Ma se la situazione attuale fosse tale da far sì che i nodi economicamente rilevanti (e qualche miners) eseguissero veramente BIP148 prima di Agosto? Beh, in quel caso potremmo avere una divisione del network, e l’unico fork che rischierebbe i pericoli di una reorganizzazione sarebbe quello legacy, e specialmente i miners. Potremmo dunque aspettarci che molti miners e nodi vadano via da quest’ultima (anche considerando che il valore della catena SegWit sarebbe inerentemente superiore a quella legacy).

A questo punto, altri sarebbero incentivati a restare sulla catena BIP148 per un proprio vantaggio individuale, ogni nodo e miner troverebbe anzi, ancora più vantaggioso evitare ogni tipo di divisione, se possibile, segnalando BIP148 prima di Agosto.

In pratica, la scelta teoricamente più “sicura”, in questo scenario, sarebbe in verità veramente rischiosa e irresponsabile, mentre quella che è teoricamente più “aggressiva” aiuterebbe a preservare sia la ricchezza personale dei partecipanti e l’unità generale (e quindi il valore generale) del network.

Ancora meglio: per evitare del tutto un simile, terribile, scenario, i miners dovrebbero essere incentivati a segnalare e attivare il “normale” SegWit (BIP141) ben prima del primo di Agosto!

Chiaramente ci sarebbe dell’imbarazzo politico nel farlo, per dei miners che si sono sempre opposti all’attuale roadmap di scalabilità di Core, ma questo problema potrebbe essere affrontato in vari modi: la politica non è questione di fatti, solo di percezioni e narrative, e molti miners “ribelli” potrebbero semplicemente dire che non si stanno “arrendendo” alla minaccia di UASF, magari “concedendo” l’attivazione di SegWit in cambio di un qualcosa futuro, anche se consapevoli che probabilmente questo qualcosa non lo otterranno mai (per questa ragione politica, la proposta di hard fork contenzioso di Barry Silbert potrebbe risultare utile, se i miners la “interpretassero” come un’attivazione, ora, di SegWit, in cambio di una promessa per un futuro inutile hard fork, che non verrà mai mantenuta).

Se il punto fosse scegliere, promuovere e suggerire come attuare un UASF, BIP148 potrebbe essere anche considerato azzardato, precipitoso e sconsiderato. Ma il punto adesso è come comportarsi in uno scenario in cui BIP148, in ogni caso, otterrà del supporto. In tale scenario, paradossalmente, la risposta sarebbe che supportare BIP148 rappresenterebbe la scelta più sicura e conservativa.

Abbiamo tante possibilità di fronte a noi, ad oggi. La minaccia che BIP148 possa convincere il 95% dell’hashing power a supportare BIP141 così com’è, per evitare interamente UASF. Se questo accade, avremo SegWit attivato sulla mainnet di Bitcoin prima di Agosto, senza nessuna divisione del network, e l’eseguire, supportare e promuovere BIP148 non potrebbe far altro che aiutare questo scenario.

Altrimenti, la stessa minaccia potrebbe essere usata per convincere poco più della metà dell’hashing power, e questo sarebbe sufficiente a garantire lo stesso risultato: nessuna divisione, SegWit attivo presto, massima utilità nel eseguire BIP148.

Una terza possibilità sarebbe che una minoranza dell’hashing power inizialmente supporti BIP148. In questo caso la catena si dividerebbe, e il risultato finale dipenderebbe principalmente dal dove si trova la maggioranza economica, poiché la ricompensa del mining dipende strettamente dal valore di mercato. Comunque, la situazione non sarebbe simmetrica: rischi di riorganizzazione affliggerebbero la catena legacy, e la sua potenziale dannosità crescerebbe nel tempo, e anche la sua probabilità decrescerebbe nel tempo. Inoltre, uno dei due rami avrebbe SegWit e tutti i suoi benefici, l’altro no. Questo scenario potrebbe attivare tanti altri sotto-scenari: il più probabile sarebbe un veloce spostamento di nodi e miners alla catena BIP148, ma altri risultati potrebbero essere possibili, come una divisione permanente, o causata da un hard fork che raggiunge la maggioranza sulla catena legacy, o dalla veloce adozione di checkpoints o da “no148” contro-soft-fork.

Esiste anche l’eventualità che nessun miners supporti BIP148, ma sembra estremamente improbabile, che comunque non porterebbe ad un “fallimento” della proposta, ma invece alla creazione di una nuova altcoin dalla catena BIP148, in seguito ad un cambio di Proof of Work.

Tutto considerato, eseguire, segnalare e supportare BIP148 sembra, al momento, la scelta più sicura.

Ci sono altre considerazioni da aggiungere a tutto questo. È possibile, per esempio, che questa situazione non rappresenti un normale passo nell’evoluzione organica del protocollo, ma invece qualcosa che i fan di Asimov riconoscerebbero come una “Crisi Seldon” del Bitcoin: un punto cruciale in cui dinamiche individuali e sociali possono determinare l’anti-fragilità di un sistema o il suo fallimento. Rimane il fatto che la centralizzazione della produzione delle ASIC è ad oggi un problema più serio di quanto Satoshi Nakamoto avesse potuto immaginare nei suoi incubi più oscuri. BIP148 potrebbe essere, oltre che un modo per ottenere SegWit e tutti i suoi benefici presto, un modo decisivo per dire ai monopolisti dell’equipaggiamento di mining che essi non possono controllare veramente Bitcoin, e non lo faranno mai.

Questo potrebbe essere uno degli ultimi importanti cambiamenti, che impediranno l’avvenire di altri in futuro, rendendo il L1 di Bitcoin più immutabile, e nel fare questo, rendendo l’intero mondo economico-finanziario incredibilmente mutabile.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

* Articolo inglese inizialmente pubblicato su Cryptoinsider (@CryptoinsiderCI) (https://cryptoinsider.com/split-thoughts-bip148-uasf-segwit-bitcoin-life-universe-everything/) in inglese. Traduzione in italiano di Giulio Mazzanti (@Giuzzilla).

Show your support

Clapping shows how much you appreciated BHB Network’s story.