Ciao,
Oggi rispondiamo a Michele e Diego, entrambi ci hanno fatto la stessa domanda dal nostro profilo instagram.
Come viene aggiornato il protocollo Bitcoin?
Bene ragazzi, il codice sorgente di Bitcoin è opensource, questo significa che chiunque può vedere il sorgente, valutarne l’integrità e proporre modifiche.
Viene utilizzando un sistema di versionamento chiamato git. Questo permette agli sviluppatori di copiarsi l’intero progetto nel proprio computer, o per usare il gergo tecnico, di clonarlo in modo tale da studiarlo e fare delle modifiche. In realtà in Bitcoin viene effettuato un fork, come da direttiva, ma non andiamo nel dettaglio tecnico di git.
Quando un utente vuole presentare una proposta alla community Bitcoin, deve attenersi alle regole descritte dalla comunità stessa.
Ogni proposta viene etichettata con un BIP, Bitcoin improvement proposal e gli viene assegnato un numero dopo aver passato tutti gli standard imposti. Come è facile intuire esiste comunque una gerarchia di sviluppatori, di coloro che si sono “guadagnati” tramite la meritocrazia il ruolo di maintainers e di lead maintainer, rispettivamente di coloro che sono responsabili dei merge delle pull requests e di quelli che sono responsabili, oltre che del merge delle pull request, anche dei rilasci e delle nomine dei mainteiners.
Le Pull request, sono delle richieste di implementazioni nel codice principale sempre grazie al sistema di versionamento git. Quindi il BIP, come spiegato nel BIP0001, sono dei documenti che devono descrivere la future che l’utente vuole proporre e applicare, al fine di discuterne con la community per essere approvata.
I BIP più conosciuti sono; il BIP32 che si occupa dei wallet deterministici, affrontato in modo dettagliato nel libro Bitcoin dalla teoria alla pratica e nel video corso, o il BIP16 che si occupa del P2SH.
Lo stato dei BIP appena citati sono Final, questo significa che sono stati implementati con successo. Il loro stato potrebbe essere Rejected o Withdrawn o Deferred.
Oggi ci concentreremo sul BIP34, il quale aggiunge un valore unico (altezza del blocco) alle transazioni coinbase per evitare di avere due transazioni con la stessa transaction id. Eh si è capitato che due transazioni differenti avessero lo stesso identificativo!
Vediamo come
In Action
bitcoin-cli getrawtransaction e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468 true
Alla voce blockhash otteniamo l’hash del blocco in cui è contenuta
…
{
“txid”: “e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468”,
… altre informazioni …
“blockhash”: “00000000000743f190a18c5577a3c2d2a1f610ae9601ac046a38084ccb7cd721”,
“confirmations”: 481756,
“time”: 1289781379,
“blocktime”: 1289781379
}
Esaminiamo il blocco utilizzando la chiamata getblock
$ bitcoin-cli getblock 00000000000743f190a18c5577a3c2d2a1f610ae9601ac046a38084ccb7cd721
{
“hash”: “00000000000743f190a18c5577a3c2d2a1f610ae9601ac046a38084ccb7cd721”,
“confirmations”: 546124,
“strippedsize”: 472,
“size”: 472,
“weight”: 1888,
“height”: 91880,
“version”: 1,
“versionHex”: “00000001”,
“merkleroot”: “2f6bf541621f43b8fa5012f976406ef7e379704859a3eeb72ad40e6c85740fe9”,
“tx”: [
“e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468”,
“bc9423e0a8b3571181d8545c0091600d8fc421c380457c45c1ca8c0698f765b8”
],
“time”: 1289781379,
“mediantime”: 1289778439,
“nonce”: 2306754076,
“bits”: “1b0e7256”,
“difficulty”: 4536.353723275037,
“chainwork”: “00000000000000000000000000000000000000000000000001b7fec5a94239f0”,
“nTx”: 2,
“previousblockhash”: “000000000004099656bf4a3fda4db1b25630634afa2a201e975e4df9772df3f3”,
“nextblockhash”: “00000000000cf6204ce82deed75b050014dc57d7bb462d7214fcc4e59c48d66d”
}
La transazione è la prima transazione del blocco.
Esaminiamo un altro blocco,
bitcoin-cli getblock 00000000000271a2dc26e7667f8419f2e15416dc6955e5a6c6cdf3f2574dd08e
{
“hash”: “00000000000271a2dc26e7667f8419f2e15416dc6955e5a6c6cdf3f2574dd08e”,
“confirmations”: 546282,
“strippedsize”: 214,
“size”: 214,
“weight”: 856,
“height”: 91722,
“version”: 1,
“versionHex”: “00000001”,
“merkleroot”: “e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468”,
“tx”: [
“e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468”
],
“time”: 1289723848,
“mediantime”: 1289721987,
“nonce”: 4000543654,
“bits”: “1b0e7256”,
“difficulty”: 4536.353723275037,
“chainwork”: “00000000000000000000000000000000000000000000000001ad0ef2d6094010”,
“nTx”: 1,
“previousblockhash”: “00000000000a30044feb1a9010445c5b6d4cdc3f32ca747cff2525c32976ba42”,
“nextblockhash”: “00000000000ca2e14ae09ec763bdc44846b97d77f31e0145f66a34fe12768712”
}
La prima transazione di questo blocco è la stessa transazione del blocco precedentemente analizzato. Siamo davanti a un double spending? Potrebbe sembrare ma in realtà no.
Partiamo dicendo che il protocollo Bitcoin non vieta la possibilità di creare due transazioni con lo stesso txid, ma sicuramente non porta benefici.
Ma perchè quindi abbiamo due transazioni con lo stesso txid?
- Il primo indizio è che la transazione che stiamo esaminando è una coinbase.
- Il secondo indizio è che è stato lo stesso miner a risolvere entrambi i blocchi.
- Il terzo indizio è che entrambi i reward sono di 50 bitcoin.
Ti ricordi come è ottenuta la transaction id?
Si applica la funzione crittografica SHA256 per due volte sulla transaction data e otteniamo la sua rappresentazione in little endian
La transaction data (in questo caso non segwit) è formata da:
- La version della transazione
- Numero di input
- Input, quindi lo scriptsig
- Numero di output
- Output (scriptPubKey)
- Locktime
La transaction data della txid che stiamo esaminando è la seguente:
$ bitcoin-cli getrawtransaction e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468
01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff060456720e1b00ffffffff0100f2052a01000000434104124b212f5416598a92ccec88819105179dcb2550d571842601492718273fe0f2179a9695096bff94cd99dcccdea7cd9bd943bfca8fea649cac963411979a33e9ac00000000
Facendo il doppio SHA256 e ottenendo la rappresentazione in little endian, otteniamo la txid incriminata.
printf `printf 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff060456720e1b00ffffffff0100f2052a01000000434104124b212f5416598a92ccec88819105179dcb2550d571842601492718273fe0f2179a9695096bff94cd99dcccdea7cd9bd943bfca8fea649cac963411979a33e9ac00000000 | xxd -r -p | sha256sum -b | xxd -r -p | sha256sum -b` | tac -rs ..
e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468
Esatto, le due transazioni hanno la stessa transaction data, ecco perchè hanno lo stesso txid!
Per evitare questo problema è stato introdotto il BIP-34, che obbliga ad inserire l’altezza del blocco all’interno dello scriptSig, risolvendo così il problema. Nel video corso e nel libro Bitcoin dalla teoria alla pratica viene analizzato la transaction data dopo il BIP-34.
Tramite la pratica abbiamo visto un esempio di aggiornamento del protocollo Bitcoin.
In descrizione trovate l’indice di tutti i BIP (https://github.com/bitcoin/bips).
Se il video vi è piaciuto lasciate un mi piace, ciao e alla prossima!
— —
🎥 Canale youtube — Bitcoin in Action
—
🐙 GitHub: https://bit.ly/2Lj3yeY
—
📖 Libro Bitcoin dalla teoria alla pratica (Amazon)
📖 Libro Bitcoin dalla teoria alla pratica (sito ufficiale con pagamento in bitcoin)
📖 Libro Bitcoin dalla teoria alla pratica (Amazon)
📖 Book Bitcoin from theory to practice
—
📖 Tascabile Bitcoin 199 domande (Amazon)
📖 Tascabile Bitcoin 199 domande (sito ufficiale con pagamento in bitcoin)
📖 Pocket Book Bitcoin 199 questions (Amazon)
📖 Pocket Book Bitcoin 199 questions (official website — accept bitcoin)
—
🎥 Video Corso Bitcoin dalla teoria alla pratica
—
I nostri social:
► Twitter , Facebook, Linkedin, Medium, Instagram, Youtube, GitHub
Television isn’t a good idea (Radio Stations)
Email isn’t a good idea (Post offices)
Amazon isn’t a good idea (Retail stores)
Bitcoin isn’t a good idea (Central banks)
In crypto we trust
