Hash dell'intestazione del blocco precedente

Ogni blocco punta all'indietro, mai in avanti. Poiché il puntatore si trova dentro gli 80 byte di cui si calcola l'hash, modificare qualsiasi cosa in un vecchio blocco ne cambia l'hash e rompe ogni blocco costruito sopra di esso, quindi annullare un pagamento di un anno fa significa rifare circa 52.000 blocchi di proof of work. È questo, e non una qualche regola sulla cancellazione dei dati, ciò che si intende quando si dice che bitcoin è immutabile.

Come funziona

L'hash dell'intestazione del blocco precedente si ottiene applicando SHA-256 due volte all'intestazione di 80 byte del genitore, ed è l'unico riferimento che un blocco conserva a qualcosa di esterno a sé.

Poiché l'intestazione del genitore contiene l'hash del proprio genitore, e così via fino all'inizio, un solo campo di 32 byte vincola l'intera storia che sta dietro. Un nodo che ha verificato la punta ha implicitamente verificato che la catena che vi conduce sia coerente al suo interno. Modifica una transazione in un blocco minato la scorsa estate e l'hash dell'intestazione di quel blocco cambia, il che significa che la copia che ne tiene il figlio non corrisponde più, il che significa che il figlio non è valido, e così tutto ciò che viene dopo. Riparare il danno significa riminare ognuno di quei blocchi, a circa 144 blocchi al giorno, ovvero 52.560 all'anno.

Il blocco genesi è l'eccezione, e deve esserlo: non c'è nulla prima di esso, quindi il campo è di 32 byte zero.

Nulla in un blocco punta in avanti. Quando Bitcoin Core restituisce un nextblockhash sta leggendo il proprio indice, non il blocco, ed è esattamente per questo che il valore può cambiare durante una riorganizzazione mentre l'hash dell'intestazione del blocco precedente non cambia mai. Neanche due blocchi che indicano lo stesso genitore sono un errore. È l'aspetto di un fork dal punto di vista dei dati, e la rete lo risolve preferendo il ramo con il maggior lavoro accumulato anziché dichiarare sbagliato uno dei due puntatori.

Dove lo vedi

L'hash dell'intestazione del blocco precedente compare con nomi leggermente diversi a seconda di ciò che stai guardando.

Bitcoin Core lo restituisce come previousblockhash da getblockheader e getblock. Per il blocco 0 il campo è semplicemente assente dalla risposta, perché non c'è alcun genitore da indicare. Gli esploratori di blocchi di solito lo etichettano Previous Block e lo trasformano in un link, ed è così che si procede all'indietro nella storia cliccando.

È anche l'intera sostanza di una sincronizzazione della catena di intestazioni. Un nodo che scarica le intestazioni controlla due cose per ogni intestazione: che questa indichi la precedente e che il suo hash rispetti il target. Solo quando quella catena si tiene insieme inizia a chiedere i corpi dei blocchi. I wallet leggeri non vanno mai oltre: conservano i collegamenti e il lavoro, e nulla più.

Se mai costruisci il campo a mano, aspettati un litigio con i tuoi stessi occhi, perché i byte nell'intestazione non sono scritti nell'ordine in cui l'hash viene normalmente citato.

Hash dell'intestazione del blocco precedente vs ordine dei byte interno

L'hash dell'intestazione del blocco precedente è memorizzato nell'ordine dei byte opposto a quello che tutti citano, e questo confonde quasi chiunque provi a verificare un'intestazione a mano. Il blocco 1 porta l'hash del proprio genitore come 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000. È l'hash del genesi, 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, scritto al contrario un byte alla volta. Gli zeri iniziali prodotti dal proof of work finiscono in coda nel campo grezzo. Non c'è nulla di sbagliato quando i due non corrispondono visibilmente: inverti i byte e corrispondono.