Topic: [LIBRO COMPLETO GRATUITO] Bitcoin per tutti - page 4. (Read 19131 times)
Volevo segnalare che sabato ho completato ed aggiunto il primo capitolo sui Fork.
Ho applicato la tua versione su github.
Ho anche aggiunto questo paragrafo sulla sicurezza nel capitolo Sicurezza e Privacy:
Permettere a chiunque di ricollegare la vostra identità ai vostri Bitcoin, potrebbe esporvi a rischi personali, soprattutto se la quantità in vostro possesso fosse considerevole. Se qualche malintenzionato venisse a conoscenza che sul vostro address fossero presenti una decina di Bitcoin, potrebbero esserci dei risvolti poco piacevoli. Sbandierare di possedere dieci Bitcoin, potrebbe non essere quindi una buona idea, soprattuto vista l'alta portabilità di questo tipo di valuta, possiamo equipararla all'oro o ai contanti. Nessuno va in giro a dire che a casa ha un kilo d'oro o una 24 ore piena di contanti. L'aspetto della privacy e della sicurezza sono quindi molto legati tra loro, più di quanto si possa immaginare.
Ho anche aggiunto questo paragrafo sulla sicurezza nel capitolo Sicurezza e Privacy:
Permettere a chiunque di ricollegare la vostra identità ai vostri Bitcoin, potrebbe esporvi a rischi personali, soprattutto se la quantità in vostro possesso fosse considerevole. Se qualche malintenzionato venisse a conoscenza che sul vostro address fossero presenti una decina di Bitcoin, potrebbero esserci dei risvolti poco piacevoli. Sbandierare di possedere dieci Bitcoin, potrebbe non essere quindi una buona idea, soprattuto vista l'alta portabilità di questo tipo di valuta, possiamo equipararla all'oro o ai contanti. Nessuno va in giro a dire che a casa ha un kilo d'oro o una 24 ore piena di contanti. L'aspetto della privacy e della sicurezza sono quindi molto legati tra loro, più di quanto si possa immaginare.
Il mio unico dubbio è che non vorrei instaurare dubbi infondati sulla sicurezza del sistema, viceversa va comunque data una informazione corretta, il più semplificata possibile (visto gli intenti del libro).
Al di là del concetto delle chiavi in formato compresso, che tralascierei, possiamo "semplificare" la questione aggiungendo la parte in grassetto:
Più di una volta mi è stato sollevata la domanda: "Cosa succede se qualcuno genera le mie stesse 12 parole? Può accedere ai miei Bitcoin?" La risposta è SI, ma è altamente improbabile praticamente impossibile. La quantità di chiavi private generabili è di (2^256) si avvicina al numero di atomi presenti nell’universo conosciuto (stimato all’incirca in un numero che va da 2^240 e 2^280), sicuramente è più semplice per due persone trovare lo stesso granello di sabbia sul pianeta terra (che in base ad una stima molto approssimativa risulta essere 2^63), rispetto a trovare una chiave privata già utilizzata da qualcun altro.
In realtà, a causa del formato più piccolo utilizzato dall'address bitcoin (160 bit rispetto ai 256 bit delle chiavi private), più chiavi private possono accedere ai Bitcoin depositati sul medesimo address. Il numero di queste chiavi è di circa 2^96! A prima vista, un numero così grande potrebbe spaventare, significa infatti che esistono moltissime chiavi private che possono accedere ai miei Bitcoin. Il punto è che, nonostante siano tantissime, si perdono all'interno delle 2^256 esistenti. In particolare si stima che, tramite un attacco di tipo brute force, cioè un sistema automatico che prova tutte le possibili soluzioni ad un determinato problema, si riesca a trovare una chiave privata in grado di sbloccare un determinato address una volta ogni 2^160 tentativi, che sono comunque un numero considerevole per il livello tecnologico attuale. Per completezza di informazione, va inoltre detto che se dal nostro address abbiamo effettuato un trasferimento verso un altro address, abbiamo esposto a terzi la nostra chiave pubblica. Questa ulteriore informazione "facilita" l'attività di chi volesse cercare di accedere ai nostri Bitcoin, riducendo di fatto i numeri di tentativi medi per riuscire a sbloccare i fondi a 2^128.
Da un punto di vista della sicurezza del sistema, è corretto dire che servono quindi mediamente 2^128 tentativi per riuscire a rubare i Bitcoin depositati su un determinato address, sempre considerando il fatto che nel frattempo non siano stati spesi o spostati su altro address.
Per approfondire l'argomento, trovate ulteriori informazioni qui: https://bitcointalksearch.org/topic/curve-ellittiche-e-algoritmo-ecdsa-1339031
Per chi avesse poca dimestichezza con gli elementi potenza, in questo caso parliamo di un raddoppio ogni unità espressa nell’elevamento.
...
2^128 = 340.282.366.920.938.000.000.000.000.000.000.000.000
....
2^160 = 1.461.501.637.330.900.000.000.000.000.000.000.000.000.000.000.000
Ditemi cosa ne pensate, se lo ritenete corretto, aggiungo la parte in grassetto.
Grazie per l'aiuto ragazzi.
Al di là del concetto delle chiavi in formato compresso, che tralascierei, possiamo "semplificare" la questione aggiungendo la parte in grassetto:
Quote
Più di una volta mi è stato sollevata la domanda: "Cosa succede se qualcuno genera le mie stesse 12 parole? Può accedere ai miei Bitcoin?" La risposta è SI, ma è altamente improbabile praticamente impossibile. La quantità di chiavi private generabili è di (2^256) si avvicina al numero di atomi presenti nell’universo conosciuto (stimato all’incirca in un numero che va da 2^240 e 2^280), sicuramente è più semplice per due persone trovare lo stesso granello di sabbia sul pianeta terra (che in base ad una stima molto approssimativa risulta essere 2^63), rispetto a trovare una chiave privata già utilizzata da qualcun altro.
In realtà, a causa del formato più piccolo utilizzato dall'address bitcoin (160 bit rispetto ai 256 bit delle chiavi private), più chiavi private possono accedere ai Bitcoin depositati sul medesimo address. Il numero di queste chiavi è di circa 2^96! A prima vista, un numero così grande potrebbe spaventare, significa infatti che esistono moltissime chiavi private che possono accedere ai miei Bitcoin. Il punto è che, nonostante siano tantissime, si perdono all'interno delle 2^256 esistenti. In particolare si stima che, tramite un attacco di tipo brute force, cioè un sistema automatico che prova tutte le possibili soluzioni ad un determinato problema, si riesca a trovare una chiave privata in grado di sbloccare un determinato address una volta ogni 2^160 tentativi, che sono comunque un numero considerevole per il livello tecnologico attuale. Per completezza di informazione, va inoltre detto che se dal nostro address abbiamo effettuato un trasferimento verso un altro address, abbiamo esposto a terzi la nostra chiave pubblica. Questa ulteriore informazione "facilita" l'attività di chi volesse cercare di accedere ai nostri Bitcoin, riducendo di fatto i numeri di tentativi medi per riuscire a sbloccare i fondi a 2^128.
Da un punto di vista della sicurezza del sistema, è corretto dire che servono quindi mediamente 2^128 tentativi per riuscire a rubare i Bitcoin depositati su un determinato address, sempre considerando il fatto che nel frattempo non siano stati spesi o spostati su altro address.
Per approfondire l'argomento, trovate ulteriori informazioni qui: https://bitcointalksearch.org/topic/curve-ellittiche-e-algoritmo-ecdsa-1339031
Per chi avesse poca dimestichezza con gli elementi potenza, in questo caso parliamo di un raddoppio ogni unità espressa nell’elevamento.
...
2^128 = 340.282.366.920.938.000.000.000.000.000.000.000.000
....
2^160 = 1.461.501.637.330.900.000.000.000.000.000.000.000.000.000.000.000
Ditemi cosa ne pensate, se lo ritenete corretto, aggiungo la parte in grassetto.
Grazie per l'aiuto ragazzi.
Per me la modifica proposta va benissimo, specificare di più rischierebbe di complicare inutilmente la comprensione, neanche in Mastering Bitcoin c'è stata una tale attenzione e precisione su questo punto
Al massimo farei questa leggera modifica alla tua modifica:
Quote
Per completezza di informazione, va inoltre detto che quando effettuiamo un trasferimento da un nostro address verso un altro address, esponiamo a terzi la chiave pubblica relativa al nostro address.
Questa ulteriore informazione "facilita" l'attività di chi volesse cercare di accedere ai Bitcoin rimasti nel nostro address, riducendo di fatto il numero di tentativi medi per riuscire a sbloccare i fondi a 2^128. Anche per questo (oltre che per una questione di maggiore privacy) si consiglia di utilizzare un address una sola volta (si consiglia cioè di svuotarlo completamente la prima volta che si devono utilizzare anche solo una parte dei suoi fondi).
Da un punto di vista della sicurezza del sistema, è corretto dire che servono quindi mediamente:
2^160 tentativi per riuscire a rubare i Bitcoin depositati su un address dal quale non è mai stato effettuato un prelievo
2^128 tentativi per riuscire a rubare i Bitcoin depositati su un address dal quale è stata effettuata almeno una transazione di spesa
Questa ulteriore informazione "facilita" l'attività di chi volesse cercare di accedere ai Bitcoin rimasti nel nostro address, riducendo di fatto il numero di tentativi medi per riuscire a sbloccare i fondi a 2^128. Anche per questo (oltre che per una questione di maggiore privacy) si consiglia di utilizzare un address una sola volta (si consiglia cioè di svuotarlo completamente la prima volta che si devono utilizzare anche solo una parte dei suoi fondi).
Da un punto di vista della sicurezza del sistema, è corretto dire che servono quindi mediamente:
2^160 tentativi per riuscire a rubare i Bitcoin depositati su un address dal quale non è mai stato effettuato un prelievo
2^128 tentativi per riuscire a rubare i Bitcoin depositati su un address dal quale è stata effettuata almeno una transazione di spesa
In realtà, a causa del formato più piccolo utilizzato dall'address bitcoin (160 bit rispetto ai 256 bit delle chiavi private), più chiavi private possono accedere ai Bitcoin depositati sul medesimo address. Il numero di queste chiavi è di circa 2^96! A prima vista, un numero così grande potrebbe spaventare, significa infatti che esistono moltissime chiavi private che possono accedere ai miei Bitcoin. Il punto è che, nonostante siano tantissime, si perdono all'interno delle 2^256 esistenti. In particolare si stima che, tramite un attacco di tipo brute force, cioè un sistema automatico che prova tutte le possibili soluzioni ad un determinato problema, si riesca a trovare una chiave privata in grado di sbloccare un determinato address una volta ogni 2^160 tentativi, che sono comunque un numero considerevole per il livello tecnologico attuale. Per completezza di informazione, va inoltre detto che se dal nostro address abbiamo effettuato un trasferimento verso un altro address, abbiamo esposto a terzi la nostra chiave pubblica. Questa ulteriore informazione "facilita" l'attività di chi volesse cercare di accedere ai nostri Bitcoin, riducendo di fatto i numeri di tentativi medi per riuscire a sbloccare i fondi a 2^128.
La parte quotata è sostanzialmente corretta.
Se vuoi essere ancora più chiaro puoi spiegare i due casi di opportunità di attacco da parte di un ipotetico hacker:
a) se un Bitcoin address non è mai stato usato per inviare fondi (ha quindi solo ricevuto bitcoin e non ne ha mai spesi) allora la chiave pubblica non è mai stata esposta.
In questo caso l'hacker è costretto ad attaccare il Bitcoin address con un numero di tentativi pari mediamente a 2^160 chiavi private (Hex).
b) se un Bitcoin address è stato usato anche solo una volta per inviare fondi allora la chiave pubblica è stata esposta.
In questo caso l'hacker, pur potendo attaccare il Bitcoin address come nel caso precedente, ha maggior convenienza ad attaccarne la sua chiave pubblica (usando il metodo Pollard's rho), con un numero di tentativi pari mediamente a 2^128 chiavi private (Hex).
Volendo essere pignoli ci sono attacchi Pollard's rho leggermente più raffinati che riescono ad abbassare il numero di tentativi a 2^127.8 (https://safecurves.cr.yp.to/rho.html), ma sostanzialmente stiamo sempre attorno a 2^128, che è un numero ENORME sotto il quale nessun attacco a forza bruta riesce ad andare.
L'algebra sottostante le curve ellittiche (nella fattispecie la curva secp256k1 usata dal Bitcoin) è talmente peculiare ed elegante da non prevedere il concetto di "moltiplicazione tra due punti" o "reciproco di un punto" rendendo impossibile (se non con la forza bruta) estrarre k (la chiave privata) dalla formula P = k * G pur conoscendo i punti P (public key) e G (punto generatore).
Ho fatto un veloce controllo sul numero delle chiavi private che possono essere generate, ed ho trovato più fonti che confermano il fatto che le chiavi private generabili sono tecnicamente 2^256 (^257 non l'ho trovato da nessuna parte me lo puoi spiegare nel dettaglio? hai qualche fonte?).
L'equivoco nasce da cosa si intenda per 'chiave privata'.
Questa per esempio è una chiave privata in formato Hex (64 Hex chars):
A2242EAD55C94C3DEB7CF2340BFEF9D5BCACA22DFE66E646745EE4371C633FC8
Essa corrisponde allo scalare k che deve essere moltiplicato per il punto G allo scopo di ottenere il punto P sulla curva ellittica (P = k * G).
Il numero massimo di chiavi private in formato Hex che è possibile generare è poco meno di 2^256 (il numero esatto di chiavi private possibili è pari al numero di punti che costituiscono la curva ellittica secp256k1).
L'equivoco nasce nel momento in cui converti la chiave privata in formato WIF (Wallet Import Format) in quanto esistono 2 diversi formati (WIF e WIF compresso) che danno origine a 2 chiavi private diverse:
Questa è la chiave privata scritta sopra, codificata in formato WIF:
5K3hGHXx9qzEKZLh6zKS5umqDGfuc8KUbWtXZ9S2ngDo81AMoxh
Questa è la stessa chiave codificata in formato WIF compresso:
L2etiTycS3Dbnujv1RzMifvsoAAjC3JYoLvRrtDUtc7UZo76CUb2
Per ogni chiave privata in formato Hex esistono quindi due possibili codifiche in formato WIF (compressa e non compressa) per cui il numero totali di chiavi private in formato WIF raddoppia e diventa poco meno di 2^257 (2^256 * 2).
In breve, se ti riferisci al numero di chiavi possibili in formato Hex la risposta è "poco meno di 2^256", se ti riferisci al numero di chiavi possibili in formato WIF (compresse + non compresse) allora risposta è "poco meno di 2^257".
A mio avviso se il contesto del discorso ruota attorno al tema della sicurezza allora è più corretto riferirsi al numero di chiavi private in formato Hex (2^256) in quanto per assurdo potremmo avere 10 formati WIF diversi (che produrrebbero altrettanti diversi Bitcoin address) ma il livello di sicurezza rimarrebbe il medesimo (poco meno di 2^160 chiavi Hex da attaccare con la più evoluta variante dell'algoritmo Pollard's rho).
P.S.: se ti fosse sfuggito ti suggerisco di studiarti con attenzione il pregevole tutorial sulle curve ellittiche postato da arulbero l'anno scorso: https://bitcointalksearch.org/topic/curve-ellittiche-e-algoritmo-ecdsa-1339031
Perfetto. Concordo.
Chiarissimo il discorso del 257.
Ottimo il link al post di arulbero, che a questo punto linkerei per chi vuole approfondire l'argomento relativo alla curva ellittica.
Il mio unico dubbio è che non vorrei instaurare dubbi infondati sulla sicurezza del sistema, viceversa va comunque data una informazione corretta, il più semplificata possibile (visto gli intenti del libro).
Al di là del concetto delle chiavi in formato compresso, che tralascierei, possiamo "semplificare" la questione aggiungendo la parte in grassetto:
Quote
Più di una volta mi è stato sollevata la domanda: "Cosa succede se qualcuno genera le mie stesse 12 parole? Può accedere ai miei Bitcoin?" La risposta è SI, ma è altamente improbabile praticamente impossibile. La quantità di chiavi private generabili è di (2^256) si avvicina al numero di atomi presenti nell’universo conosciuto (stimato all’incirca in un numero che va da 2^240 e 2^280), sicuramente è più semplice per due persone trovare lo stesso granello di sabbia sul pianeta terra (che in base ad una stima molto approssimativa risulta essere 2^63), rispetto a trovare una chiave privata già utilizzata da qualcun altro.
In realtà, a causa del formato più piccolo utilizzato dall'address bitcoin (160 bit rispetto ai 256 bit delle chiavi private), più chiavi private possono accedere ai Bitcoin depositati sul medesimo address. Il numero di queste chiavi è di circa 2^96! A prima vista, un numero così grande potrebbe spaventare, significa infatti che esistono moltissime chiavi private che possono accedere ai miei Bitcoin. Il punto è che, nonostante siano tantissime, si perdono all'interno delle 2^256 esistenti. In particolare si stima che, tramite un attacco di tipo brute force, cioè un sistema automatico che prova tutte le possibili soluzioni ad un determinato problema, si riesca a trovare una chiave privata in grado di sbloccare un determinato address una volta ogni 2^160 tentativi, che sono comunque un numero considerevole per il livello tecnologico attuale. Per completezza di informazione, va inoltre detto che se dal nostro address abbiamo effettuato un trasferimento verso un altro address, abbiamo esposto a terzi la nostra chiave pubblica. Questa ulteriore informazione "facilita" l'attività di chi volesse cercare di accedere ai nostri Bitcoin, riducendo di fatto i numeri di tentativi medi per riuscire a sbloccare i fondi a 2^128.
Da un punto di vista della sicurezza del sistema, è corretto dire che servono quindi mediamente 2^128 tentativi per riuscire a rubare i Bitcoin depositati su un determinato address, sempre considerando il fatto che nel frattempo non siano stati spesi o spostati su altro address.
Per approfondire l'argomento, trovate ulteriori informazioni qui: https://bitcointalksearch.org/topic/curve-ellittiche-e-algoritmo-ecdsa-1339031
Per chi avesse poca dimestichezza con gli elementi potenza, in questo caso parliamo di un raddoppio ogni unità espressa nell’elevamento.
...
2^128 = 340.282.366.920.938.000.000.000.000.000.000.000.000
....
2^160 = 1.461.501.637.330.900.000.000.000.000.000.000.000.000.000.000.000
Ditemi cosa ne pensate, se lo ritenete corretto, aggiungo la parte in grassetto.
Grazie per l'aiuto ragazzi.
Posso capire che la curva ellittica secp256k1 fosse un po' troppo complessa da spiegare (anche se chiavi private e chiavi pubbliche sono di fatto proprio elementi di quella curva). Hai scritto che ci sono 2^256 chiavi private (in realtà 2^257 contando compresse e non compresse) ma dal punto di vista della sicurezza del sistema è come se ce ne fossero "solo" 2^160 (ci sono 2^97 chiavi diverse ma tutte valide per ciascun address). Non è proprio la stessa cosa.
Ipotizzo che la tua correzione si riferisse al primo paragrafo del capitolo 8.
Ho fatto un veloce controllo sul numero delle chiavi private che possono essere generate, ed ho trovato più fonti che confermano il fatto che le chiavi private generabili sono tecnicamente 2^256 (^257 non l'ho trovato da nessuna parte me lo puoi spiegare nel dettaglio? hai qualche fonte?).
A parte il discorso 256 VS 257, il primo paragrafo del capitolo 8 mi sembra quindi corretto.
Mi riferisco a
Quote
Più di una volta mi è stato sollevata la domanda: "Cosa succede se qualcuno genera le mie stesse 12 parole? Può accedere ai miei Bitcoin?" La risposta è SI, ma è altamente improbabile praticamente impossibile. La quantità di chiavi private generabili è di (2^256) si avvicina al numero di atomi presenti nell’universo conosciuto (stimato all’incirca in un numero che va da 2^240 e 2^280), sicuramente è più semplice per due persone trovare lo stesso granello di sabbia sul pianeta terra (che in base ad una stima molto approssimativa risulta essere 2^63), rispetto a trovare una chiave privata già utilizzata da qualcun altro. Per chi avesse poca dimestichezza con gli elementi potenza, in questo caso parliamo di un raddoppio ogni unità espressa nell’elevamento.
In questo paragrafo tu esplicitamente colleghi il numero di chiavi private generabili con la misura della sicurezza del sistema.
Quando dici:
"sicuramente è più semplice per due persone trovare lo stesso granello di sabbia sul pianeta terra (che in base ad una stima molto approssimativa risulta essere 2^63), rispetto a trovare una chiave privata già utilizzata da qualcun altro"
io lettore capisco che il problema di sicurezza del mio address è solo se qualcuno trova esattamente la mia chiave privata (1 possibilità / 2^256) mentre invece ci sono ben 2^96 chiavi diverse su 2^256 (1 / 2^160) che permettono di accedere al mio address.
Con questa frase
"Più di una volta mi è stato sollevata la domanda: "Cosa succede se qualcuno genera le mie stesse 12 parole? Può accedere ai miei Bitcoin?" La risposta è SI, ma è altamente improbabile praticamente impossibile. La quantità di chiavi private generabili è di (2^256) si avvicina al numero di atomi ..."
fai intendere che la questione della sicurezza ("accedere ai miei Bitcoin") è legata a quel numero (256 bit) invece che a 160 bit, che è poi la vera misura di entropia del sistema.
Giusto per puntualizzare sulla sicurezza del sistema, se utilizzo un address dal quale ho già effettuato una transazione, ho già esposto la mia chiave pubblica (non solo il mio address), quindi per passare dalla chiave pubblica alla chiave privata mi bastano circa 2^128 "passaggi" (anche se le chiavi private sono 2^256!)
Per quanto riguarda la questione numero di chiavi private 2^256 <-> 2^257, vedi la risposta di rrupoli.
Lo sto leggendo un poco alla volta. Lo trovo fatto benissimo per le persone che si avvicinano per la prima volta.
Mi fa molto piacere. Era proprio il mio obiettivo.
Ho fatto un veloce controllo sul numero delle chiavi private che possono essere generate, ed ho trovato più fonti che confermano il fatto che le chiavi private generabili sono tecnicamente 2^256 (^257 non l'ho trovato da nessuna parte me lo puoi spiegare nel dettaglio? hai qualche fonte?).
L'equivoco nasce da cosa si intenda per 'chiave privata'.
Questa per esempio è una chiave privata in formato Hex (64 Hex chars):
A2242EAD55C94C3DEB7CF2340BFEF9D5BCACA22DFE66E646745EE4371C633FC8
Essa corrisponde allo scalare k che deve essere moltiplicato per il punto G allo scopo di ottenere il punto P sulla curva ellittica (P = k * G).
Il numero massimo di chiavi private in formato Hex che è possibile generare è poco meno di 2^256 (il numero esatto di chiavi private possibili è pari al numero di punti che costituiscono la curva ellittica secp256k1).
L'equivoco nasce nel momento in cui converti la chiave privata in formato WIF (Wallet Import Format) in quanto esistono 2 diversi formati (WIF e WIF compresso) che danno origine a 2 chiavi private diverse:
Questa è la chiave privata scritta sopra, codificata in formato WIF:
5K3hGHXx9qzEKZLh6zKS5umqDGfuc8KUbWtXZ9S2ngDo81AMoxh
Questa è la stessa chiave codificata in formato WIF compresso:
L2etiTycS3Dbnujv1RzMifvsoAAjC3JYoLvRrtDUtc7UZo76CUb2
Per ogni chiave privata in formato Hex esistono quindi due possibili codifiche in formato WIF (compressa e non compressa) per cui il numero totali di chiavi private in formato WIF raddoppia e diventa poco meno di 2^257 (2^256 * 2).
In breve, se ti riferisci al numero di chiavi possibili in formato Hex la risposta è "poco meno di 2^256", se ti riferisci al numero di chiavi possibili in formato WIF (compresse + non compresse) allora risposta è "poco meno di 2^257".
A mio avviso se il contesto del discorso ruota attorno al tema della sicurezza allora è più corretto riferirsi al numero di chiavi private in formato Hex (2^256) in quanto per assurdo potremmo avere 10 formati WIF diversi (che produrrebbero altrettanti diversi Bitcoin address) ma il livello di sicurezza rimarrebbe il medesimo (circa 2^160 chiavi Hex da attaccare in caso di public key non esposta).
P.S.: se ti fosse sfuggito ti suggerisco di studiarti con attenzione il pregevole tutorial sulle curve ellittiche postato da arulbero l'anno scorso: https://bitcointalksearch.org/topic/curve-ellittiche-e-algoritmo-ecdsa-1339031
Ottimo lavoro, ho scaricato il libro e sto iniziando a dargli una lettura ed è ben realizzato. Complimenti e grazie per il tuo contributo.
Grazie. Fammi sapere se trovi erorri, così li correggo.
Non mi pare poi che tu abbia accennato alla questione sicurezza (non dei bitcoin ma personale), questione sollevata in un thread su questo forum (questione che è connaturata con il nuovo paradigma di proprietà del denaro che si realizza mediante la proprietà di chiavi invece che mediante delle relazioni attraverso terzi.)
Effettivamente non avevo mai fatto questa riflessione.
Il realtà il discorso è molto simile ai contanti, all' oro, ai gioielli, orologi costosi, ecc.
Però forse è opportuno aggiungere un paragrafo per mettere in guardia su questo rischio.
Posso capire che la curva ellittica secp256k1 fosse un po' troppo complessa da spiegare (anche se chiavi private e chiavi pubbliche sono di fatto proprio elementi di quella curva). Hai scritto che ci sono 2^256 chiavi private (in realtà 2^257 contando compresse e non compresse) ma dal punto di vista della sicurezza del sistema è come se ce ne fossero "solo" 2^160 (ci sono 2^97 chiavi diverse ma tutte valide per ciascun address). Non è proprio la stessa cosa.
Ipotizzo che la tua correzione si riferisse al primo paragrafo del capitolo 8.
Ho fatto un veloce controllo sul numero delle chiavi private che possono essere generate, ed ho trovato più fonti che confermano il fatto che le chiavi private generabili sono tecnicamente 2^256 (^257 non l'ho trovato da nessuna parte me lo puoi spiegare nel dettaglio? hai qualche fonte?).
A parte il discorso 256 VS 257, il primo paragrafo del capitolo 8 mi sembra quindi corretto.
Modificherei solo "universo conosciuto" con "universo visibile".
Sul discorso chiavi compresse e non compresse, secondo me, non centra nulla con il discorso del numero massimo di chiavi generabili. Se anche qui puoi essere più preciso, perchè temo di non aver afferrato il concetto.
Discorso diverso (quello da te giustamente sollevato) sulla possibilità di un attacco bruteforce su uno specifico address. Qui si stima che ogni address possa in realtà essere sbloccato da 2^96 differenti chiavi private diverse, quindi significherebbe che statisticamente se ne trova una funzionante ogni 2^160 (in media).
Quindi potremo dire che un eventuale attacco bruteforce volto ad individuare la chiave privata relativa ad un address, riesce ad trovare una chiave privata valida ogni 2^160 tentativi. (che comunque mi sembra un numero discretamente grande, per la tecnologia attuale)
Aggiungerei quindi nell'elenco delle potenze, giunto per dare un idea visuale del numero:
2^160 = 1.461.501.637.330.900.000.000.000.000.000.000.000.000.000.000.000
ed un paragrafo che spieghi meglio questo attacco all'address, che è quello dal punto di vista della sicurezza che alla fine interessa di più.
Ottimo lavoro, ho scaricato il libro e sto iniziando a dargli una lettura ed è ben realizzato. Complimenti e grazie per il tuo contributo.
Sto terminando il primo approfondimento sui Fork.
Prima di pubblicarlo vedo di sistemare questa cosa e quelle del numero delle chiavi, che sono rimaste due cose in sospeso che meritano di essere corrette.
Prima di pubblicarlo vedo di sistemare questa cosa e quelle del numero delle chiavi, che sono rimaste due cose in sospeso che meritano di essere corrette.
cut
Ricordo che le prime volte volte che pensavo al resto mi dava fastidio l'idea che ogni utxo dovesse essere speso tutto in una volta, poichè avevo proprio l'idea di bitcoin come numeri su un conto corrente.
L'analogia con le banconote fisiche funziona abbastanza bene, con una precisazione però: ogni volta che si spende un utxo, il suo importo può essere anche frazionato in più parti, un po' come se ci fossero più resti:
ad esempio posso spendere un utxo suddividendolo in 3 output: per pagare con una parte l'address A, con il resto del pagamento all'address A pagare l'address B, e versare quindi il resto finale di nuovo nel mio address di partenza.
Quindi non è corretto dire che un utxo non è frazionabile, è vero che non si può spenderne solo una parte in una transazione, ma all'interno di una singola transazione si può frazionare l'intero utxo in molte parti.
Ricordo che le prime volte volte che pensavo al resto mi dava fastidio l'idea che ogni utxo dovesse essere speso tutto in una volta, poichè avevo proprio l'idea di bitcoin come numeri su un conto corrente.
L'analogia con le banconote fisiche funziona abbastanza bene, con una precisazione però: ogni volta che si spende un utxo, il suo importo può essere anche frazionato in più parti, un po' come se ci fossero più resti:
ad esempio posso spendere un utxo suddividendolo in 3 output: per pagare con una parte l'address A, con il resto del pagamento all'address A pagare l'address B, e versare quindi il resto finale di nuovo nel mio address di partenza.
Quindi non è corretto dire che un utxo non è frazionabile, è vero che non si può spenderne solo una parte in una transazione, ma all'interno di una singola transazione si può frazionare l'intero utxo in molte parti.
Trovo l'equivalenza "UTXO = banconota virtuale" molto robusta come modello esplicativo dell'organizzazione di un wallet.
Uso la dizione "non frazionabile" o "indivisibile" riferendomi al fatto che una banconota non può essere tagliata in due, non se ne può spendere solo una frazione per un pagamento, cioè quando decidi di usarla la devi spendere nella sua interezza (altrimenti perdi la frazione che non intendevi spendere).
Non mi sovvengono altri aggettivi che possano rendere meglio il concetto di "mattone elementare non divisibile".
Terrei comunque separati due concetti:
a) la rappresentazione statica dei bitcoin all'interno di un wallet (molteplici address che contengono molteplici UTXO)
b) come vengono effettivamente usati gli UTXO durante una transazione e che risultati finali si ottengono
Cioè una volta spiegato che l'UTXO è una banconota contenuta all'interno di un address, si passa a spiegare come poter usare queste banconote virtuali in una transazione.
Per spiegare come funziona una transazione in bitcoin è necessario uscire dal modello della banconota fisica che passa di mano dal pagatore al percettore.
Le transazioni in bitcoin hanno infatti peculiarità uniche che vanno spiegate nel dettaglio, il modello della banconota fisica non funziona bene per spiegare una transazione in quanto l'UTXO non viene trasferito da un address ad un altro ma viene piuttosto "invalidato" ed al suo posto vengono generati nuovi UTXO associati ad altri address (od anche al medesimo address).
Volendo rimanere nella metafora fisica del tuo esempio, è come se la banconota indivisibile da 100 Euro (UTXO tratto da un mio address) che uso per pagare tre miei creditori (rappresentati da 3 diversi address) venisse letteralmente bruciata durante la transazione e sostituita da tre nuove banconote da 33 Euro (cioè 3 nuovi UTXO) da consegnare ai creditori e una nuova banconota da 1 Euro (un ulteriore UTXO) per pagare la transaction fee al miner.
Con questo approccio divulgativo puoi riuscire a spiegare agilmente anche le transazioni più complesse (magari con 10 input, 7 output, 1 resto e 1 una fee) mantenendo un adeguato rigore formale.
Lo sto leggendo un poco alla volta. Lo trovo fatto benissimo per le persone che si avvicinano per la prima volta.
Mi fa molto piacere. Era proprio il mio obiettivo.
Esempio semplice
Bob ha acquistato su un exchange 0,8 btc, il suo wallet gli mostrerà quindi una transazione in ingresso di 0,8 btc.
Se Bob deve inviare ad Alice 0,2 btc, il wallet prende la transazione in ingresso di 0,8 BTC, la divide in due transazioni, una da 0,2 che verrà inviata ad Alice e una di 0,6 btc di resto che dovrà reinviare a se stesso. La transazione generata dal wallet di Bob conterrà quindi 1 Input e 2 output.
Bob ha acquistato su un exchange 0,8 btc, il suo wallet gli mostrerà quindi una transazione in ingresso di 0,8 btc.
Se Bob deve inviare ad Alice 0,2 btc, il wallet prende la transazione in ingresso di 0,8 BTC, la divide in due transazioni, una da 0,2 che verrà inviata ad Alice e una di 0,6 btc di resto che dovrà reinviare a se stesso. La transazione generata dal wallet di Bob conterrà quindi 1 Input e 2 output.
Rileggendo questa parte, utilizzeresti il concetto di transazione in modo un po' improprio, in quanto sembra che nel tuo esempio ci siano 3 transazioni. Non è del tutto corretto dire che il wallet prende la transazione in ingresso e la divide in due transazioni in uscita, poichè il wallet prende in realtà l'output non speso di una transazione come input di una nuova transazione e lo suddivide in due output. 1 utxo in input, 2 utxo in output, ma il tutto avviene all'interno di una singola transazione. La transazione deve essere unica proprio perchè l'utxo di partenza non è spendibile in 2 transazioni separate. La transazione trasforma utxo in utxo, e nel fare questo l'input perde la sua proprietà di "unspent". Quindi eviterei di utilizzare il termine "transazione" al posto di "utxo".
Certo era solo per dare un idea dell' approccio.
Lo sto leggendo un poco alla volta. Lo trovo fatto benissimo per le persone che si avvicinano per la prima volta.
Esempio semplice
Bob ha acquistato su un exchange 0,8 btc, il suo wallet gli mostrerà quindi una transazione in ingresso di 0,8 btc.
Se Bob deve inviare ad Alice 0,2 btc, il wallet prende la transazione in ingresso di 0,8 BTC, la divide in due transazioni, una da 0,2 che verrà inviata ad Alice e una di 0,6 btc di resto che dovrà reinviare a se stesso. La transazione generata dal wallet di Bob conterrà quindi 1 Input e 2 output.
Bob ha acquistato su un exchange 0,8 btc, il suo wallet gli mostrerà quindi una transazione in ingresso di 0,8 btc.
Se Bob deve inviare ad Alice 0,2 btc, il wallet prende la transazione in ingresso di 0,8 BTC, la divide in due transazioni, una da 0,2 che verrà inviata ad Alice e una di 0,6 btc di resto che dovrà reinviare a se stesso. La transazione generata dal wallet di Bob conterrà quindi 1 Input e 2 output.
Rileggendo questa parte, utilizzeresti il concetto di transazione in modo un po' improprio, in quanto sembra che nel tuo esempio ci siano 3 transazioni. Non è del tutto corretto dire che il wallet prende la transazione in ingresso e la divide in due transazioni in uscita, poichè il wallet prende in realtà l'output non speso di una transazione come input di una nuova transazione e lo suddivide in due output. 1 utxo in input, 2 utxo in output, ma il tutto avviene all'interno di una singola transazione. La transazione deve essere unica proprio perchè l'utxo di partenza non è spendibile in 2 transazioni separate. La transazione trasforma utxo in utxo, e nel fare questo l'input perde la sua proprietà di "unspent". Quindi eviterei di utilizzare il termine "transazione" al posto di "utxo".
Riguardo alla questione sicurezza, non capisco bene a cosa ti riferisci. Se mi link il thread, vado a leggermelo.
Mi riferisco a questo thread https://bitcointalksearch.org/topic/sicurezza-oltre-gli-aspetti-tecnici-2107660
In sostanza possedere bitcoin (e farlo sapere in giro) è molto più pericoloso che possedere euro su un conto corrente, poichè dal punto di vista pratico i bitcoin sono come contante, e nessuno andrebbe in giro con migliaia di euro in tasca (ma di fatto molti lo fanno con i bitcoin ignorando l'enorme pericolo a livello di sicurezza personale, come testimoniano purtroppo gli ultimi fatti di cronaca di cui si parla alla fine del thread).
La vostra discussione mi ha stimolato, e penso che la scelta migliore, anche per rimanere coerente con quello già scritto nel resto del libro, sia di spiegare le cose a livello di transazioni. Prendetela come una bozza della bozza, devo mettermi li con calma e rileggere i paragrafi da integrare. Gli esempi potrebbero essere qualcosa del genere.
Esempio semplice
Bob ha acquistato su un exchange 0,8 btc, il suo wallet gli mostrerà quindi una transazione in ingresso di 0,8 btc.
Se Bob deve inviare ad Alice 0,2 btc, il wallet prende la transazione in ingresso di 0,8 BTC, la divide in due transazioni, una da 0,2 che verrà inviata ad Alice e una di 0,6 btc di resto che dovrà reinviare a se stesso. La transazione generata dal wallet di Bob conterrà quindi 1 Input e 2 output.
IMMAGINE CHE ILLUSTRA IL TUTTO
Esempio più complesso
Bob ha scritto un libro su Bitcoin, ha inserito al suo interno un Qr Code. Cinque lettori gli hanno donato 0,002 btc per uno, per un totale di 0,01 btc. Bob deve pagare 0,005 btc per l'acquisto di uno spazio web. Il suo wallet, userà quindi 3 input da 0,002, per un totale di 0,006 e genererà 2 output, uno da 0,005 verso il fornitore del servizio web, ed uno da 0,001 di resto verso se stesso.
Ora Bob avrà un saldo di 0,005, composto dai due input che non sono stati intaccati dall'ultima transazione, e dal resto di 0,001 btc.
IMMAGINE CHE ILLUSTRA IL TUTTO
Esempio semplice
Bob ha acquistato su un exchange 0,8 btc, il suo wallet gli mostrerà quindi una transazione in ingresso di 0,8 btc.
Se Bob deve inviare ad Alice 0,2 btc, il wallet prende la transazione in ingresso di 0,8 BTC, la divide in due transazioni, una da 0,2 che verrà inviata ad Alice e una di 0,6 btc di resto che dovrà reinviare a se stesso. La transazione generata dal wallet di Bob conterrà quindi 1 Input e 2 output.
IMMAGINE CHE ILLUSTRA IL TUTTO
Esempio più complesso
Bob ha scritto un libro su Bitcoin, ha inserito al suo interno un Qr Code. Cinque lettori gli hanno donato 0,002 btc per uno, per un totale di 0,01 btc. Bob deve pagare 0,005 btc per l'acquisto di uno spazio web. Il suo wallet, userà quindi 3 input da 0,002, per un totale di 0,006 e genererà 2 output, uno da 0,005 verso il fornitore del servizio web, ed uno da 0,001 di resto verso se stesso.
Ora Bob avrà un saldo di 0,005, composto dai due input che non sono stati intaccati dall'ultima transazione, e dal resto di 0,001 btc.
IMMAGINE CHE ILLUSTRA IL TUTTO
Tempo fa avevo tradotto un articolo sulla questione del resto:
http://bitcoinedintorni.blogspot.it/2015/04/cinque-modi-di-perdere-bitcoin-con-gli.html
magari ti può servire come spunto.
Ricordo che le prime volte volte che pensavo al resto mi dava fastidio l'idea che ogni utxo dovesse essere speso tutto in una volta, poichè avevo proprio l'idea di bitcoin come numeri su un conto corrente.
L'analogia con le banconote fisiche funziona abbastanza bene, con una precisazione però: ogni volta che si spende un utxo, il suo importo può essere anche frazionato in più parti, un po' come se ci fossero più resti:
ad esempio posso spendere un utxo suddividendolo in 3 output: per pagare con una parte l'address A, con il resto del pagamento all'address A pagare l'address B, e versare quindi il resto finale di nuovo nel mio address di partenza.
Quindi non è corretto dire che un utxo non è frazionabile, è vero che non si può spenderne solo una parte in una transazione, ma all'interno di una singola transazione si può frazionare l'intero utxo in molte parti.
Infine per quanto riguarda il numero di chiavi private, poichè un address è lo ripemd160(sha256(una chiave pubblica)), esso è lungo 160 bit. Quindi è ovvio che ci sono moltissime chiavi private (in media 2^256/2^160) che possono controllare lo stesso address (come le password nei siti, se un sito memorizza come dovrebbe essere solo il digest di una password, è chiaro che ci saranno molte altre password (diverse da quella originale) che mi permetteranno di accedere indifferentemente al mio account.)
La vostra discussione mi ha stimolato, e penso che la scelta migliore, anche per rimanere coerente con quello già scritto nel resto del libro, sia di spiegare le cose a livello di transazioni. Prendetela come una bozza della bozza, devo mettermi li con calma e rileggere i paragrafi da integrare. Gli esempi potrebbero essere qualcosa del genere.
Esempio semplice
Bob ha acquistato su un exchange 0,8 btc, il suo wallet gli mostrerà quindi una transazione in ingresso di 0,8 btc.
Se Bob deve inviare ad Alice 0,2 btc, il wallet prende la transazione in ingresso di 0,8 BTC, la divide in due transazioni, una da 0,2 che verrà inviata ad Alice e una di 0,6 btc di resto che dovrà reinviare a se stesso. La transazione generata dal wallet di Bob conterrà quindi 1 Input e 2 output.
IMMAGINE CHE ILLUSTRA IL TUTTO
Esempio più complesso
Bob ha scritto un libro su Bitcoin, ha inserito al suo interno un Qr Code. Cinque lettori gli hanno donato 0,002 btc per uno, per un totale di 0,01 btc. Bob deve pagare 0,005 btc per l'acquisto di uno spazio web. Il suo wallet, userà quindi 3 input da 0,002, per un totale di 0,006 e genererà 2 output, uno da 0,005 verso il fornitore del servizio web, ed uno da 0,001 di resto verso se stesso.
Ora Bob avrà un saldo di 0,005, composto dai due input che non sono stati intaccati dall'ultima transazione, e dal resto di 0,001 btc.
IMMAGINE CHE ILLUSTRA IL TUTTO
Esempio semplice
Bob ha acquistato su un exchange 0,8 btc, il suo wallet gli mostrerà quindi una transazione in ingresso di 0,8 btc.
Se Bob deve inviare ad Alice 0,2 btc, il wallet prende la transazione in ingresso di 0,8 BTC, la divide in due transazioni, una da 0,2 che verrà inviata ad Alice e una di 0,6 btc di resto che dovrà reinviare a se stesso. La transazione generata dal wallet di Bob conterrà quindi 1 Input e 2 output.
IMMAGINE CHE ILLUSTRA IL TUTTO
Esempio più complesso
Bob ha scritto un libro su Bitcoin, ha inserito al suo interno un Qr Code. Cinque lettori gli hanno donato 0,002 btc per uno, per un totale di 0,01 btc. Bob deve pagare 0,005 btc per l'acquisto di uno spazio web. Il suo wallet, userà quindi 3 input da 0,002, per un totale di 0,006 e genererà 2 output, uno da 0,005 verso il fornitore del servizio web, ed uno da 0,001 di resto verso se stesso.
Ora Bob avrà un saldo di 0,005, composto dai due input che non sono stati intaccati dall'ultima transazione, e dal resto di 0,001 btc.
IMMAGINE CHE ILLUSTRA IL TUTTO
Jump to: