Bitcoin, la blockchain si biforca dopo un aggiornamento previsto

Bitcoin, la blockchain si biforca dopo un aggiornamento previsto

La situazione non è grave ma richiede cautela: chi usa un client leggero e con meccanismo di validazione SPV dovrebbe fare attenzione in quanto a rischio double-spending

di pubblicata il , alle 15:11 nel canale Web
 

Allarme per la comunità Bitcoin: gli esiti inaspettati di un aggiornamento previsto stanno portando al rischio di generare un problema di "double spending" o, in termini più comprensibili, di possibilità che con una stessa criptomoneta sia possibile compiere più transazioni distinte: il double-spending, visto da un'altra prospettiva, è nel mondo delle criptovalute il corrispettivo della falsificazione.

L'allarme è scattato poichè alcuni miner hanno generato blocchi invalidi: alcuni client della rete bitcoin sono in grado di rilevare questi blocchi e rifiutarli, mentre altri non sono in grado di fare ciò e possono mostrare conferme di transazioni la cui affidabilità può variare a seconda del software utilizzato. Bitcoin.org avverte che tutti i bitcoin ricevuti in transazioni confermate prima del 2015-07-06 00:00 UTC sono da considerarsi sicuri, mentre l'affidabilità della conferma per le transazioni validate dopo tale ora dipende dal client impiegato.

Bitcoin Core 0.9.5 e successivi non hanno alcun problema poiché sono in grado di rilevare i blocchi invalidi, mentre le versioni di Bitcoin Core 0.9.4 e precedenti non sono in grado di offrire lo stesso livello di sicurezza. I wallet cosiddetti "lightweight" e che si basano sul meccanismo di verifica SPV (Simplified Payment Verification - un sistema per il quale in realtà non viene verificato alcunché dal momento che si basa sulla connessione ad un nodo fidato o che la difficoltà della proof of work viene considerata essa stessa una prova di validità) non possono essere considerati al sicuro dal problema fino a quando non abbiano ricevuto almeno 30 conferme aggiuntive sulla validità di una transazione e fino a quando tutti i principali pool di mining non sono passati alla validazione completa. Per quanto riguarda i web wallet, la sicurezza dipende da caso a caso e a seconda del tipo di infrastruttura utilizzato è possibile ricadere nei casi appena citati.

Ma cosa è accaduto, nel concreto? Da diverso tempo la capacità di calcolo della rete Bitcoin sta operando per adottare le nuove regole di sicurezza BIP66 (rimandiamo a questo documento per approfondimenti dettagliati) le quali fungono, tra le altre cose, da "percorso" per l'abbandono progressivo dei blocchi in versione 2 verso i blocchi in versione 3 (La versione di un blocco della blockchain indica la versione di protocollo con cui il blocco è stato minato). Le nuove regole stabiliscono infatti che se degli ultimi 1000 blocchi minati almeno 950 sono in versione 3, tutti i client aggiornati alle nuove regole rifiutino automaticamente nuovi eventuali blocchi in versione 2.

La soglia 950/1000 è stata raggiunta nella mattina del 4 luglio. Poco dopo un piccolo miner facente parte della porzione di miner non aggiornati ha minato un blocco invalido. Occorrenza, questa, del tutto prevista. Quel che invece non era stato previsto che circa la metà dell'hash rate del network bitcoin stava eseguendo il mining in modalità SPV e ha costruito nuovi blocchi basandosi su quello invalido. Bitcoin.org osserva, nel suo comunicato, che il 50% circa dei miner SPV avevano precedentemente indicato la volontà di adottare le regole BIP66. Questo spiega per quale motivo tutti quei software SPV che assumono che i block sono validi a prescindere, sono a rischio di mostrare transazioni come confermate quando queste potrebbero non esserlo realmente.

Tutto ciò ha generato una biforcazione della blockchain: da un lato la catena di blocchi validi, dall'altro una piccola catena morta che si è chiusa dopo 6 blocchi, nessuno dei quali contenenti transazioni. Sebbene a seguito della chiusura della piccola catena di 6 blocchi si fosse pensato ad una ristabilizzazione della situazione, in realtà il 5 luglio alle ore 23:40 si è verificata un'altra biforcazione chiusasi dopo 3 blocchi. Attualmente, però, non è ancora dato sapere se in questi tre blocchi siano contenute transazioni. In questa pagina è possibile verificare gli hash dei blocchi invalidi.

Qualora si stia minando bitcoin all'interno di un pool di mining è consigliabile verificare che il pool adotti misure di validazione completa e, in caso contrario, spostarsi verso un pool con queste caratteristiche. Se, invece, si stia minando in solo è consigliabile passare a Bitcoin Core 0.10.2. Bitcoin.org, che sta monitorando la situazione per aggiornare la comunità, ritiene che la situazione non sia ancora stata riportata alla normalità. Attenzione, dunque.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione

6 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
bobafetthotmail06 Luglio 2015, 16:31 #1
Noto una lieve nota di allarmismo infondato eh.

Tutte le volte che c'è un aggiornamento ci sono episodi di fork del genere visto che è poco probabile che TUTTO IL MONDO aggiorni il software allo stesso momento.

Qui semmai è un problema l'utilizzo del SPV che in caso di situazioni fisiologiche come questa si incastra.

No per dire, "software SVP assumono che i block sono validi a prescindere". Massima sicurezza eh, chi è il genio che ha inventato questo sistema di "validazione" semplificata delle transazioni?

Lo stesso genio che ha inventato il WPS probabilmente.
HostFat06 Luglio 2015, 17:04 #2
I client SPV non possono validare le tx proprio perchè non scaricano i blocchi, e quindi vanno ad interrogare X nodi sulla validità di queste tx.
Se una maggioranza di questi nodi conferma queste tx, i client SPV le considerano valide.
Il problema c'è se capita per caso che questi client SPV siano comunque collegati a tutti nodi appartenenti ad una minoranza della rete, che si trova sul fork minore.

In queste situazioni di incertezza la soluzione è aspettare più conferme.
Nel caso sopracitato si consigliava di aspettare circa 30 conferme.

Per specificare meglio, l'unico client full / nodo full è il Bitcoin-Qt, tutti gli altri sono per lo più client SPV (o servizi terzi)
Il Bitcoin-Qt richiede il download dell'intera Blockchain, diversi giga e quindi diverso tempo per tenerla aggiornata.
bobafetthotmail06 Luglio 2015, 17:53 #3
ah, ok.
è meno stupido di quanto scritto nell'articolo, così avrebbe un senso.

Secondo me 30 nodi sono un pò pochini per un controllo del genere. Magari andava bene agli inizi, ma ora magari fare un pò di più sarebbe meglio.
Quanti sono i nodi totali? Grossomodo eh.
HostFat06 Luglio 2015, 17:56 #4
30 conferme, cioè 30 blocchi di seguito sulla stessa fork, non 30 nodi.
In genere quando si parla di conferme si intendono un primo blocco e i successivi sulla stessa catena blocchi.

Quindi ad esempio un client SPV andrebbe ad interrogare 8 o più nodi full (dipende comunque da client a client), chiedendo la conferma di tale transazione, e i successivi blocchi, sempre a quei 8 nodi o ad altri.

Nel caso suddetto di rischio, se la tx riceve 30 conferme una di seguito all'altra (30 blocchi di seguito legati fra loro), interrogando X nodi, si poteva considerare una transazione corretta e depositata sulla blockchain (fork maggiore)

5 ore di attesa quindi, circa.
bobafetthotmail06 Luglio 2015, 18:10 #5
ah ok. Quindi l'articolo è fondamentalmente fuffa.
Italia 106 Luglio 2015, 18:38 #6
Beh, fortunatamente ho installato sui miei 2 pc le ultime versioni del client. 0.10.0 su questo (con win10) e 0.10.non mi ricordo su quello in soffitta. Il firmware dei miner può far qualcosa ?

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^