La Storia del Blocco Alternativo di Genesi di Bitcoin

In questo articolo proverò a spiegare il primo codice sorgente di Bitcoin e a fare delle correlazioni con il codice sorgente attualmente utilizzato. Il mio intento è quello di aiutarvi a comprendere meglio i primi particolari della storia di Bitcoin e della figura di Satoshi Nakamoto. Per quanto riguarda i principianti potrebbe essere un articolo abbastanza complesso da comprendere, anche se ho fatto del mio meglio per renderlo comprensibile a tutti. L’utente medio e gli utenti più esperti sono il mio pubblico di riferimento, per cui per questa categoria di utenti dovrebbe essere facile proseguire nella lettura.

Bitcoin è la criptovaluta per eccellenza: la prima ad essere sviluppata e poi rilasciata. Creata alla fine del 2008 da un gruppo di sviluppatori o uno sviluppatore chiamato Satoshi Nakamoto, il Bitcoin rappresenta oramai il concetto di valuta alternativa tanto che criptovalute e Bitcoin sono entrate nel dizionario come sinonimo.

Nei primi anni del suo sviluppo, molti furono gli appassionati travolti da un nuovo ideale: creare una moneta che fosse slegata da un’entità centrale. Quasi dopo 13 anni, possiamo dire che Satoshi è riuscito ad instillare l’idea in molti appassionati e non di Bitcoin.

C’è una storia però sconosciuta a molti che rivela alcune caratteristiche di come operava o come operavano le persone dietro l’identità anonima di Satoshi Nakamoto. Questo è il riassunto della storia dietro il blocco di genesi “alternativo” di Bitcoin. Tranquilli non stiamo parlando di nessun hack, si tratta solo di una rete alternativa nata prima di Gennaio 2009. Nota che ci riferiremo a Satoshi come una singola persona, anche se devi tenere a mente che più ricerche confermano che fosse composto da un gruppo di sviluppatori.

Gli inizi del progetto

Considereremo la storia sin dal principio, ovvero quando un giorno Satoshi pubblicò su una mailing list di metzdowd il link del whitepaper di Bitcoin, un’idea alquanto “rivoluzionaria”. Talmente “rivoluzionaria” che gli amministratori della mailing list invitarono gli utenti a non parlare di politiche economiche, ma a concentrarsi piuttosto sull’impatto tecnico della tecnologia.

Cryptography@Metzdowd è una mailing list creata per discutere argomenti e novità riguardo la tecnologia della crittografia e il suo impatto politico. Nel 31 ottobre 2008 14:10:00, Satoshi invia la prima e-mail a cryptography@metzdowd dicendo di aver pubblicato un white-paper che descrive una nuova tecnologia, Bitcoin.

Mano a mano che arrivano nuove e-mail molte persone incominciano a discutere con Satoshi riguardo lo sviluppo della nuova moneta. In particolare, all’interno della corrispondenza delle e-mail pubbliche, possiamo citare un passaggio importante di una e-mail del 17 Novembre 2008 inviata a James A. Donald.

Satoshi scrive infatti:

I believe I’ve worked through all those little details over the last year and a half while coding it, and there were a lot of them. The functional details are not covered in the paper, but the sourcecode is coming soon. I sent you the main files. (available by request at the moment, full release soon)

Tradotto:

Penso di aver lavorato su tutti questi piccoli dettagli nel corso dell’ultimo anno e mezzo di programmazione e ce n’erano molti. I dettagli funzionali non sono trattati nel documento, ma il codice sorgente è in arrivo. Vi ho inviato i file principali. (al momento disponibile solo su richiesta, presto il rilascio completo)

Il Codice Sorgente

Il pre-rilascio del codice sorgente è un ottimo punto di osservazione per neofiti e principianti che vogliono iniziare nello studio del codice sorgente di Bitcoin. Il pre-rilascio infatti può essere considerato un prototipo (minimum viable product) di quello che diventerà Bitcoin.

Il codice sorgente però era disponibile solo su richiesta e Satoshi fino a quel momento non era conosciuto come oggi. Un utente (Cryddit - aka Ray Dillinger) che ricevette il codice sorgente però alla fine del 2013 decise di pubblicarlo sul forum BitcoinTalk.org. L’utente riporta il codice sorgente così come l’ha ricevuto, rimuovendo di fatto però alcune informazioni come metadata.

È tuttora possibile scaricarne una copia da Nakamoto Institute - bitcoin-nov08.tgz. Il codice sorgente della primissima versione di Bitcoin consta di 4 file:

• node.cpp e node.h - codice per il nodo (accettazione dei blocchi)
• main.cpp e main.h - parti: wallet, transazioni, blocchi (read from disk), genesis block

Naturalmente il codice sorgente non conteneva tutti i file necessari per la generazione di un binario. Si può ipotizzare che Satoshi non avesse incluso tutti i file per timore che qualcun altro potesse copiare la sua idea, o banalmente perché ci stava ancora lavorando sopra. È confermato inoltre che la primissima versione del codice sorgente è pesantemente modificata e molti dei commenti originari sono stati rimossi.

All’interno del codice sorgente poi vengono menzionati alcuni file mancanti, in particolare troviamo:

• headers.h - probabilmente un file globale che conteneva tutti i riferimenti alle librerie;
• sha.h - file di libreria per includere l’algoritmo di hashing SHA;

Una delle prime stranezze, confrontando il codice sorgente con un altro più vicino (Bitcoin 0.1) ma più completo, era l’aggiunta del file di header sha.h. Sembra Satoshi si sia dimenticato di rimuoverlo, dato che sha.h non viene utilizzato da nessuna parte. Inoltre il file sha.h non è stato scritto da Satoshi, dato che è codice di pubblico dominio (più precisamente cryptopp).

Viene quindi da sé pensare che ci possa essere una terza ipotesi (e più valida): Satoshi rilasciando la primissima versione del codice sorgente voleva ottenere feedback dagli esperti sulle parti più importanti del progetto, tralasciando tutte le altre parti superflue. In particolare cercava di ottenere feedback sulla parte di networking, gestione delle transazioni e la catena a blocchi.

Un’altra stranezza che è possibile trovare all’interno di node.cpp (funzione ThreadBitcoinMiner) consiste nella menzione di un miner (funzione BitcoinMiner()) che però effettivamente non viene incluso all’interno del codice sorgente. Il file script.cpp non è stato incluso, così come non sono stati inclusi tutti gli altri file per la generazioni di chiavi pubbliche/private.

Genesis Block

Ora che abbiamo una visione di massima del codice sorgente, possiamo addentrarci in quello che sembra una storia non vera. Partiamo dall’introduzione della blockchain. Satoshi nel whitepaper che descrive Bitcoin ipotizza una chain (catena) in cui vengono inseriti dei blocchi che contengono le transazioni. All’interno della primissima versione del codice sorgente, la chain è stata chiamata “timechain”.

I blocchi sono vincolati tra di loro da una “catena”: all’interno di ogni blocco c’è un hash che consente di collegare due blocchi in modo matematico. Se c’è un blocco con un hash invalido, i successivi blocchi ad esso collegati saranno invalidi.

Tra tutti i blocchi inseriti nella catena, uno in particolare è molto speciale: il genesis block, il primo blocco della blockchain che viene minato dal proprietario del codice sorgente. Questo blocco è il punto di creazione della blockchain e rappresenta l’unico blocco effettivamente emesso da un’autorità centralizzata.

Per capire più tecnicamente come il genesis block viene inserito all’interno della blockchain, possiamo analizzare la primissima versione di Bitcoin. Siamo interessati a scoprire come viene inizializzata la blockchain e quale blocco inserisce. Il blocco di genesi viene inserito tramite la funzione LoadBlockIndex. All’interno del codice è stato inserito questo commento, probabilmente per verificare il corretto funzionamento:

//// debug
// Genesis Block:
// GetHash()      = 0x000006b15d1327d67e971d1de9116bd60a3a01556c91b6ebaa416ebc0cfaa646
// hashPrevBlock  = 0x0000000000000000000000000000000000000000000000000000000000000000
// hashMerkleRoot = 0x769a5e93fac273fd825da42d39ead975b5d712b2d50953f35a4fdebdec8083e3
// txNew.vin[0].scriptSig      = 247422313
// txNew.vout[0].nValue        = 10000
// txNew.vout[0].scriptPubKey  = OP_CODESEPARATOR 0x31D18A083F381B4BDE37B649AACF8CD0AFD88C53A3587ECDB7FAF23D449C800AF1CE516199390BFE42991F10E7F5340F2A63449F0B639A7115C667E5D7B051D404 OP_CHECKSIG
// nTime          = 1221069728
// nBits          = 20
// nNonce         = 141755
// CBlock(hashPrevBlock=000000, hashMerkleRoot=769a5e, nTime=1221069728, nBits=20, nNonce=141755, vtx=1)
//   CTransaction(vin.size=1, vout.size=1, nLockTime=0)
//     CTxIn(COutPoint(000000, -1), coinbase 04695dbf0e)
//     CTxOut(nValue=10000, nSequence=4294967295, scriptPubKey=51b0, posNext=null)
//   vMerkleTree: 769a5e

Campi di un Blocco

Per facilitare meglio la comprensione da parte del lettore possiamo individuare i seguenti campi e identificare alcune differenze con l’attuale versione standard di Bitcoin. La definizione del blocco è disponibile nel file main.h di cui riportiamo la sezione dove vengono definiti i campi.

class CBlock
{
public:
    // header
    uint256 hashPrevBlock;
    uint256 hashMerkleRoot;
    unsigned int nTime;
    unsigned int nBits;
    unsigned int nNonce;

    // network and disk
    vector<CTransaction> vtx;

    // memory only
    mutable vector<uint256> vMerkleTree;

    // ...
}

Hash del blocco

L’hash è una particolare stringa che si riferisce all’applicazione della funzione di hash al block header (campo hash). Una funzione di hash è una funzione che prende in input dei dati di qualsiasi dimensione e produce una sequenza di bit strettamente correlata con l’input. Dalla sequenza di bit non si può risalire facilmente all’input originale.

Sappiamo che ogni blocco può essere diviso in intestazione (una serie di dati globali) e nel corpo (il contenuto principale del blocco: le transazioni). La funzione sha256(sha256(header_blocco)) restituisce l’hash 0x000006b15d1327d67e971d1de9116bd60a3a01556c91b6ebaa416ebc0cfaa646. Il significato del campo hash del blocco non è stato modificato nell’attuale versione di Bitcoin.

Hash del blocco precedente

Per far sì che la coda di blocchi abbia un certo senso, ogni blocco deve contenere un riferimento al blocco precedente (campo hashPrevBlock). L’utilizzo di un hash per riferirsi al blocco precedente è molto efficace per due motivi.

Il primo risiede nel fatto che c’è un collegamento “matematico”, verificabile, che consente ad un nodo di ignorare eventuali blocchi che non appartengono alla catena. Il secondo invece consiste in un’ottimizzazione per la ricerca di un blocco all’interno.

Uno dei più famosi algoritmi di ricerca all’interno di una struttura dati consiste nelle tabelle hash. In poche parole, applico ad ogni elemento una funzione di hash e mappo ogni hash su una posizione di memoria a me nota. Per controllare se un elemento esiste o meno, basta accedere alla posizione di memoria in cui è stato mappato l’hash. In tempo costante O(1) potrei cercare il blocco all’interno della catena tramite l’hash. Naturalmente la ricerca di un blocco varia da progetto a progetto.

Nel particolare caso del blocco di genesi, l’hash del blocco precedente è impostato a 0. Il campo ha lo stesso significato nell’attuale versione di Bitcoin.

Radice del Merkle Tree

Il Merkle Tree è una struttura dati pesantemente utilizzata all’interno di Bitcoin. La struttura dati fa parte della categoria delle strutture dati ad alberi composti da nodi. Ipotizziamo di avere un grafo, in cui ci sono dei singoli nodi collegati tra di loro. I grafi abitualmente possono svilupparsi in ogni direzione, incluso verticale, orizzontale e molti altri ancora.

Il grafo ad albero è un particolare grafo che si sviluppa dall’alto verso il basso: in alto c’è il nodo da cui parte il grafo, mentre scorrendo via via dall’alto verso il basso troviamo i diversi nodi. Chiamiamo figli di x i nodi che sono connessi al nodo x. Il nodo che sta “sopra” al nodo di x, si chiama parent di x. I grafi ad albero hanno un vertice radice, da questa nascono vari archi –“rami” nell’analogia dell’albero – che collegano la radice a nuovi vertici.

Ogni vertice può a sua volta avere rami che nascono e che puntano a nuovi vertici, i vertici finali, senza rami in uscita, si dicono “foglie”. I Merkle Tree che Bitcoin utilizza sono costruiti a partire dalle foglie. Ogni foglia contiene l’hash di una transazione (se dispari, l’ultima viene duplicata), una coppia alla volta i contenuti delle foglie vengono concatenati ed viene applicata la funzione di hash per creare un nuovo vertice. Il procedimento viene ripetuto strato dopo strato fino a che non rimangono solo due vertici che quindi concatenati ed hashati creano l’hash della radice.

Per verificare quindi la struttura dati che contiene le transazioni, è sufficiente controllare l’hash della radice del Merkle Tree, ovvero il campo hashMerkleRoot. Il Merkle Tree è un modo compatto di rappresentare quell’insieme di transazioni, è usato come una specie di checksum. Viene controllato che un nuovo blocco con quell’esatto hash di root ha sicuramente un set di transazioni che, manipolato in merkle tree, ritorna l’hash della radice.

Senza il Merkle Tree il nodo Bitcoin sarebbe costretto per ogni blocco a verificare N transazioni. Ipotizzando M blocchi e N transazioni, il tempo sarebbe proporzionale a O(N * M), in confronto all’utilizzo del Merkle Tree O(1). Per questo blocco, il valore è 0x769a5e93fac273fd825da42d39ead975b5d712b2d50953f35a4fdebdec8083e3.

Le Transazioni

Il contenuto del blocco è rappresentato da un insieme di transazioni (campo txNew). Ogni blocco (classe CBlock) ha infatti al suo interno un vettore di transazioni chiamato vtx.

Riassumiamo in tabella i campi per una transazione:

La transazione del primo blocco è una transazione coinbase, composta da un input e un output. Riconosciamo che si tratta di una transazione coinbase, ovvero di creazione della moneta, da un elemento fondamentale: il numero degli input è pari a 1 (questa condizione è esplicita nel codice di Satoshi). Questa transazione viene inviata a colui che l’ha minata, ovvero Satoshi, ottenendo così i primi Bitcoin. In questo blocco 10.000 che equivale a “1 CENT”, secondo la prima denominazione utilizzata da Satoshi. Possiamo trovare anche scriptPubKey: uno script che indica una condizione. Se questa condizione è vera, allora la transazione si può spendere altrimenti no.

Purtroppo per un problema presente anche nella prima versione pubblica di Bitcoin, Satoshi non poté mai spendere i soldi di quella transazione. Come possiamo verificare con il codice, quando si inserisce il blocco di genesi all’interno della blockchain, lo sviluppatore dovrebbe inserire la transazione anche nella struttura dati che contiene tutte le transazioni. Satoshi però non incluse la prima transazione: il blocco quindi esiste, la transazione invece non esiste per il sistema, anche se rimane inclusa dentro il blocco di genesi.

Nel campo di output, l’ammontare per la prima transazione è impostato a 10000 (campo nValue). Viene inoltre specificato una scriptPubKey: è un campo che specifica una certa condizione (in questo caso OP_CHECKSIG). Se questa condizione risulta vera, allora la transazione è valida e l’importo si può spendere. Per una panoramica più approfondita sullo scriptPubKey, vi consiglio di leggere la sezione “Script” della wiki di Bitcoin.

Facciamo l’esempio di costruire una transazione normale in cui vogliamo usare un input “A”, che è l’output di una transazione precedente. La transazione precedente aveva specificato, per “A”, uno scriptpubkey, che nel caso più semplice contiene una chiave pubblica e la richiesta di firmare con quella chiave (OP_CHECKSIG). Quando si costruisce la transazione usando “A” come input, si deve fornire uno scriptsig che è, nel caso semplice, la versione firmata della transazione in costruzione con la chiave specificata dallo sciptpubkey precedente (la “transazione in costruzione” è la transazione con tutti i campi compilati tranne gli scriptsig, che devono essere vuoti). La particolarità del blocco genesi è che il campo scriptsig è completamente arbitrario: non c’era nessuna transazione precedente da cui prendere le regole di convalida, quindi Satoshi ha inserito quello che voleva.

Timestamp

Il nome è piuttosto autodescrittivo. Il campo timestamp rappresenta il numero di secondi passati dal Unix Epoch (la data del 1° Gennaio 1970). Per questo blocco, il valore timestamp è 1221069728 e si riferisce a mercoledì 10 settembre 2008, alle ore 18:02:08 (GMT).

Il blocco infatti sembra essere stato aggiunto il 10 Settembre 2008. “Sembra” perché non è certo che sia stato aggiunto alla catena proprio quel giorno. Piuttosto, il 10 Settembre 2008 ci ricorda un evento molto importante.

Nota che questo tipo di associazione è molto “speculativo” e non ci sono altre prove sul fatto che Satoshi intendesse collegare questo evento alla propria blockchain. Tuttavia, la coincidenza rimane curiosa. Qualcuno potrebbe sicuramente dibattere sul fatto che scegliendo qualsiasi data, un “complottista” può trovare una coincidenza. Satoshi restava molto contrario alle banche e l’aggiunta del blocco in quel preciso istante mi fa pensare che a tavolino abbia messo quella data.

Target/Difficoltà

Il campo nBits è l’unico campo che presenta una sostanziale differenza con l’attuale versione di Bitcoin. Nella versione standard (quella attuale) è target section: l’hash dell’intestazione del blocco deve essere inferiore o uguale affinché il blocco venga accettato dalla rete. Più il valore del campo target è basso, più è difficile estrarre il blocco.

Nella primissima versione, il campo nBits riguarda il mining, ma rappresenta la quantità minima di “lavoro” da poter fare prima che il blocco venga accettato. Sembra che sia un’inversione del significato: rappresenta il numero minimo di “lavoro” che deve essere svolto per poter essere accettato dalla rete. In parole povere, l’hash prodotto dal mining oltre ad essere valido deve essere maggiore di nBits. Infatti il valore del campo nBits è uguale alla costante dichiarata nel file main.h chiamata MINPROOFOFWORK con il commento “ridiculously easy for testing”.

Nonce

Il campo nonce è un numero arbitrario scelto dal miner che viene utilizzato per rispettare il vincolo sull’hash. L’hash del blocco infatti deve iniziare con un numero di zero. Il campo nNonce è lo stesso utilizzato nella versione attuale di Bitcoin.

Il codice

A seguire il codice riportato nel main.cpp per inserire il blocco all’interno della blockchain.

CTransaction txNew;
txNew.vin.resize(1);
txNew.vout.resize(1);
txNew.vin[0].scriptSig     = CScript() << 247422313;
txNew.vout[0].nValue       = 10000;
txNew.vout[0].scriptPubKey = CScript() << OP_CODESEPARATOR << CBigNum("0x31D18A083F381B4BDE37B649AACF8CD0AFD88C53A3587ECDB7FAF23D449C800AF1CE516199390BFE42991F10E7F5340F2A63449F0B639A7115C667E5D7B051D404") << OP_CHECKSIG;
CBlock block;
block.vtx.push_back(txNew);
block.hashPrevBlock = 0;
block.hashMerkleRoot = block.BuildMerkleTree();
block.nTime  = 1221069728;
block.nBits  = 20;
block.nNonce = 141755;

Scopriamo così che il primo blocco minato da Satoshi è il genesis block di una rete alternativa probabilmente utilizzata a scopo di test. L’hash del blocco è: 0x000006b15d1327d67e971d1de9116bd60a3a01556c91b6ebaa416ebc0cfaa646.

Questo è il primo blocco (definito anche “blocco alternativo” o “pre-genesis block”) che Satoshi ha inserito all’interno della sua catena a blocchi. Ricordiamo infatti che tale blocco non viene riportato da nessun’altra parte. Se non fosse stato per il codice sorgente rilasciato sul forum di BitcoinTalk nessuno saprebbe la storia dietro questo particolare hash. La blockchain da cui parte ufficialmente Bitcoin non contiene infatti quel pre-genesis block, bensì un altro che include la famosa frase “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks” (“The Times 03/Jan/2009 Il cancelliere sull’orlo del secondo salvataggio delle banche”) e da cui tutto partì.

Perché però non includere questo blocco di pre-genesis all’interno della blockchain di Bitcoin? Satoshi doveva agire nella massima trasparenza. Non era ammissibile che il creatore del progetto potesse partire con una blockchain già composta da blocchi (con delle transazioni). Creare un nuovo genesis block che potesse essere stato originato nella data di rilascio del codice aveva senso.

Rispetto alla versione attualmente in uso non troviamo il campo version che indica la versione del blocco. La mancanza di questo campo sembra causare un problema come confermato da un commento presente all’interno del metodo ConnectBlock: //// issue here: it doesn't know the version (tradotto: problema qui: non conosce la versione, riferendosi al nodo). Volendo essere pignoli e maliziosi, questo è uno dei pochi commenti ad utilizzare quattro slash al posto di due. L’altro commento che suscita curiosità è questo: //// is this all we want to do if there's a file error like this? (tradotto: è tutto ciò che vogliamo fare se c’è un errore come questo?). A chi si riferiva Satoshi quando parlava al plurale?

Poteva effettivamente riferirsi ad un gruppo di persone con cui collaborava? Si poteva forse riferire ai primi reviewer della mailing list di Metzdowd? Satoshi però non è nuovo ad introdurre alcuni red herring, ossia elementi che potrebbero condurre a piste false. Questo commento insieme agli altri potrebbe rappresentare una falsa pista, non confermando il fatto che dietro Satoshi ci fosse più di una persona.

Chi c’è dietro Satoshi

L’identità dietro Satoshi è da sempre stato un mistero fin dall’inizio della storia dei bitcoin. Diversi sono stati gli speculatori che hanno puntato il dito contro personaggi di spicco nel campo dell’informatica e dell’economia. Da personaggi globali (Elon Musk) a fanatici, è chiaro che il puzzle appassiona molte persone.

Analisi stilometriche sono state eseguite sui testi prodotti da Satoshi, incluso i messaggi inviati all’interno del forum bitcointalk, le e-mail e il white-paper, testo principale della sua produzione. Hanno provato a raccogliere informazioni sulle prime persone che orbitarono vicino a Satoshi (Hal Finney, Nick Szabo)

Nel corso degli anni, personaggi truffaldini, come ad esempio Craig Wright, si sono fatte avanti dicendo di essere Satoshi. Certo è che l’unico modo per verificare se una persona è realmente Satoshi è attraverso le chiavi PGP. Se una persona riesce a firmare un messaggio con la chiave privata di Satoshi, ci sono due possibilità: la persona è realmente Satoshi oppure la chiave privata è stata trafugata.

Restano poi moltissimi punti oscuri sulla nascita di Bitcoin che la persona reale dietro lo pseudonimo Satoshi Nakamoto potrebbe aiutare a svelare.

Alcuni hanno azzardato che dietro Satoshi potrebbe esserci un gruppo di persone, il che spiegherebbe perché le analisi stilometriche abbiano fallito (o forse perché c’è stato molto bias sugli studi). All’interno della comunità di Bitcoin, sono presenti alcuni studi che confutano o confermano il collegamento tra una persona e Satoshi; questi studi però analizzano un set di dati piuttosto restrittivo ed un numero alquanto limitato di persone.

È possibile però svelare un particolare molto importante sulla personalità di Satoshi Nakamoto. Il fatto di aver scelto il genesis block con un certo timestamp (che includesse la frase dell’articolo del Times) fa capire quanta preparazione e meticolosità ci sia dietro l’identità di Satoshi. Satoshi non voleva che l’anteprima del codice sorgente fosse pubblicata. La preparazione a tavolino della moneta, alcuni dei commenti individuati all’interno dei primi commit SVN e il perfezionismo a cui mirava potrebbero suggerire che Satoshi sia una figura creata ad “hoc” da un gruppo di persone. Queste ovviamente rimangono solo speculazioni; per attribuire effettivamente un’identità a Satoshi servirebbero più sforzi da parte della comunità, reperendo più informazioni possibili da eventuali conversazioni.

Come sempre, se avete qualche informazione in più o se avete individuato qualche errore, vi invito a contattarmi tramite email (Chiave PGP). Se vi piace questo post fatemelo sapere, potrei continuare con più analisi sul codice sorgente della primissima versione di bitcoin.