pf55351 (OP)
Jr. Member
Offline
Activity: 51
Merit: 1
|
|
June 12, 2018, 02:43:39 PM |
|
Salve, leggendo qui https://en.bitcoin.it/wiki/Blockosservo che un blocco è costituito da vari campi in particolare: e a sua volta header contiene: https://en.bitcoin.it/wiki/Block_hashing_algorithmquindi l hash del blocco risultato dell'operazione di mining non è contenuto propriamente nel blocco sotto forma di risultato del tipo 000000000000000000301fcfeb141088a93b77dc0d52571a1185b425256ae2fb Ma ci sono tutti i dati necessari per rilevarlo cioè calcolo il doppio sha256 dell'aggregato di tutti i campi dell'header, Hash effettivo lo vedrò nel prox blocco come prev hash E' corretto cio? Quando un blocco minato viene inviato alla rete gli altri nodi controllano calcolando effettivamente lhash che questo sia valido?
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
picchio
Legendary
Offline
Activity: 2506
Merit: 1120
|
|
June 12, 2018, 03:09:03 PM |
|
... quindi l hash del blocco risultato dell'operazione di mining non è contenuto propriamente nel blocco sotto forma di risultato del tipo 000000000000000000301fcfeb141088a93b77dc0d52571a1185b425256ae2fb ...
Considera che è impossibile (astronomicamente difficile) avere un file con all'interno informazioni accurate sul suo hash.
|
Waves mi piaceva ora non più.
|
|
|
pf55351 (OP)
Jr. Member
Offline
Activity: 51
Merit: 1
|
|
June 12, 2018, 03:42:10 PM |
|
... quindi l hash del blocco risultato dell'operazione di mining non è contenuto propriamente nel blocco sotto forma di risultato del tipo 000000000000000000301fcfeb141088a93b77dc0d52571a1185b425256ae2fb ...
Considera che è impossibile (astronomicamente difficile) avere un file con all'interno informazioni accurate sul suo hash. Scusa ma se leggo questo blocco ad esempio: https://blockchain.info/it/block/0000000000000000001da9a39e5d43727fdde2ecf14c6ef5da8f34590128689cDelle informazioni riportate nella parte a destra solo quella relativa all hash precedente e il merkle tree trovo all'initerno del blocco. L hash del blocco cioè il risultato dell'operazione di mining non viene scritto nel blocco, questo vorrei capire. E inoltre capire gli altri nodi verificano che il blocco sia valido calcolando anch' essi l hash del blocco in base i dati del blocco stesso ? Grazie
|
|
|
|
goddog
Member
Offline
Activity: 168
Merit: 47
8426 2618 9F5F C7BF 22BD E814 763A 57A1 AA19 E681
|
|
June 12, 2018, 04:18:05 PM Last edit: June 12, 2018, 05:07:04 PM by goddog |
|
l'hash dell'header deve essere inferiore o uguale al target nell'header, oltre al nonce e ad altri dati, c'e' il merkle root che identifica le transazioni e l'hash del blocco blocco precedente. https://bitcoin.org/en/developer-reference#block-headersi nodi spv ad esempio scaricano solo gli header, e controllano che l'hash sia inferiore o uguale al target. i full node invece scaricano tutto il blocco e controllano anche il merkle root. questo ad esempio e' il codice di electrum per controllare l'header. def verify_header(self, header, prev_hash, target): _hash = hash_header(header) if prev_hash != header.get('prev_block_hash'): raise Exception("prev hash mismatch: %s vs %s" % (prev_hash, header.get('prev_block_hash'))) if constants.net.TESTNET: return bits = self.target_to_bits(target) if bits != header.get('bits'): raise Exception("bits mismatch: %s vs %s" % (bits, header.get('bits'))) if int('0x' + _hash, 16) > target: raise Exception("insufficient proof of work: %s vs target %s" % (int('0x' + _hash, 16), target))
EDIT: l'hash dell'header deve essere inferiore o uguale al target
|
|
|
|
pf55351 (OP)
Jr. Member
Offline
Activity: 51
Merit: 1
|
|
June 13, 2018, 10:04:27 AM |
|
Ok si questo è chiaro, ma come vedi nel link che ti ho postato riporta anche l hash del blocco... questo hash li viene mostrato come calcolo dei fari campi dell header ma il valore non è riportato all'interno del blocco. Al max lo vedo nel blocco successivo come prev hash corretto? i nodi spv ad esempio scaricano solo gli header, e controllano che l'hash sia inferiore o uguale al target.
i full node invece scaricano tutto il blocco e controllano anche il merkle root.
E' la verifica che fanno gli altri nodi per accettare il blocco?
|
|
|
|
goddog
Member
Offline
Activity: 168
Merit: 47
8426 2618 9F5F C7BF 22BD E814 763A 57A1 AA19 E681
|
|
June 13, 2018, 12:41:13 PM |
|
Ok si questo è chiaro, ma come vedi nel link che ti ho postato riporta anche l hash del blocco... questo hash li viene mostrato come calcolo dei fari campi dell header ma il valore non è riportato all'interno del blocco. L'hash del blocck non lo calcola nessuno, non ha senso. Ogni client calcola l'hash dell'header e lo confronta con il target. non e' possibile inserire l'hash dell'header nell'header perche', oltre ad essere una informazione ridondante, ne cambierebbe l'hash e quindi andrebbe messo fuori dall'header, dove lo metteresti? Come ti hanno detto anche prima, inserire l'hash nell'header, renderebbe il mining impossibile, vorrebbe dire trovare una collisione. Ti sfido a creare un file, contenente l'hash del file stesso. Al max lo vedo nel blocco successivo come prev hash corretto?
Esatto, se vuoi vedere l'hash dell'header, senza fare calcoli, puoi vederlo nel blocco successivo, e' una informazione che serve a legare i blocchi in una catena. Ma non se non ti calcoli gli hash da solo, non fai nessuna verifica e quindi non puoi sapere se l'hash scritto nel blocco successivo sia reale o solo un numero a caso. i nodi spv ad esempio scaricano solo gli header, e controllano che l'hash sia inferiore o uguale al target.
i full node invece scaricano tutto il blocco e controllano anche il merkle root.
E' la verifica che fanno gli altri nodi per accettare il blocco? esatto, ogni client che si rispetti, calcola almeno l'hash dell'header e lo confronta con il target, per essere sicuro che chi gli invia i dati abbia fornito almeno un prova di lavoro reale e non si sia inventato tutto di sana pianta. Prova di lavoro= sicurezza che il miner abbia speso tempo ed enegia. Rendendo quindi economicamente non conveniente cercare di truffare. Comunque per essere sicuri di trovarsi sulla catena corretta, e che il blocco sia realmente valido, l'unica soluzione e' verificare anche il merkle root, e quindi scaricare tutte le transazioni e ricalcolare tutti gli hash.
|
|
|
|
pf55351 (OP)
Jr. Member
Offline
Activity: 51
Merit: 1
|
|
June 13, 2018, 01:28:50 PM |
|
Ok ora è chiaro, non avevo ben compreso la risposta di prima di picchio esatto, ogni client che si rispetti, calcola almeno l'hash dell'header e lo confronta con il target, per essere sicuro che chi gli invia i dati abbia fornito almeno un prova di lavoro reale e non si sia inventato tutto di sana pianta. Prova di lavoro= sicurezza che il miner abbia speso tempo ed enegia. Rendendo quindi economicamente non conveniente cercare di truffare.
Comunque per essere sicuri di trovarsi sulla catena corretta, e che il blocco sia realmente valido, l'unica soluzione e' verificare anche il merkle root, e quindi scaricare tutte le transazioni e ricalcolare tutti gli hash.
Un'altra cosa non chiara è come un client ad esempio nodo vps utilizzi merkle tree per conoscere la presenza o meno di una trx all'interno del blocco. Se io conosco id della trx (cioè hash) ed ho a disposizione tutti i mt della blockchain visto che li ho scaricati tutti, come ottengo la verifica? P.S. Se devo aprire un ulteriore post lo faccio subito
|
|
|
|
goddog
Member
Offline
Activity: 168
Merit: 47
8426 2618 9F5F C7BF 22BD E814 763A 57A1 AA19 E681
|
|
June 13, 2018, 02:04:28 PM |
|
Un'altra cosa non chiara è come un client ad esempio nodo vps utilizzi merkle tree per conoscere la presenza o meno di una trx all'interno del blocco. Se io conosco id della trx (cioè hash) ed ho a disposizione tutti i mt della blockchain visto che li ho scaricati tutti, come ottengo la verifica?
P.S. Se devo aprire un ulteriore post lo faccio subito
SPV=simple payment verification VPS=virtual private server non centrano niente, occhio a non confonderti un client spv non e' un vero client, non si collega alla rete bitcoin, si collega a un server che a sua volta e' collegato ad un full node. dopo aver verificato l'header dei blocchi il client manda al server gli indirizzi di cui vuole conoscere le transazioni . Il server risponde con le tx rilevanti + gli hash, solo quelli, di tutte le tx contenute nei blocchi interessati, fornendo quindi una proof of inclusion. Il client puo' quindi ricalcolare l'hash della tx in entrata(o uscita) e, utilizzando gli altri hash, calcolare il merkle root e verificarlo con quello del blocco. Questa procedura, non e' standard, e nemmeno e' stata descritta da Satoshi nel suo paper. I wallet spv moderni, mi sembra facciano riferimento a bip37EDIT: dai un occhio a questo flowchart https://gist.github.com/TOMOAKI12345/7e0aa1c6b8ace4a70ca6
|
|
|
|
pf55351 (OP)
Jr. Member
Offline
Activity: 51
Merit: 1
|
|
June 13, 2018, 03:17:58 PM |
|
Ciao, grazie per la risposta: SPV=simple payment verification VPS=virtual private server non centrano niente, occhio a non confonderti
Errore di battitura un client spv non e' un vero client, non si collega alla rete bitcoin, si collega a un server che a sua volta e' collegato ad un full node. dopo aver verificato l'header dei blocchi il client manda al server gli indirizzi di cui vuole conoscere le transazioni . Il server risponde con le tx rilevanti + gli hash, solo quelli, di tutte le tx contenute nei blocchi interessati, fornendo quindi una proof of inclusion. Il client puo' quindi ricalcolare l'hash della tx in entrata(o uscita) e, utilizzando gli altri hash, calcolare il merkle root e verificarlo con quello del blocco.
Se ho capito bene, correggimi se scrivo fesserie, il client svp si scarica tutti gli headers dei vari blocchi dell'intera blockchain, da un nodo full e li verifica calcolando che l hash di ogni header sia minore o uguale al target riportato in ogni header. Poi invia al nodo full l'indirizzo di cui vuole recuperare gli UTXO, il nodo full risponde con la trx dove compare quell'indirizzo piu tutti gli hash delle trx contenuti in quel blocco dal quale può risalire alla merkle root. In questo modo ha la prova che la trx fornita è inclusa effettivamente in quel blocco e recupera anche eventuali UTXO. Questa procedura, non e' standard, e nemmeno e' stata descritta da Satoshi nel suo paper. I wallet spv moderni, mi sembra facciano riferimento a bip37Quindi secondo Nakamto il sistema doveva essere costituito solamente da full node giusto? Grazie FP
|
|
|
|
goddog
Member
Offline
Activity: 168
Merit: 47
8426 2618 9F5F C7BF 22BD E814 763A 57A1 AA19 E681
|
|
June 13, 2018, 03:49:45 PM |
|
Poi invia al nodo full l'indirizzo di cui vuole recuperare gli UTXO, il nodo full risponde con la trx dove compare quell'indirizzo piu tutti gli hash delle trx contenuti in quel blocco dal quale può risalire alla merkle root. In questo modo ha la prova che la trx fornita è inclusa effettivamente in quel blocco e recupera anche eventuali UTXO.
a grandissime linee e' così, in pratica no. Devi guardarti la bip37, che ammetto di non conoscere, non e' che il client manda realmente l'indirizzo(altrimenti non potrebbe conoscere le tx p2sh), fa delle richieste usando dei filtri. Quindi secondo Nakamto il sistema doveva essere costituito solamente da full node giusto?
Grazie FP
no, Nakamoto prevedeva i nodi SPV, anche nel whitepaper, ma non ha dettagliato precisamente come avrebbero dovuto funzionare. Ne ha dato solo delle linee guida generali, piu' o meno come quelle che ti ho dato io.
|
|
|
|
pf55351 (OP)
Jr. Member
Offline
Activity: 51
Merit: 1
|
|
June 13, 2018, 08:13:01 PM |
|
Poi invia al nodo full l'indirizzo di cui vuole recuperare gli UTXO, il nodo full risponde con la trx dove compare quell'indirizzo piu tutti gli hash delle trx contenuti in quel blocco dal quale può risalire alla merkle root. In questo modo ha la prova che la trx fornita è inclusa effettivamente in quel blocco e recupera anche eventuali UTXO.
a grandissime linee e' così, in pratica no. Devi guardarti la bip37, che ammetto di non conoscere, non e' che il client manda realmente l'indirizzo(altrimenti non potrebbe conoscere le tx p2sh), fa delle richieste usando dei filtri. Quindi secondo Nakamto il sistema doveva essere costituito solamente da full node giusto?
Grazie FP
no, Nakamoto prevedeva i nodi SPV, anche nel whitepaper, ma non ha dettagliato precisamente come avrebbero dovuto funzionare. Ne ha dato solo delle linee guida generali, piu' o meno come quelle che ti ho dato io. Ok rido un'occhiata al wp, l'importante pero che il funzionamento a grandi linee del spv
|
|
|
|
|