Dubbio su WP Nakamoto

[pf55351]

Salve ragazzi, sto studiando il wp di Nakamoto,
reperibile a questo link

https://bitcoin.org/bitcoin.pdf

mi potete spiegare questa parte

"We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the
next by digitally signing a hash of the previous transaction and the public key of the next owner
and adding these to the end of the coin. A payee can verify the signatures to verify the chain of
ownership."

in merito allo schema subito dopo riportato?

Non riesco a capire come il payeer possa verificare la firma visto che nella transazione ? presente, oltre alla quantita di valore da trasferire, un hash della precedente transazione e chiave pubblica del nuovo proprietario tutto firmato dal vecchio proprietario.... il nuovo proprietario dove pu? reperire la chiave pubblica del vecchio proprietario per verificare la firma?

Grazie
 

[1714787473]

1714787473

[1714787473]

1714787473

[1714787473]

1714787473

[1714787473]

1714787473

[1714787473]

1714787473

[picchio]

Salve ragazzi, sto studiando il wp di Nakamoto,
reperibile a questo link

https://bitcoin.org/bitcoin.pdf

mi potete spiegare questa parte

"We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the
next by digitally signing a hash of the previous transaction and the public key of the next owner
and adding these to the end of the coin. A payee can verify the signatures to verify the chain of
ownership."

in merito allo schema subito dopo riportato?

Non riesco a capire come il payeer possa verificare la firma visto che nella transazione ? presente, oltre alla quantita di valore da trasferire, un hash della precedente transazione e chiave pubblica del nuovo proprietario tutto firmato dal vecchio proprietario.... il nuovo proprietario dove pu? reperire la chiave pubblica del vecchio proprietario per verificare la firma?

Grazie
 

In realtà non firma sulla chiave pubblica che non viene esposta ma sull'address BTC che è una sorta di hash della chiave pubblica.
In effetti mi pare strano questa inesattezza nel paper di Satoshi.
EDIT: pur non risultando errato quanto scritto sopra (da me) non ho risposto alla domanda ... la chiave pubblica va esposta nel momento in cui firmi una transazione, dimostra di essere il proprietario delle transazioni in ingresso che vengono spese. L'esposizione della chiave pubblica mette a rischio la chiave privata piu' di quanto sia la sola esposizione dell'address (in linea teorica), questo spiega il consiglio di inviare il resto ad altro address piuttosto che al mittente.

[Piggy]

Se non ricordo male.

Quando paghi qualcuno imposti delle condizioni che devono essere soddisfatte per reclamare i coin. Il ricevente per spendere i coin deve solo dimostrare di essere il proprietario dell'indirizzo destinatario. Al fine del trasferimento/transazione non gli interessa sapere da chi provengono.

[picchio]

Se non ricordo male.

Quando paghi qualcuno imposti delle condizioni che devono essere soddisfatte per reclamare i coin. Il ricevente per ottenere i coin deve solo dimostrare di essere il proprietario dell'indirizzo destinatario. Al fine del trasferimento/transazione non gli interessa sapere da chi provengono.

Una precisazione. Il ricevente per ottenere le coin non deve fare niente. Quando vuole spenderle deve mostrare la chiave pubblica e firmare dimostrando di avere la chiave privata e quindi essere legittimato a spendere le transazioni (che arrivano comunque anche se l'address non ha chiave privata nota - es: https://en.bitcoin.it/wiki/Proof_of_burn ).

[Piggy]

Se non ricordo male.

Quando paghi qualcuno imposti delle condizioni che devono essere soddisfatte per reclamare i coin. Il ricevente per ottenere i coin deve solo dimostrare di essere il proprietario dell'indirizzo destinatario. Al fine del trasferimento/transazione non gli interessa sapere da chi provengono.

Una precisazione. Il ricevente per ottenere le coin non deve fare niente. Quando vuole spenderle deve mostrare la chiave pubblica e firmare dimostrando di avere la chiave privata e quindi essere legittimato a spendere le transazioni (che arrivano comunque anche se l'address non ha chiave privata nota - es: https://en.bitcoin.it/wiki/Proof_of_burn ).

Si giusto, ho editato.

[pf55351]

Ciao grazie per la risposta ma quindi:


[/quote]
In realtà non firma sulla chiave pubblica che non viene esposta ma sull'address BTC che è una sorta di hash della chiave pubblica.
In effetti mi pare strano questa inesattezza nel paper di Satoshi.[/quote]

Si sono d'accordo sul fatto che nella transazione non viene usata la chiave pubblica ma l'address che è la chiave pubblica su cui vengono eseguite una funziona di hash e opportuna codifica.

[/quote]
EDIT: pur non risultando errato quanto scritto sopra (da me) non ho risposto alla domanda ... la chiave pubblica va esposta nel momento in cui firmi una transazione, dimostra di essere il proprietario delle transazioni in ingresso che vengono spese. L'esposizione della chiave pubblica mette a rischio la chiave privata piu' di quanto sia la sola esposizione dell'address (in linea teorica), questo spiega il consiglio di inviare il resto ad altro address piuttosto che al mittente.
[/quote]

Si concordo anche come funziona il funzionamento di firma digitale, ma lo schema che è riportato nel wp lo hai osservato con attenzione?
Partendo dal presupposto che il wp sono linee guida quindi credo che sia normale che si fa riferimento alla chiave pubblica, ma facendo sempre riferimento allo schema non capisco come si possa verificare la firma...

Ti riporto lo schema per intenderci di cosa sto parlando.





Grazie

[pf55351]

Se non ricordo male.

Quando paghi qualcuno imposti delle condizioni che devono essere soddisfatte per reclamare i coin. Il ricevente per spendere i coin deve solo dimostrare di essere il proprietario dell'indirizzo destinatario. Al fine del trasferimento/transazione non gli interessa sapere da chi provengono.

Le condizioni sono quelle che vengono impostate negli script?

[Piggy]

Se non ricordo male.

Quando paghi qualcuno imposti delle condizioni che devono essere soddisfatte per reclamare i coin. Il ricevente per spendere i coin deve solo dimostrare di essere il proprietario dell'indirizzo destinatario. Al fine del trasferimento/transazione non gli interessa sapere da chi provengono.

Le condizioni sono quelle che vengono impostate negli script?

Si, quelle. Guarda questo se ti può essere d'aiuto https://en.bitcoin.it/wiki/Transaction

[pf55351]

Ragazzi forse nel wp di Nakamoto facendo riferimento a questa immagine



 anche se non è espressamente scritto c'è un puntatore alla transazione precedente da cui posso ricavare appunto hash e verificare con la chiave pubblica - presente nella trx precedente, la firma?

[picchio]

Ragazzi forse nel wp di Nakamoto facendo riferimento a questa immagine



 anche se non è espressamente scritto c'è un puntatore alla transazione precedente da cui posso ricavare appunto hash e verificare con la chiave pubblica - presente nella trx precedente, la firma?

Provo a confonderti le idee.
- all'inizio non ci sono BTC
- ogni blocco crea una revenue in una transazione "coinbase" che valeva, 50BTC, poi 25, ora 12.5 e via halving cantando (fino ad un massimo di 21000000 di btc generati)
- chi ha minato, dopo 120 blocchi, puo' iniziare a "spendere" la coin base.
- decide di inviare parte del premio ad address A e il resto se lo rimette nel suo indirizzo (o dove vuole). Genera due transazioni in uscita. Deve firmare con una chiave privata che genera l'address dichiarato nella coinbase.
- a questo punto "address A" ha una transazione in ingresso con relativo hash e, quando vuole, puo' spenderla interamente in modo analogo a come ha fatto il miner precedentemente. Se non la spende interamente lascia la fee aggiuntiva al miner che mina il blocco che la contiene.

Spero di averti complicato le idee a sufficienza.

In sostanza: quando ricevi basta l'address di ricezione, quando vuoi spendere devi firmare con una delle chiavi private esistenti (non credo abbiano mai trovato due chiavi che portano allo stesso address ma teoricamente è possibile).

Il puntatore alla transazione (TXID) credo sia un hash e ci sono delle considerazioni interessanti sul forging che vanno oltre ...

[pf55351]

[quote ]






In sostanza: quando ricevi basta l'address di ricezione, quando vuoi spendere devi firmare con una delle chiavi private esistenti (non credo abbiano mai trovato due chiavi che portano allo stesso address ma teoricamente è possibile).


[/quote]

Ciao, grazie mille per la risposta.
Sul funzionamento attuale della blockchain per bitcoin sono d'accordo con te per come funziona ora.
Io pero voglio solamente capire quanto è riportato nel wp.

Prova per un attimo a resettare tutto quello che conosci sul funzionamento del bitcoin e leggi quanto ti riporto sotto e guarda la figura :

"We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the
next by digitally signing a hash of the previous transaction and the public key of the next owner
and adding these to the end of the coin. A payee can verify the signatures to verify the chain of
ownership."



Ora in base a quanto vedi nella figura questa frase "A payee can verify the signatures to verify the chain of...." come si concretizza, cioè il beneficiario come verifica la firma?
Per verificare una firma devo conoscere la chiave pubblica del firmatario, questa chiave in base a quello schema dove la recupero?

Non so se è chiaro il dubbio, non voglio conoscere l'attuale funzionamento, ma sto analizzando i concetti da cui sono partiti. E' questo wp o manca qualcosa o ne da per scontato altre... come ti dicevo prima c'è un puntatore alla trx precedente da cui posso leggere la pk.

Grazie

[picchio]

Devi imparare a quotare .... esiste il preview

In sostanza: quando ricevi basta l'address di ricezione, quando vuoi spendere devi firmare con una delle chiavi private esistenti (non credo abbiano mai trovato due chiavi che portano allo stesso address ma teoricamente è possibile).

...
Ora in base a quanto vedi nella figura questa frase "A payee can verify the signatures to verify the chain of...." come si concretizza, cioè il beneficiario come verifica la firma?
Per verificare una firma devo conoscere la chiave pubblica del firmatario, questa chiave in base a quello schema dove la recupero?
...

Nella firma?
Non sono esperto di crittografia ma vorrei approfondire ...
prova a vedere:
https://en.bitcoin.it/wiki/Transaction
https://crypto.stackexchange.com/questions/30297/is-it-usual-for-a-signed-message-to-contain-the-public-key-of-the-signer

[arulbero]

Prova per un attimo a resettare tutto quello che conosci sul funzionamento del bitcoin e leggi quanto ti riporto sotto e guarda la figura :

"We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the
next by digitally signing a hash of the previous transaction and the public key of the next owner
and adding these to the end of the coin. A payee can verify the signatures to verify the chain of
ownership."

…

Ora in base a quanto vedi nella figura questa frase "A payee can verify the signatures to verify the chain of...." come si concretizza, cioè il beneficiario come verifica la firma?
Per verificare una firma devo conoscere la chiave pubblica del firmatario, questa chiave in base a quello schema dove la recupero?

Non so se è chiaro il dubbio, non voglio conoscere l'attuale funzionamento, ma sto analizzando i concetti da cui sono partiti. E' questo wp o manca qualcosa o ne da per scontato altre... come ti dicevo prima c'è un puntatore alla trx precedente da cui posso leggere la pk.

Un paio di precisazioni:

a) nella transazione con cui io invio dei btc dal mio address A a un nuovo address B, è presente una parte, detta "scriptSig" (lo script che i nodi della rete - e in un questo senso anche il ricevente, ma solo in questo senso - devono eseguire per verificare che la transazione sia legittima) che contiene esattamente la chiave pubblica dell'indirizzo A e la firma di A. E' così che si verifica la firma.


Ad esempio, guarda questa transazione: https://blockchain.info/it/tx/2757cdab2acc9f11f32d45c9db9d3bdf23787304ed06a43d3c4ccf15e5def075

L'indirizzo di partenza A è 1AqEgLuT4V2XL2yQ3cCzjMtu1mXtJLVvww,
la sua chiave pubblica: 02cced963cdc06b1881a355f4094a03ef208a9368c2096fb1f6b568508acae973e la trovi facilmente in fondo allo scritpSig.

Se vuoi capire in profondità il funzionamento di una transazione, ti consiglio vivamente http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html


b) L'hash dell'indirizzo B (in questo caso 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa in base 58 = db53d9bbd1f3a83b094eeca7dd970bd85b492fa2 in formato esadecimale) lo trovi facilmente nello scriptPubKey (script di output) sempre della transazione che ti ho linkato.

Questo script sarà eseguito dalla rete solo nel momento in cui il proprietario dell'indirizzo B immetterà in rete una transazione '2' da B verso un indirizzo C. In quel caso lo script di output (scriptPubKey) presente nella transazione '1' verrà eseguito utilizzando la public key inserita nello scriptSig della nuova transazione '2'.

Breve nota storica: Satoshi parla di pagamento a una public key invece che a un hash di una public key

Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key

solo perché all'inizio le transazioni erano P2PK (pay to public key, pagate direttamente a una chiave pubblica) invece delle attuali P2PKH (pay to public key script hash, cioè pagate agli address consueti).

Puoi verificarlo facilmente andando a guardare una qualsiasi transazione in uno dei primi blocchi:

https://blockchain.info/it/tx/7f1f0cbd84a06c073c3164b463eda189fe3f98a9744e553380c23e41d6125c60

Lì si paga direttamente a questa chiave pubblica (non compressa):

04bc3ee049bebf27e6e29403aeb61a1c48acee5d4c3b687252a99add1b7dbe38272e42882747493 f2d2e6c92e22dc46567491f3cd5a25259e269ac66649ef6d871

non all' hash della chiave pubblica (address).

EDIT
Riassumendo: ogni transazione da A a B contiene la chiave pubblica di A e l'indirizzo di destinazione B.
ScriptSig: chiave pubblica di A e firma
ScriptPubKey: indirizzo di destinazione B in formato esadecimale

La verifica viene fatta controllando che la chiave pubblica di A e la firma presenti nello ScriptSig della transazione attuale siano consistenti con l'indirizzo di destinazione A presente nello ScriptPubKey della transazione precedente, quella che ha rifornito A.

Quindi data una transazione, il suo ScriptSig viene eseguito immediatamente, mentre il suo ScriptPubKey verrà eseguito solo nel momento in cui verranno spesi i fondi presenti in B. Ogni ScriptPubKey viene eseguito insieme allo ScriptSig di una transazione successiva, mai insieme allo ScriptSig della stessa transazione.

[arulbero]

mi potete spiegare questa parte

"We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the
next by digitally signing a hash of the previous transaction and the public key of the next owner
and adding these to the end of the coin. A payee can verify the signatures to verify the chain of
ownership."

in merito allo schema subito dopo riportato?

Non riesco a capire come il payeer possa verificare la firma visto che nella transazione ? presente, oltre alla quantita di valore da trasferire, un hash della precedente transazione e chiave pubblica del nuovo proprietario tutto firmato dal vecchio proprietario.... il nuovo proprietario dove pu? reperire la chiave pubblica del vecchio proprietario per verificare la firma?

Tento un altro post, quello precedente mi è venuto troppo tecnico.
L'immagine che hai postato l'ho sempre trovata di non facile lettura, comunque provo a commentarla.

Guardando alla transazione centrale, quella dalla chiave pubblica 1 alla chiave pubblica 2:

Owners'2 Public Key: è la chiave pubblica 2 (l'indirizzo 2 invece non è presente da nessuna parte, poichè all'epoca le transazioni erano P2PK, non P2PKH). Questa chiave si trova in una sezione detta ScriptPubKey (script di output).

Utilizzando quindi la txid della transazione precedente e la chiave pubblica 2 a cui sono destinati i fondi, si ottiene mediante una funzione di hash la

Owners'1 Signature : è la firma che garantisce l'immutabilità della transazione e la sua autenticità. Essa si trova nella sezione detta ScriptSig (script di input).

NB: per realizzare la firma serve ovviamente anche la chiave privata 1, per verificarne l'autenticità serve la chiave pubblica 1 (Owners'1 Public Key) presente nello ScriptPubKey della transazione precedente.

Quello che è cambiato oggi rispetto a quello schema:

1) nello ScriptPubKey è presente l'hash della public key (l'address) invece della public key (per maggiore sicurezza, da P2PK a P2PKH)

2) per il motivo precedente, nello ScriptSig adesso oltre alla firma si aggiunge qui la chiave pubblica 1 che non si trova più nella transazione precedente. In questo modo la chiave pubblica 1 viene esposta solo nel momento in cui si spendono i fondi dell'indirizzo associato ad essa.

Questo è lo schema attuale:



La freccia che va dalla transazione 1 alla 2 sta a indicare che tra i dati che vengono firmati nella transazione 2 compare anche la txid della transazione 1 (in modo analogo a quello che succede con i blocchi della blockchain).

[pf55351]

Prova per un attimo a resettare tutto quello che conosci sul funzionamento del bitcoin e leggi quanto ti riporto sotto e guarda la figura :

"We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the
next by digitally signing a hash of the previous transaction and the public key of the next owner
and adding these to the end of the coin. A payee can verify the signatures to verify the chain of
ownership."

…

Ora in base a quanto vedi nella figura questa frase "A payee can verify the signatures to verify the chain of...." come si concretizza, cioè il beneficiario come verifica la firma?
Per verificare una firma devo conoscere la chiave pubblica del firmatario, questa chiave in base a quello schema dove la recupero?

Non so se è chiaro il dubbio, non voglio conoscere l'attuale funzionamento, ma sto analizzando i concetti da cui sono partiti. E' questo wp o manca qualcosa o ne da per scontato altre... come ti dicevo prima c'è un puntatore alla trx precedente da cui posso leggere la pk.

Un paio di precisazioni:

a) nella transazione con cui io invio dei btc dal mio address A a un nuovo address B, è presente una parte, detta "scriptSig" (lo script che i nodi della rete - e in un questo senso anche il ricevente, ma solo in questo senso - devono eseguire per verificare che la transazione sia legittima) che contiene esattamente la chiave pubblica dell'indirizzo A e la firma di A. E' così che si verifica la firma.


Ad esempio, guarda questa transazione: https://blockchain.info/it/tx/2757cdab2acc9f11f32d45c9db9d3bdf23787304ed06a43d3c4ccf15e5def075

L'indirizzo di partenza A è 1AqEgLuT4V2XL2yQ3cCzjMtu1mXtJLVvww,
la sua chiave pubblica: 02cced963cdc06b1881a355f4094a03ef208a9368c2096fb1f6b568508acae973e la trovi facilmente in fondo allo scritpSig.

Se vuoi capire in profondità il funzionamento di una transazione, ti consiglio vivamente http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html


b) L'hash dell'indirizzo B (in questo caso 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa in base 58 = db53d9bbd1f3a83b094eeca7dd970bd85b492fa2 in formato esadecimale) lo trovi facilmente nello scriptPubKey (script di output) sempre della transazione che ti ho linkato.

Questo script sarà eseguito dalla rete solo nel momento in cui il proprietario dell'indirizzo B immetterà in rete una transazione '2' da B verso un indirizzo C. In quel caso lo script di output (scriptPubKey) presente nella transazione '1' verrà eseguito utilizzando la public key inserita nello scriptSig della nuova transazione '2'.

Breve nota storica: Satoshi parla di pagamento a una public key invece che a un hash di una public key

Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key

solo perché all'inizio le transazioni erano P2PK (pay to public key, pagate direttamente a una chiave pubblica) invece delle attuali P2PKH (pay to public key script hash, cioè pagate agli address consueti).

Puoi verificarlo facilmente andando a guardare una qualsiasi transazione in uno dei primi blocchi:

https://blockchain.info/it/tx/7f1f0cbd84a06c073c3164b463eda189fe3f98a9744e553380c23e41d6125c60

Lì si paga direttamente a questa chiave pubblica (non compressa):

04bc3ee049bebf27e6e29403aeb61a1c48acee5d4c3b687252a99add1b7dbe38272e42882747493 f2d2e6c92e22dc46567491f3cd5a25259e269ac66649ef6d871

non all' hash della chiave pubblica (address).

EDIT
Riassumendo: ogni transazione da A a B contiene la chiave pubblica di A e l'indirizzo di destinazione B.
ScriptSig: chiave pubblica di A e firma
ScriptPubKey: indirizzo di destinazione B in formato esadecimale

La verifica viene fatta controllando che la chiave pubblica di A e la firma presenti nello ScriptSig della transazione attuale siano consistenti con l'indirizzo di destinazione A presente nello ScriptPubKey della transazione precedente, quella che ha rifornito A.

Quindi data una transazione, il suo ScriptSig viene eseguito immediatamente, mentre il suo ScriptPubKey verrà eseguito solo nel momento in cui verranno spesi i fondi presenti in B. Ogni ScriptPubKey viene eseguito insieme allo ScriptSig di una transazione successiva, mai insieme allo ScriptSig della stessa transazione.

Ciao, grazie mille per la risposta, la parte di script ancora la devo approfondire per bene, ma da quello che capisco, correggimi se dico una fesseria, il ricevente di una trx verifica la firma quando deve effettuare lui una transazione verso un altro soggetto e non nel momento in cui la riceve.
Resta comunque il fatto che devo approfondire il linguaggio e le modalità p2pk e p2pkh, detto questo quindi riportando nello schema del wp di Nakamoto che ho linkato più volte, e tralasciando il funzionamento attuale, tu vedendo quello disegno e quanto riportato sopra come faresti a verificare la firma presente nel blocco centrale per esempio?
Secondo te il payee da dove recupera la pk? Non considerare il funzionamento attuale ma solo quello che è scritto nel wp. Spero che sia chiaro quanto sto cercando di capire

Grazie

[pf55351]

mi potete spiegare questa parte

"We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the
next by digitally signing a hash of the previous transaction and the public key of the next owner
and adding these to the end of the coin. A payee can verify the signatures to verify the chain of
ownership."

in merito allo schema subito dopo riportato?

Non riesco a capire come il payeer possa verificare la firma visto che nella transazione ? presente, oltre alla quantita di valore da trasferire, un hash della precedente transazione e chiave pubblica del nuovo proprietario tutto firmato dal vecchio proprietario.... il nuovo proprietario dove pu? reperire la chiave pubblica del vecchio proprietario per verificare la firma?

Tento un altro post, quello precedente mi è venuto troppo tecnico.
L'immagine che hai postato l'ho sempre trovata di non facile lettura, comunque provo a commentarla.

Guardando alla transazione centrale, quella dalla chiave pubblica 1 alla chiave pubblica 2:

Owners'2 Public Key: è la chiave pubblica 2 (l'indirizzo 2 invece non è presente da nessuna parte, poichè all'epoca le transazioni erano P2PK, non P2PKH). Questa chiave si trova in una sezione detta ScriptPubKey (script di output).

Utilizzando quindi la txid della transazione precedente e la chiave pubblica 2 a cui sono destinati i fondi, si ottiene mediante una funzione di hash la

Owners'1 Signature : è la firma che garantisce l'immutabilità della transazione e la sua autenticità. Essa si trova nella sezione detta ScriptSig (script di input).

NB: per realizzare la firma serve ovviamente anche la chiave privata 1, per verificarne l'autenticità serve la chiave pubblica 1 (Owners'1 Public Key) presente nello ScriptPubKey della transazione precedente.

Quello che è cambiato oggi rispetto a quello schema:

1) nello ScriptPubKey è presente l'hash della public key (l'address) invece della public key (per maggiore sicurezza, da P2PK a P2PKH)

2) per il motivo precedente, nello ScriptSig adesso oltre alla firma si aggiunge qui la chiave pubblica 1 che non si trova più nella transazione precedente. In questo modo la chiave pubblica 1 viene esposta solo nel momento in cui si spendono i fondi dell'indirizzo associato ad essa.

Ciao grazie ancora, almeno sul fatto che la figura sia di non facile comprensione siamo d’accordo
Ricapitolo:
Nello script di output trovo hash dell indirizzo corretto sto facendo riferimento alla trx che mii hai linkato prima?
 Quando dici facendo riferimento alla txid precedente ce quindi un puntutatore alla trx di prima dove posso facilemente reperire le info di verifica?

P.S ho risposto mentre stavi pubblicando l ulteriore post

[arulbero]

Ciao, grazie mille per la risposta, la parte di script ancora la devo approfondire per bene, ma da quello che capisco, correggimi se dico una fesseria, il ricevente di una trx verifica la firma quando deve effettuare lui una transazione verso un altro soggetto e non nel momento in cui la riceve.

No, la verifica della firma viene fatta immediatamente dalla rete, non appena la transazione viene "proposta" pubblicamente. Che il ricevente la verifichi personalmente o no non c'entra, in un certo senso è la rete stessa il ricevente. Una transazione non può essere trasmessa nè tantomeno inserita in un blocco se non è prima verificata.

Ciao grazie ancora, almeno sul fatto che la figura sia di non facile comprensione siamo d’accordo
Ricapitolo:
Nello script di output trovo hash dell indirizzo corretto sto facendo riferimento alla trx che mii hai linkato prima?
 Quando dici facendo riferimento alla txid precedente ce quindi un puntutatore alla trx di prima dove posso facilemente reperire le info di verifica?

Ogni transazione non spende mai "direttamente" i btc di un indirizzo, bensì spende un output (o più output) non speso (UTXO) relativo a una transazione precedente. Cioè ci si riferisce a un indirizzo di partenza solo in modo indiretto, mai direttamente. L'indirizzo A di partenza non c'è esplicitamente nella transazione che spende i suoi fondi.

Nella seguente immagine la transazione C spende 2 output non spesi delle transazioni A e B:



E tornando alla transazione che ti ho linkato prima:

Code:

{
   "lock_time":524944,
   "size":226,
   "inputs":[
      {
         "prev_out":{
            "index":0,
            "hash":"ecc8c09284a6f9e6d52cccf7f8f4aef1d0c4a33984375dea4cea70923066078d"
         },
         "script":"483045022100d1dd9918d3b94a2ed5694f405340c153ddcba746309356366d7f30ac5483865002200b655cd3aeaff1f7c127708b3516ff2374f3c9991afdbca2282c6240d91d9ecd012102cced963cdc06b1881a355f4094a03ef208a9368c2096fb1f6b568508acae973e"
      }
   ],
   "version":1,
   "vin_sz":1,
   "hash":"2757cdab2acc9f11f32d45c9db9d3bdf23787304ed06a43d3c4ccf15e5def075",
   "vout_sz":2,
   "out":[
      {
         "script_string":"OP_DUP OP_HASH160 db53d9bbd1f3a83b094eeca7dd970bd85b492fa2 OP_EQUALVERIFY OP_CHECKSIG",
         "address":"1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa",
         "value":5000000,
         "script":"76a914db53d9bbd1f3a83b094eeca7dd970bd85b492fa288ac"
      },
      {
         "script_string":"OP_DUP OP_HASH160 7ea3c6d706587efc37b78f8886aa613459e2af92 OP_EQUALVERIFY OP_CHECKSIG",
         "address":"1CYcLaSSu7RqndeoW27H36uRfpyVJpTuxh",
         "value":50009400,
         "script":"76a9147ea3c6d706587efc37b78f8886aa613459e2af9288ac"
      }
   ]
}

guardando alla parte

Code:

"inputs":[
      {
         "prev_out":{
            "index":0,
            "hash":"ecc8c09284a6f9e6d52cccf7f8f4aef1d0c4a33984375dea4cea70923066078d"
         },

nello script di input c'è il chiaro riferimento al primo (index 0) output non speso di una transazione già presente nella blockchain (hash = txid della transazione), non è presente invece esplicitamente l'indirizzo di partenza 1AqEgLuT4V2XL2yQ3cCzjMtu1mXtJLVvww

In sostanza c'è quindi proprio un puntatore alla transazione precedente, in questo modo le informazioni contenute in questa transazione precedente vengono utilizzate per interpretare anche la transazione attuale (che non avrebbe senso da sola, ma va pensata inserita in una catena di transazioni --> "chain of digital signatures").

EDIT: ho aggiornato anche la risposta https://bitcointalk.org/index.php?topic=4313499.msg39156123#msg39156123 con una versione aggiornata dello schema di Satoshi

[pf55351]

Ciao grazie ancora per l'aiuto....
Provo a fare il punto della situazione vediamo se ho capito:

1. Nello schema mensionato da me si fa riferimento ad una prima versione di bitcoin in cui si pagava direttamente alla chiave pubblica.
In questo caso nella transazione di A verso B, A firma hash di tx precedente e chiave pubblica di B e la rete per verificare la firma, e che quindi sia stato veramente A ad emettere la transazione, recupera la chiave pubblica di A dalla transazione precedente di A, transazione precedente linkata nella transazione attuale

2. Nella versione attuale c'è un doppio controllo in quanto non si paga piu alla chiave ma alla sua hash.
Quindi A che fa una trx verso B, firma sempre hash della trx precedente e la chiave pubblica di B, in piu aggiunge la sua chiave pubblica alla transazione.
La rete fa una doppia verifica in questo caso, dalla transazione precedente verifica che effettivamente la chiave pubblica sia di A e ottenuto questo verifica  che la firma  sia corretta.

Penso che questo sia su per giù quello che hai tentato di raccontarmi  


A questo punto nella trx che mi hai linkato di tipo p2pk

https://blockchain.info/it/tx/7f1f0cbd84a06c073c3164b463eda189fe3f98a9744e553380c23e41d6125c60

Nella parte script input trovo solo la firma di 71 byte corretto?
Mentre nell'output la chiave pubblica di 65 byte?

Ci sono alcune cose che nn mi tornano ma prima di fare domande vorrei capire un attimo, dove posso trovare la transazione vera e propria perche se uso

https://blockchain.info/it/tx/2757cdab2acc9f11f32d45c9db9d3bdf23787304ed06a43d3c4ccf15e5def075?format=json

trovo questo

Code:

ver	1
inputs	
0	
sequence	4294967294
witness	""
prev_out	
spent	true
tx_index	351096178
type	0
addr	"1AqEgLuT4V2XL2yQ3cCzjMtu1mXtJLVvww"
value	55009653
n	0
script	"76a9146bd8842d3d4263059525af64e48f6d7e7a0357e888ac"
script	"483045022100d1dd9918d3b94a2ed5694f405340c153ddcba746309356366d7f30ac5483865002200b655cd3aeaff1f7c127708b3516ff2374f3c9991afdbca2282c6240d91d9ecd012102cced963cdc06b1881a355f4094a03ef208a9368c2096fb1f6b568508acae973e"
weight	904
block_height	524947
relayed_by	"0.0.0.0"
out	
0	
spent	true
tx_index	351116017
type	0
addr	"1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa"
value	5000000
n	0
script	"76a914db53d9bbd1f3a83b094eeca7dd970bd85b492fa288ac"
1	
spent	true
tx_index	351116017
type	0
addr	"1CYcLaSSu7RqndeoW27H36uRfpyVJpTuxh"
value	50009400
n	1
script	"76a9147ea3c6d706587efc37b78f8886aa613459e2af9288ac"
lock_time	524944
size	226
double_spend	false
time	1527588281
tx_index	351116017
vin_sz	1
hash	"2757cdab2acc9f11f32d45c9db9d3bdf23787304ed06a43d3c4ccf15e5def075"
vout_sz	2

Mi da in realtà la versione json di quanto linkato che credo sia diversa da quello che effettivamente viene inviato

Grazie

EDIT:
Ho trovato quello che cercavo tramite blockexplorer che mi sembra quello che fornisce un risultato piu veritiero

La cosa che ora non capisco è la lunghezza della chiave pubblica che risulta di lunghezza pari alla metà di quella che dovrebbe essere.... vedi le transazioni di cui abbiamo fatto riferimento:

TRX con p2hpk
https://blockchain.info/it/tx/2757cdab2acc9f11f32d45c9db9d3bdf23787304ed06a43d3c4ccf15e5def075

TRX con p2pk
https://blockchain.info/it/tx/7f1f0cbd84a06c073c3164b463eda189fe3f98a9744e553380c23e41d6125c60

 

[arulbero]

1. Nello schema mensionato da me si fa riferimento ad una prima versione di bitcoin in cui si pagava direttamente alla chiave pubblica.
In questo caso nella transazione di A verso B, A firma hash di tx precedente e chiave pubblica di B e la rete per verificare la firma, e che quindi sia stato veramente A ad emettere la transazione, recupera la chiave pubblica di A dalla transazione precedente di A, transazione precedente linkata nella transazione attuale

2. Nella versione attuale c'è un doppio controllo in quanto non si paga piu alla chiave ma alla sua hash.
Quindi A che fa una trx verso B, firma sempre hash della trx precedente e la chiave pubblica di B, in piu aggiunge la sua chiave pubblica alla transazione.
La rete fa una doppia verifica in questo caso, dalla transazione precedente verifica che effettivamente la chiave pubblica sia di A e ottenuto questo verifica  che la firma  sia corretta.

Penso che questo sia su per giù quello che hai tentato di raccontarmi  

Sì, tutto corretto.

La cosa che ora non capisco è la lunghezza della chiave pubblica che risulta di lunghezza pari alla metà di quella che dovrebbe essere.... vedi le transazioni di cui abbiamo fatto riferimento:

TRX con p2hpk
https://blockchain.info/it/tx/2757cdab2acc9f11f32d45c9db9d3bdf23787304ed06a43d3c4ccf15e5def075

TRX con p2pk
https://blockchain.info/it/tx/7f1f0cbd84a06c073c3164b463eda189fe3f98a9744e553380c23e41d6125c60

Nella parte script input trovo solo la firma di 71 byte corretto?
Mentre nell'output la chiave pubblica di 65 byte?

La chiave pubblica nello script di ouput della transazione P2PK è di 65 byte (il byte 04 +  64 byte).

In quella transazione P2PKH, come si usa fare solo nelle transazioni più recenti, si usa invece un formato compresso della chiave pubblica (33 byte, il byte 02 o 03 + 32 byte) che si trova nello script di input (per il discorso già fatto chiave pubblica vs. address).

Nella parte di input della transazione P2PK non si trova solo la firma (la firma da sola è di 64 byte, non 71 byte), ma altre informazioni per formattare il messaggio.

Guarda questo scritpSig, preso da http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html, che riguarda una transazione P2PKH del 2014:



la prima parte (che inizia con PUSHDATA 47) corrisponde ai 71 byte che hai visto tu (47 hex = 71 ). Oltre ai 64 byte della firma vera e propria (X e Y) ci sono altri 7 byte che informano dove iniziano e dove finiscono i vari campi.

Come vedi nell'input di una transazione P2PKH c'è anche una parte con la chiave pubblica (PUSHDATA 41, 41 hex = 65 byte), chiave che invece nelle vecchie P2PK era posizionata nell'output della transazione precedente.

Nell'esempio in tabella, trattandosi di una transazione del 2014, si usa ancora il vecchio formato non compresso della chiave pubblica di 65 byte (formato compresso/non compresso non c'entra con P2PK / P2PKH)

[pf55351]

Ciao, grazie perchè mi si sta ricomponendo il puzzle.

La chiave pubblica nello script di ouput della transazione P2PK è di 65 byte (il byte 04 +  64 byte).

Ok chiaro

Nella parte di input della transazione P2PK non si trova solo la firma (la firma da sola è di 64 byte, non 71 byte), ma altre informazioni per formattare il messaggio.

Perfetto

Come vedi nell'input di una transazione P2PKH c'è anche una parte con la chiave pubblica (PUSHDATA 41, 41 hex = 65 byte), chiave che invece nelle vecchie P2PK era posizionata nell'output della transazione precedente.

Chiaro.

Chiaro anche che tipo di chiave pubblica estesa o compressa non dipende dal tipo di script.

In particolare i 32 byte della chiave pubblica compressa corrispondono ai primi 32 byte della chiave pubblica o c'è qualche altro sistema di derivazione?

Una cosa che non capisco se prendo la chiave pubblica dell'esempio precedente cioè: 04bc3ee049bebf27e6e29403aeb61a1c48acee5d4c3b687252a99add1b7dbe38272e42882747493 f2d2e6c92e22dc46567491f3cd5a25259e269ac66649ef6d871

e mi derivo l'indirizzo usando questo tool
http://gobittest.appspot.com/Address

ottengo come indirizzo 18L8V7DaFBjAbzF5rzmZqCym31KAbjDQXC che è uguale a quello riportato nella transazione https://blockchain.info/it/tx/7f1f0cbd84a06c073c3164b463eda189fe3f98a9744e553380c23e41d6125c60

Se faccio però i passaggi da riga di comando già al primo hash sha256 ottengo un valore diverso cosa sbaglio?