Sostanzialmente ogni chiave privata (in formato esteso) corrisponde a due address distinti.
Chiave Privata Estesa
|
______________|_______________
| |
| |
WIF Compressa WIF non compressa
| |
| |
Address 1 Address 2
Le WIF (Wallet Import Format) compresse iniziano con K o L (introdotte da core 0.6), le WIF non compresse iniziano con 5.
Avendo anche solamente una dei tre formati della chiave privata (Estesa, WIF Compressa, WIF non compressa) è possibile risalire comunque a tutti e due gli address mediante questi passaggi:
https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
https://en.bitcoin.it/wiki/Wallet_import_format
Basta smazzarsi un po' ma avendone una delle 3 siete in una botte di ferro salvo catastrofi
Topic: wallet.dat compabitilità (Read 770 times)
Le curve ellittiche non c'entrano, il problema sta nella conversione delle coordinate di un punto della curva ellittica in un indirizzo bitcoin.
Tra chiavi private e chiavi pubbliche c'è una perfetta corrispondenza biunivoca (si tratta rispettivamente di scalari a 256 bit e di punti della curva ellittica P=(x,y) dove x e y sono numeri di 256 bit).
Per trasformare i 512 bit della chiave pubblica in una stringa di 160 bit che è l'indirizzo bitcoin, si deve fare l'hash256 delle due coordinate e poi ripmed160. Il problema nasce dal fatto che è possibile rappresentare un punto della curva ellittica usando anche solo la x e il segno di y (infatti se (x,y) è un punto della curva lo è anche (x,-y)), dal momento che il valore di y dipende solo dal valore di x --> y^2=x^3+7
Quindi poichè l'algoritmo hash produce 2 diversi risultati se gli diamo in input (x,y) o (x,+/-), si determina il problema che la stessa chiave privata, la quale determina dal punto di vista matematico un solo punto P della curva ellittica, produce in realtà due chiavi pubbliche P diverse (dal punto di vista dell'hash sono effettivamente diverse, poco importa che siano solo rappresentazioni diverse dello stesso oggetto matematico).
Quando importiamo una chiave privata nel nostro wallet, a quale delle "due" chiavi pubbliche si riferisce la chiave privata? E quindi quale indirizzo deve monitorare il wallet?
Per distinguere i due diversi casi, per quanto riguarda la chiave pubblica si usa la seguente convenzione:
"02" + 128 caratteri in formato esadecimale per la chiave pubblica standard (x,y) (8 + 512 bit)
"03" + 64 caratteri in formato esadecimale per la chiave pubblica compressa (x,pari) (8 + 256 bit)
("04" + 64 caratteri in formato esadecimale per la chiave pubblica compressa (x,dispari)) (8 + 256 bit)
Ma ricordo che la chiave privata è unica, quindi bisogna aggiungere delle informazioni quando si presenta la chiave privata al wallet (che per questo è o in formato WIF o in formato WIF compresso). In questo formato, dove si passa dalla rappresentazione binaria o esadecimale a quella base58, viene aggiunta (come dice il nome) anche quell'informazione che consente al wallet di sapere che tipo di chiave pubblica e quindi di indirizzo deve ricavare da quella chiave.
A complicare ulteriormente le cose, l'informazione che si aggiunge alla chiave privata per dire che da essa si deve ricavare la chiave pubblica compressa rende la chiave privata in formato WIF compresso più lunga rispetto alla chiave privata in formato WIF, ciononostante si chiama ancora "chiave privata compressa" poichè da essa si deve ricavare la chiave pubblica nella sua rappresentazione compressa.
Tra chiavi private e chiavi pubbliche c'è una perfetta corrispondenza biunivoca (si tratta rispettivamente di scalari a 256 bit e di punti della curva ellittica P=(x,y) dove x e y sono numeri di 256 bit).
Per trasformare i 512 bit della chiave pubblica in una stringa di 160 bit che è l'indirizzo bitcoin, si deve fare l'hash256 delle due coordinate e poi ripmed160. Il problema nasce dal fatto che è possibile rappresentare un punto della curva ellittica usando anche solo la x e il segno di y (infatti se (x,y) è un punto della curva lo è anche (x,-y)), dal momento che il valore di y dipende solo dal valore di x --> y^2=x^3+7
Quindi poichè l'algoritmo hash produce 2 diversi risultati se gli diamo in input (x,y) o (x,+/-), si determina il problema che la stessa chiave privata, la quale determina dal punto di vista matematico un solo punto P della curva ellittica, produce in realtà due chiavi pubbliche P diverse (dal punto di vista dell'hash sono effettivamente diverse, poco importa che siano solo rappresentazioni diverse dello stesso oggetto matematico).
Quando importiamo una chiave privata nel nostro wallet, a quale delle "due" chiavi pubbliche si riferisce la chiave privata? E quindi quale indirizzo deve monitorare il wallet?
Per distinguere i due diversi casi, per quanto riguarda la chiave pubblica si usa la seguente convenzione:
"02" + 128 caratteri in formato esadecimale per la chiave pubblica standard (x,y) (8 + 512 bit)
"03" + 64 caratteri in formato esadecimale per la chiave pubblica compressa (x,pari) (8 + 256 bit)
("04" + 64 caratteri in formato esadecimale per la chiave pubblica compressa (x,dispari)) (8 + 256 bit)
Ma ricordo che la chiave privata è unica, quindi bisogna aggiungere delle informazioni quando si presenta la chiave privata al wallet (che per questo è o in formato WIF o in formato WIF compresso). In questo formato, dove si passa dalla rappresentazione binaria o esadecimale a quella base58, viene aggiunta (come dice il nome) anche quell'informazione che consente al wallet di sapere che tipo di chiave pubblica e quindi di indirizzo deve ricavare da quella chiave.
A complicare ulteriormente le cose, l'informazione che si aggiunge alla chiave privata per dire che da essa si deve ricavare la chiave pubblica compressa rende la chiave privata in formato WIF compresso più lunga rispetto alla chiave privata in formato WIF, ciononostante si chiama ancora "chiave privata compressa" poichè da essa si deve ricavare la chiave pubblica nella sua rappresentazione compressa.
Condivido. Alla fine quali sono le cose pratiche importanti? Secondo me gli aspetti importanti sono che la chiave privata inizia per 5 o in un altro caso inizia per "a", "K" o "L" e che questi due tipi di chiavi si possono tradurre in un tipo o nell'altro con un programmino off line come https://www.bitaddress.org
Se il client non accetta il tipo di chiave privata che abbiamo noi allora la possiamo trasformare nell'altro tipo in modo molto semplice e siamo a posto.
Per i più curiosi come me la teoria che hai esposto è molto chiara.
Non ho letto tutto il 3ad ma mi pare di capire che il problema è nei due formati della private key, c'è il formato che inizia con a o K o L e quello che inizia per 5 e poi c'è il problema dei due indirizzi bitcoin differenti perché le due private key (che è una sola) danno due bitcoin address.
Questo è un problema dell'algoritmo ellittico e non di multibit o di altro, comunque si possono fare le conversioni e questo non dipende dal programma usato, sono specifiche matematiche che non si perdono col tempo.
Per esempio il classico https://www.bitaddress.org permette di generare una private key (5JfkD6nME2HJ9mxpEmqQNMYvBQ7qw2CmEaeiLt9nv12uAEf4jfA) e cliccando su Wallet details e inserendo la predetta chiave privata fornisce i dati voluti ovvero:
1L8udQVzcu9ninYLunZ9bowMyTA8NvMLFA (indirizzo bitcoin)
19N68NbupPn2HngfVzFD7QY2cVvhQJ75w (indirizzo bitcoin compresso)
e ovviamente c'è anche la chiave privata corrispondente a 5... ovvero quella compressa (Kzz1iQXAGUevhjTMVnte9Fhsiu3CySJvEwXTUkmoew9PDbSwqs3f) che inizia per K o L.
Si noti che la PrivK è sempre la stessa ovvero 32 Byte di dati solo che è aggiunta l'informazione relativa alla compressione o meno della corrispondente PubK: se si vuole l'indirizzo esteso allora si fa in modo che la PrivK inizi per 5, se si vuole l'indirizzo bitcoin compresso si fa in modo che inizi per a o K o L.
Comunque quando uno importa la PrivK sul core può vedere se gli va bene:
Chiave privata WIF
51 caratteri base58, inizia per a '5'
oppure:
Chiave privata WIF compressa
52 caratteri base58, inizia per 'a' 'K' o 'L'
In realtà la chiave privata è sempre la stessa ed è lunga 32 byte, a questa corrispondono due indirizzi bitcoin.
Qui le info che ho solo letto perché non so molto:
https://bitcointalksearch.org/topic/compressed-vs-uncompresed-private-keys-129652
Questo è un problema dell'algoritmo ellittico e non di multibit o di altro, comunque si possono fare le conversioni e questo non dipende dal programma usato, sono specifiche matematiche che non si perdono col tempo.
Per esempio il classico https://www.bitaddress.org permette di generare una private key (5JfkD6nME2HJ9mxpEmqQNMYvBQ7qw2CmEaeiLt9nv12uAEf4jfA) e cliccando su Wallet details e inserendo la predetta chiave privata fornisce i dati voluti ovvero:
1L8udQVzcu9ninYLunZ9bowMyTA8NvMLFA (indirizzo bitcoin)
19N68NbupPn2HngfVzFD7QY2cVvhQJ75w (indirizzo bitcoin compresso)
e ovviamente c'è anche la chiave privata corrispondente a 5... ovvero quella compressa (Kzz1iQXAGUevhjTMVnte9Fhsiu3CySJvEwXTUkmoew9PDbSwqs3f) che inizia per K o L.
Si noti che la PrivK è sempre la stessa ovvero 32 Byte di dati solo che è aggiunta l'informazione relativa alla compressione o meno della corrispondente PubK: se si vuole l'indirizzo esteso allora si fa in modo che la PrivK inizi per 5, se si vuole l'indirizzo bitcoin compresso si fa in modo che inizi per a o K o L.
Comunque quando uno importa la PrivK sul core può vedere se gli va bene:
Chiave privata WIF
51 caratteri base58, inizia per a '5'
oppure:
Chiave privata WIF compressa
52 caratteri base58, inizia per 'a' 'K' o 'L'
In realtà la chiave privata è sempre la stessa ed è lunga 32 byte, a questa corrispondono due indirizzi bitcoin.
Qui le info che ho solo letto perché non so molto:
https://bitcointalksearch.org/topic/compressed-vs-uncompresed-private-keys-129652
Le curve ellittiche non c'entrano, il problema sta nella conversione delle coordinate di un punto della curva ellittica in un indirizzo bitcoin.
Tra chiavi private e chiavi pubbliche c'è una perfetta corrispondenza biunivoca (si tratta rispettivamente di scalari a 256 bit e di punti della curva ellittica P=(x,y) dove x e y sono numeri di 256 bit).
Per trasformare i 512 bit della chiave pubblica in una stringa di 160 bit che è l'indirizzo bitcoin, si deve fare l'hash256 delle due coordinate e poi ripmed160. Il problema nasce dal fatto che è possibile rappresentare un punto della curva ellittica usando anche solo la x e il segno di y (infatti se (x,y) è un punto della curva lo è anche (x,-y)), dal momento che il valore di y dipende solo dal valore di x --> y^2=x^3+7
Quindi poichè l'algoritmo hash produce 2 diversi risultati se gli diamo in input (x,y) o (x,+/-), si determina il problema che la stessa chiave privata, la quale determina dal punto di vista matematico un solo punto P della curva ellittica, produce in realtà due chiavi pubbliche P diverse (dal punto di vista dell'hash sono effettivamente diverse, poco importa che siano solo rappresentazioni diverse dello stesso oggetto matematico).
Quando importiamo una chiave privata nel nostro wallet, a quale delle "due" chiavi pubbliche si riferisce la chiave privata? E quindi quale indirizzo deve monitorare il wallet?
Per distinguere i due diversi casi, per quanto riguarda la chiave pubblica si usa la seguente convenzione:
"02" + 128 caratteri in formato esadecimale per la chiave pubblica standard (x,y) (8 + 512 bit)
"03" + 64 caratteri in formato esadecimale per la chiave pubblica compressa (x,pari) (8 + 256 bit)
("04" + 64 caratteri in formato esadecimale per la chiave pubblica compressa (x,dispari)) (8 + 256 bit)
Ma ricordo che la chiave privata è unica, quindi bisogna aggiungere delle informazioni quando si presenta la chiave privata al wallet (che per questo è o in formato WIF o in formato WIF compresso). In questo formato, dove si passa dalla rappresentazione binaria o esadecimale a quella base58, viene aggiunta (come dice il nome) anche quell'informazione che consente al wallet di sapere che tipo di chiave pubblica e quindi di indirizzo deve ricavare da quella chiave.
A complicare ulteriormente le cose, l'informazione che si aggiunge alla chiave privata per dire che da essa si deve ricavare la chiave pubblica compressa rende la chiave privata in formato WIF compresso più lunga rispetto alla chiave privata in formato WIF, ciononostante si chiama ancora "chiave privata compressa" poichè da essa si deve ricavare la chiave pubblica nella sua rappresentazione compressa.
Non uso bitcoincore, ma per esempio con multibit, che cmq fa salvare il wallet.dat , preferisco non correre rischi ed esporto anche la private key col file wallet.key , così al max se il .dat non è compatibile, posso importare la private key ovunque. Bitcoincore esporta le priv key degli indirizzi ?
Sottoscrivo. La cosa migliore è una bella stampa in chiaro delle chiavi private dove si hanno i soldi e mettere il foglio in cassaforte o in una cassetta bancaria, in tal modo non ci sono problemi: i CD-rom si estinguono, le chiavette cambiano, i floppy non ci sono più e nemmeno le VHS, meglio premunirsi. I fogli di carta sono un supporto standard da migliaia di anni.
Il formato delle chiavi private e delle chiavi pubbliche (l'algoritmo ellittico?) è l'unica cosa su cui fare affidamento.
Multibit poi è utilissimo in quanto usa sempre i medesimi indirizzi per fare tutto, se non si hanno problemi di privacy permette di avere sempre in un paio di indirizzi tutto il proprio contante.
ok grazie a tutti per le risposte .
purtroppo non tutti hanno una casa forte
poi non so quanto siano sicure le cassette bancarie . comunque provedo subito a salvare le chiavi private . cosi sono più sereno .
speriamo che tra 20 anni il BTC salga a 20.000 almeno e soprattuto che aumentino i servizi e beni pagabili con BTC .
Non ho letto tutto il 3ad ma mi pare di capire che il problema è nei due formati della private key, c'è il formato che inizia con a o K o L e quello che inizia per 5 e poi c'è il problema dei due indirizzi bitcoin differenti perché le due private key (che è una sola) danno due bitcoin address.
Questo è un problema dell'algoritmo ellittico e non di multibit o di altro, comunque si possono fare le conversioni e questo non dipende dal programma usato, sono specifiche matematiche che non si perdono col tempo.
Per esempio il classico https://www.bitaddress.org permette di generare una private key (5JfkD6nME2HJ9mxpEmqQNMYvBQ7qw2CmEaeiLt9nv12uAEf4jfA) e cliccando su Wallet details e inserendo la predetta chiave privata fornisce i dati voluti ovvero:
1L8udQVzcu9ninYLunZ9bowMyTA8NvMLFA (indirizzo bitcoin)
19N68NbupPn2HngfVzFD7QY2cVvhQJ75w (indirizzo bitcoin compresso)
e ovviamente c'è anche la chiave privata corrispondente a 5... ovvero quella compressa (Kzz1iQXAGUevhjTMVnte9Fhsiu3CySJvEwXTUkmoew9PDbSwqs3f) che inizia per K o L.
Si noti che la PrivK è sempre la stessa ovvero 32 Byte di dati solo che è aggiunta l'informazione relativa alla compressione o meno della corrispondente PubK: se si vuole l'indirizzo esteso allora si fa in modo che la PrivK inizi per 5, se si vuole l'indirizzo bitcoin compresso si fa in modo che inizi per a o K o L.
Comunque quando uno importa la PrivK sul core può vedere se gli va bene:
Chiave privata WIF
51 caratteri base58, inizia per a '5'
oppure:
Chiave privata WIF compressa
52 caratteri base58, inizia per 'a' 'K' o 'L'
In realtà la chiave privata è sempre la stessa ed è lunga 32 byte, a questa corrispondono due indirizzi bitcoin.
Qui le info che ho solo letto perché non so molto:
https://bitcointalksearch.org/topic/compressed-vs-uncompresed-private-keys-129652
Si può scaricare in locale:
https://www.bitaddress.org/
Questo è un problema dell'algoritmo ellittico e non di multibit o di altro, comunque si possono fare le conversioni e questo non dipende dal programma usato, sono specifiche matematiche che non si perdono col tempo.
Per esempio il classico https://www.bitaddress.org permette di generare una private key (5JfkD6nME2HJ9mxpEmqQNMYvBQ7qw2CmEaeiLt9nv12uAEf4jfA) e cliccando su Wallet details e inserendo la predetta chiave privata fornisce i dati voluti ovvero:
1L8udQVzcu9ninYLunZ9bowMyTA8NvMLFA (indirizzo bitcoin)
19N68NbupPn2HngfVzFD7QY2cVvhQJ75w (indirizzo bitcoin compresso)
e ovviamente c'è anche la chiave privata corrispondente a 5... ovvero quella compressa (Kzz1iQXAGUevhjTMVnte9Fhsiu3CySJvEwXTUkmoew9PDbSwqs3f) che inizia per K o L.
Si noti che la PrivK è sempre la stessa ovvero 32 Byte di dati solo che è aggiunta l'informazione relativa alla compressione o meno della corrispondente PubK: se si vuole l'indirizzo esteso allora si fa in modo che la PrivK inizi per 5, se si vuole l'indirizzo bitcoin compresso si fa in modo che inizi per a o K o L.
Comunque quando uno importa la PrivK sul core può vedere se gli va bene:
Chiave privata WIF
51 caratteri base58, inizia per a '5'
oppure:
Chiave privata WIF compressa
52 caratteri base58, inizia per 'a' 'K' o 'L'
In realtà la chiave privata è sempre la stessa ed è lunga 32 byte, a questa corrispondono due indirizzi bitcoin.
Qui le info che ho solo letto perché non so molto:
https://bitcointalksearch.org/topic/compressed-vs-uncompresed-private-keys-129652
Si può scaricare in locale:
https://www.bitaddress.org/
Occhio anche all'export delle chiavi private.
Riesumo un topic aperto da me tempo fa
https://bitcointalksearch.org/topic/error-import-multibit-private-key-680355
Ora io stavo facendo prove, immaginatevi avere quel problema con un wallet pieno di BTC, ti viene un colpo..........poi la soluzione la trovi..........
Riesumo un topic aperto da me tempo fa
https://bitcointalksearch.org/topic/error-import-multibit-private-key-680355
Ora io stavo facendo prove, immaginatevi avere quel problema con un wallet pieno di BTC, ti viene un colpo..........poi la soluzione la trovi..........
Non uso bitcoincore, ma per esempio con multibit, che cmq fa salvare il wallet.dat , preferisco non correre rischi ed esporto anche la private key col file wallet.key , così al max se il .dat non è compatibile, posso importare la private key ovunque. Bitcoincore esporta le priv key degli indirizzi ?
Sottoscrivo. La cosa migliore è una bella stampa in chiaro delle chiavi private dove si hanno i soldi e mettere il foglio in cassaforte o in una cassetta bancaria, in tal modo non ci sono problemi: i CD-rom si estinguono, le chiavette cambiano, i floppy non ci sono più e nemmeno le VHS, meglio premunirsi. I fogli di carta sono un supporto standard da migliaia di anni.
Il formato delle chiavi private e delle chiavi pubbliche (l'algoritmo ellittico?) è l'unica cosa su cui fare affidamento.
Multibit poi è utilissimo in quanto usa sempre i medesimi indirizzi per fare tutto, se non si hanno problemi di privacy permette di avere sempre in un paio di indirizzi tutto il proprio contante.
Non uso bitcoincore, ma per esempio con multibit, che cmq fa salvare il wallet.dat , preferisco non correre rischi ed esporto anche la private key col file wallet.key , così al max se il .dat non è compatibile, posso importare la private key ovunque. Bitcoincore esporta le priv key degli indirizzi ?
La sicurezza non c'è, ma la probabilità è alta. (che rimanga compatibile)
Se non fosse cosi si perderebbe fiducia verso la moneta.
Ci potrebbero essere due casi estremi:
- Cambia il formato, e quindi verrà rilasciato un probabile tool per la conversione.
- Ci sarà un superbug e/o impreviso, e quindi chi rimarrà nel vecchio formato rimarrà a rischio di quanto peggio
Se non fosse cosi si perderebbe fiducia verso la moneta.
Ci potrebbero essere due casi estremi:
- Cambia il formato, e quindi verrà rilasciato un probabile tool per la conversione.
- Ci sarà un superbug e/o impreviso, e quindi chi rimarrà nel vecchio formato rimarrà a rischio di quanto peggio
salve ho un wallet.dat che ho salvato circa 3 anni fa su una chiavetta USB . volevo chiedere se questo wallet.dat sarà compatibile con le nuove versioni di bitcoin-core che ci saranno tra 5 10 anni ?
Jump to: