Struttura Blocco

[pf55351]

Salve, leggendo qui

https://en.bitcoin.it/wiki/Block

osservo che un blocco è costituito da vari campi in particolare:

e a sua volta header contiene:

https://en.bitcoin.it/wiki/Block_hashing_algorithm

quindi 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?

[picchio]

...
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.

[pf55351]

...
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/0000000000000000001da9a39e5d43727fdde2ecf14c6ef5da8f34590128689c

Delle 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]

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-headers

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.

questo ad esempio e' il codice di electrum per controllare l'header.

Code:

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]

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-headers

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]

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-headers

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]

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]

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 bip37

EDIT: dai un occhio a questo flowchart
https://gist.github.com/TOMOAKI12345/7e0aa1c6b8ace4a70ca6

[pf55351]

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 bip37

Quindi secondo Nakamto il sistema doveva essere costituito solamente da full node giusto?


Grazie
FP

[goddog]

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]

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