adesso mi studio tutto per bene che quando sembra di aver capito ti si apre un modno nuovo.
Nel caso ci risentiamo da queste parti
Topic: Dubbio su WP Nakamoto (Read 482 times)
Grazie mille ancora,
adesso mi studio tutto per bene che quando sembra di aver capito ti si apre un modno nuovo.
Nel caso ci risentiamo da queste parti
adesso mi studio tutto per bene che quando sembra di aver capito ti si apre un modno nuovo.
Nel caso ci risentiamo da queste parti
Parecchio interessante grazie per la spiegazione dettagliata, stavo provando a rispondere nell altro thread, ma non era chiaro neanche a me nel dettaglio il funzionamento e mi sono perso per strada
Prego, ma è spiegato molto meglio su Mastering Bitcoin. Lì ci sono molti più dettagli.
Parecchio interessante grazie per la spiegazione dettagliata, stavo provando a rispondere nell altro thread, ma non era chiaro neanche a me nel dettaglio il funzionamento e mi sono perso per strada
Innanzitutto ti consiglio caldamente di leggerti questi:
https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc
https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidoc
http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
Partiamo dalla tua transazione in formato hex:
https://blockchain.info/tx/7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45?format=hex
https://blockchain.info/it/decode-tx :
Guardiamo solo allo script di input:
lo decodifichiamo con http://chainquery.com/bitcoin-api/decodescript :
Osserviamo che ci sono due blocchi di istruzioni: la prima parte
è una firma (sequence 30, length 45, integer 02, length 21, X = ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf883, … vedi tabella "pushdata47" di qualche risposta fa)
Selezioniamo la seconda parte, che è uno script :
e quindi la decodifichiamo a sua volta http://chainquery.com/bitcoin-api/decodescript :
da qui si vede che è uno script multisig 1 su 1 della forma:
1 1 OP_CHECKMULTISIG
dove la pubKey è
042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6 eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf
Riassumendo:
nella transazione precedente abbiamo lo script di output della forma
che contiene l'hash di uno script a questo stadio ancora sconosciuto alla rete;
nella transazione attuale, nello script di input abbiamo:
la firma
+ lo script in chiaro che corrisponde a quello il cui hash è contenuto nell'output della precedente tx:
Dunque si procede così:
Se l'hash160 dello script inserito nell'input coincide con l'hash fornito dalla transazione precedente, allora viene eseguito il controllo finale sulla firma:
si realizza così la verifica e si autorizza lo sblocco dei fondi collegati all'UTXO.
https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc
https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidoc
http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
Partiamo dalla tua transazione in formato hex:
https://blockchain.info/tx/7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45?format=hex
Quote
0100000001c8cc2b56525e734ff63a13bc6ad06a9e5664df8c67632253a8e36017aee3ee4000000 0009000483045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33b f88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b7900145514 1042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea 6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51aefeffffff0120f40e0000000 0001976a9141d30342095961d951d306845ef98ac08474b36a088aca7270400
https://blockchain.info/it/decode-tx :
Code:
{
"lock_time":272295,
"size":229,
"inputs":[
{
"prev_out":{
"index":0,
"hash":"40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8"
},
"script":"00483045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001455141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae"
}
],
"version":1,
"vin_sz":1,
"hash":"7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45",
"vout_sz":1,
"out":[
{
"script_string":"OP_DUP OP_HASH160 1d30342095961d951d306845ef98ac08474b36a0 OP_EQUALVERIFY OP_CHECKSIG",
"address":"13fLLox43yXYvfoZadXpGbkTUXkW8bhqut",
"value":980000,
"script":"76a9141d30342095961d951d306845ef98ac08474b36a088ac"
}
]
}
"lock_time":272295,
"size":229,
"inputs":[
{
"prev_out":{
"index":0,
"hash":"40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8"
},
"script":"00483045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001455141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae"
}
],
"version":1,
"vin_sz":1,
"hash":"7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45",
"vout_sz":1,
"out":[
{
"script_string":"OP_DUP OP_HASH160 1d30342095961d951d306845ef98ac08474b36a0 OP_EQUALVERIFY OP_CHECKSIG",
"address":"13fLLox43yXYvfoZadXpGbkTUXkW8bhqut",
"value":980000,
"script":"76a9141d30342095961d951d306845ef98ac08474b36a088ac"
}
]
}
Guardiamo solo allo script di input:
Code:
"script":"00483045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001455141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae"
lo decodifichiamo con http://chainquery.com/bitcoin-api/decodescript :
Code:
{
"result": {
"asm": "0 3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001 5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae",
"type": "nonstandard",
"p2sh": "3PDibfe9au3sruD1ZmwbMh7fMsYG9aL9nr"
},
"error": null,
"id": null
}
"result": {
"asm": "0 3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001 5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae",
"type": "nonstandard",
"p2sh": "3PDibfe9au3sruD1ZmwbMh7fMsYG9aL9nr"
},
"error": null,
"id": null
}
Osserviamo che ci sono due blocchi di istruzioni: la prima parte
Code:
3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001
è una firma (sequence 30, length 45, integer 02, length 21, X = ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf883, … vedi tabella "pushdata47" di qualche risposta fa)
Selezioniamo la seconda parte, che è uno script :
Code:
5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae
e quindi la decodifichiamo a sua volta http://chainquery.com/bitcoin-api/decodescript :
Code:
{
"result": {
"asm": "1 042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf 1 OP_CHECKMULTISIG",
"reqSigs": 1,
"type": "multisig",
"addresses": [
"1Fz5s6qVFwP3MDGeNav4ESQXFMpm8ELzUw"
],
"p2sh": "3P14159f73E4gFr7JterCCQh9QjiTjiZrG"
},
"error": null,
"id": null
}
"result": {
"asm": "1 042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf 1 OP_CHECKMULTISIG",
"reqSigs": 1,
"type": "multisig",
"addresses": [
"1Fz5s6qVFwP3MDGeNav4ESQXFMpm8ELzUw"
],
"p2sh": "3P14159f73E4gFr7JterCCQh9QjiTjiZrG"
},
"error": null,
"id": null
}
da qui si vede che è uno script multisig 1 su 1 della forma:
1
dove la pubKey è
042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6 eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf
Riassumendo:
nella transazione precedente abbiamo lo script di output della forma
Code:
HASH160 PUSHDATA(20) e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a EQUAL
che contiene l'hash di uno script a questo stadio ancora sconosciuto alla rete;
nella transazione attuale, nello script di input abbiamo:
la firma
Code:
0
+ lo script in chiaro che corrisponde a quello il cui hash è contenuto nell'output della precedente tx:
Code:
<1 pubKey 1 OP_CHECKMULTISIG>
Dunque si procede così:
Code:
<1 pubKey 1 OP_CHECKMULTISIG> HASH160 EQUAL
Se l'hash160 dello script inserito nell'input coincide con l'hash fornito dalla transazione precedente, allora viene eseguito il controllo finale sulla firma:
Code:
0 signature 1 pubKey 1 OP_CHECKMULTISIG
si realizza così la verifica e si autorizza lo sblocco dei fondi collegati all'UTXO.
Gli scritpSig sono gli unlocking script, gli script di output sono invece i locking script. Tu hai scritto il contrario. +
si è vero ma il concetto è chiaro
Quote
La transazione 40eee... che stai guardando non è P2PKH ma P2PSH, si capisce dallo script di output (gli opt code sono diversi da quelli di un output verso un address)
Lo avrei dovuto capire da questo. EQUAL
Quote
infatti l'indirizzo di destinazione inizia con un 3 anzichè con il classico 1.
1 o 3 ti riferisci al primo carattere dell indirizzo codificato in base 58
Quote
L'hash di uno script è di 20 byte esattamente come l'hash di una chiave pubblica, ma ovviamente non sono la stessa cosa.
ok , e la verifica unlocking coem deve essere considerata?
Code:
ScriptSig: 0[] PUSHDATA(72)[3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001]
PUSHDATA(69[5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae]
PUSHDATA(69[5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae]
Gli scritpSig sono gli unlocking script, gli script di output sono invece i locking script. Tu hai scritto il contrario.
Ogni transazione sblocca momentaneamente dei btc (mediante firma e chiave pubblica per esempio) per rivincolarli immediatamente dopo con un altro "lucchetto" (tipo un address di destinazione)
La transazione 40eee... che stai guardando non è P2PKH ma P2PSH, si capisce dallo script di output (gli opt code sono diversi da quelli di un output verso un address) e infatti l'indirizzo di destinazione inizia con un 3 anzichè con il classico 1. L'hash di uno script è di 20 byte esattamente come l'hash di una chiave pubblica, ma ovviamente non sono la stessa cosa.
Ogni transazione sblocca momentaneamente dei btc (mediante firma e chiave pubblica per esempio) per rivincolarli immediatamente dopo con un altro "lucchetto" (tipo un address di destinazione)
La transazione 40eee... che stai guardando non è P2PKH ma P2PSH, si capisce dallo script di output (gli opt code sono diversi da quelli di un output verso un address) e infatti l'indirizzo di destinazione inizia con un 3 anzichè con il classico 1. L'hash di uno script è di 20 byte esattamente come l'hash di una chiave pubblica, ma ovviamente non sono la stessa cosa.
Ciao, in base a quanto scritto nell'ultimo esempio mi troverei questa situazione per la creazione della transazione la sintassi da considerare è
dove il primo, scriptSig è da considerarsi il locking script.
Mentre per la verifica
dove lo scriptPubKey è lo unlocking script.
Mentre una transazione di questo genere https://blockchain.info/tx/40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8
E' una transazione P2PKH infatti ritrovo nello scriptSing la firma e la chiave pubblica compressa e in output l hash 160 del destinatario....
Se continuo https://blockchain.info/tx/7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45
mi sarei aspettato visto il tipo di output della sezione precedente una script sign composto da firma e chiave compressa e invece trovo
Code:
scriptSig:
scriptPubKey:P_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
scriptPubKey:P_DUP OP_HASH160
dove il primo, scriptSig è da considerarsi il locking script.
Mentre per la verifica
Code:
scriptPubKey: OP_CHECKSIG
scriptSig:
scriptSig:
dove lo scriptPubKey è lo unlocking script.
Mentre una transazione di questo genere https://blockchain.info/tx/40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8
E' una transazione P2PKH infatti ritrovo nello scriptSing la firma e la chiave pubblica compressa e in output l hash 160 del destinatario....
Se continuo https://blockchain.info/tx/7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45
mi sarei aspettato visto il tipo di output della sezione precedente una script sign composto da firma e chiave compressa e invece trovo
Code:
ScriptSig: 0[] PUSHDATA(72)[3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001] PUSHDATA(69)[5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae]
Come lo devo interpretare?Ciao per essere sicuri che ho capito bene, se leggo
P2PKH
Oppure
P2PK
In entrambi i casi la parte relativa a scriptPubKey si riferisce ovviamente alla trx precedente?
Questo a livello di funzionamento di verifica della trx rispetto al ricevente cioè la rete
Mentre a livello di creazione della trx la parte con scriptPubKey viene creata con i dati del ricevente
Corretto?
P2PKH
Code:
scriptPubKey: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
scriptSig:
scriptSig:
Oppure
P2PK
Code:
scriptPubKey: OP_CHECKSIG
scriptSig:
scriptSig:
In entrambi i casi la parte relativa a scriptPubKey si riferisce ovviamente alla trx precedente?
Questo a livello di funzionamento di verifica della trx rispetto al ricevente cioè la rete
Mentre a livello di creazione della trx la parte con scriptPubKey viene creata con i dati del ricevente
Corretto?
Sì. I due script (quello di output della tx precedente e quello di input della tx attuale) sono due facce della stessa medaglia, il primo è il "locking" script, il secondo l'"unlocking" script. Ma appartengono sempre a 2 transazioni distinte.
Invece quando crei una transazione, il locking script della transazione potrebbe essere anche di una tipologia diversa rispetto all'unlocking script della stessa transazione.
Per esempio se vuoi spendere l'output non speso di una tx P2PK verso un'indirizzo standard, creando quindi una tx P2PKH, questa transazione avrà come
script di input (unlocking script):
Code:
scriptSig:
(poichè per svincolare i bitcoin vincolati dalla tx precedente con la condizione
e come script di output (locking script):
Code:
scriptPubKey: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
La tipologia di una transazione (P2PK, P2PKH, multisig, P2SH) si ricava dalla condizione che viene posta nello script di output che vincola i bitcoin.
Ciao per essere sicuri che ho capito bene, se leggo
P2PKH
Oppure
P2PK
In entrambi i casi la parte relativa a scriptPubKey si riferisce ovviamente alla trx precedente?
Questo a livello di funzionamento di verifica della trx rispetto al ricevente cioè la rete
Mentre a livello di creazione della trx la parte con scriptPubKey viene creata con i dati del ricevente
Corretto?
P2PKH
Code:
scriptPubKey: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
scriptSig:
scriptSig:
Oppure
P2PK
Code:
scriptPubKey: OP_CHECKSIG
scriptSig:
scriptSig:
In entrambi i casi la parte relativa a scriptPubKey si riferisce ovviamente alla trx precedente?
Questo a livello di funzionamento di verifica della trx rispetto al ricevente cioè la rete
Mentre a livello di creazione della trx la parte con scriptPubKey viene creata con i dati del ricevente
Corretto?
Si ora va, ho ripreso la chiave pubblica dalla transazione, se la prendo dal post non funziona, forse c'è qualche carattere sporco o errato non ho indagato molto.
Grazie mille
Grazie mille
Non va lo stesso
Io ho appena provato e funziona. Stai usando il sito che ti ho linkato?
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?
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 chiave pubblica è un punto di una curva ellittica, la sua forma è (X,Y), dove X e Y sono valori di 256 bit che soddisfano l'equazione Y^2 = x^3 + 7 modulo un certo numero primo p.
Per questo motivo, se conosco anche solo la X, posso derivare facilmente la Y dall'equazione. Più precisamente, per ogni valore di X ci sono 2 valori di Y possibili:
Link utili:
https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch04.asciidoc
https://bitcointalksearch.org/topic/curve-ellittiche-e-algoritmo-ecdsa-1339031
Perfetto
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?
Al 99% hai considerato la chiavee 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?
Quote
04bc3ee049bebf27e6e29403aeb61a1c48acee5d4c3b687252a99add1b7dbe38272e42882747493 f2d2e6c92e22dc46567491f3cd5a25259e269ac66649ef6d871
come una stringa di caratteri anzichè come una sequenza di byte rappresentati in formato esadecimale,
prova https://www.fileformat.info/tool/hash.htm usando "Binary Hash" anzichè "String Hash" e otterrai i valori corretti come in http://gobittest.appspot.com/Address
Non va lo stesso
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?
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 chiave pubblica è un punto di una curva ellittica, la sua forma è (X,Y), dove X e Y sono valori di 256 bit che soddisfano l'equazione Y^2 = x^3 + 7 modulo un certo numero primo p.
Per questo motivo, se conosco anche solo la X, posso derivare facilmente la Y dall'equazione. Più precisamente, per ogni valore di X ci sono 2 valori di Y possibili:
Link utili:
https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch04.asciidoc
https://bitcointalksearch.org/topic/curve-ellittiche-e-algoritmo-ecdsa-1339031
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?
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?
Al 99% hai considerato la chiave
Quote
04bc3ee049bebf27e6e29403aeb61a1c48acee5d4c3b687252a99add1b7dbe38272e42882747493 f2d2e6c92e22dc46567491f3cd5a25259e269ac66649ef6d871
come una stringa di caratteri anzichè come una sequenza di byte rappresentati in formato esadecimale,
prova https://www.fileformat.info/tool/hash.htm usando "Binary Hash" anzichè "String Hash" e otterrai i valori corretti come in http://gobittest.appspot.com/Address
Ciao, grazie perchè mi si sta ricomponendo il puzzle.
Ok chiaro
Perfetto
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?
Quote
La chiave pubblica nello script di ouput della transazione P2PK è di 65 byte (il byte 04 + 64 byte).
Ok chiaro
Quote
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
Quote
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?
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.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
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
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?
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)
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
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
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
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
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?
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"
}
]
}
"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"
},
{
"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://bitcointalksearch.org/topic/m.39156123 con una versione aggiornata dello schema di Satoshi
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?
"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
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
Quote
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
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?
"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).
Jump to: