sktrdie (OP)
|
|
October 15, 2013, 10:21:05 PM |
|
Salve,
Domandina tecnica sul protocollo Bitcoin: leggendo il paper di Satoshi, parla appunto del proof-of-work e che per generare un blocco bisogna hashare delle transazioni (che faranno appunto parte del blocco stesso) in modo che questo hash cominci con un numero di bit zero ("the hash begins with a number of zero bits").
Questo è molto vago a mio parere e vorrei capire come viene implementato. Come fanno i minatori a capire di aver generato l'hash che cominci con il numero esatto di zeri? Dove viene impostata questa variabile che indica questo ammontare di zeri?
Grazie, Luca
|
|
|
|
|
|
|
|
|
You can see the statistics of your reports to moderators on the "Report to moderator" pages.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
Ermo
|
|
October 16, 2013, 08:27:52 AM |
|
Salve,
Domandina tecnica sul protocollo Bitcoin: leggendo il paper di Satoshi, parla appunto del proof-of-work e che per generare un blocco bisogna hashare delle transazioni (che faranno appunto parte del blocco stesso) in modo che questo hash cominci con un numero di bit zero ("the hash begins with a number of zero bits").
Questo è molto vago a mio parere e vorrei capire come viene implementato. Come fanno i minatori a capire di aver generato l'hash che cominci con il numero esatto di zeri? Dove viene impostata questa variabile che indica questo ammontare di zeri?
Grazie, Luca
Dai un occhiata al concetto di difficoltà e target su wiki: https://en.bitcoin.it/wiki/DifficultyMancano un po' di nozioni se chiedi questo. Comunque benvenuto
|
LTC: Lea4dcKi2FuZZecyDqaqvH5T5CJBLuSW2h XPM: AKqTVeegaUS8BJUfFp7QWh4ANUTNFpeiGJ XRP: rMAiUYD4nE2odV8fmRoQE9PzvsNZdNMNNJ
|
|
|
sktrdie (OP)
|
|
October 16, 2013, 08:40:11 AM |
|
Grazie Enzo, Ovviamente mancano un po' di nozioni altrimenti non avrei chiesto la domanda. Passare un link, peraltro in inglese, non è proprio la risposta che cercavo ma ti ringrazio comunque.
|
|
|
|
Stemby
Legendary
Offline
Activity: 2450
Merit: 1008
|
|
October 16, 2013, 08:46:57 AM |
|
In realtà il wiki non è per niente chiaro sull'argomento; la domanda è perfettamente legittima, e sono io stesso curioso di leggere una risposta esauriente. Ciao!
|
“…virtual currencies, could have a substitution effect on central bank money if they become widely accepted.” ECB Report, October 2012
|
|
|
sktrdie (OP)
|
|
October 16, 2013, 10:52:11 AM |
|
Per chi volesse una spiegazione più dettagliata, quando un miner (o nodo) comincia a cercare l'hash per l'ultimo blocco, il miner ha come obbiettivo un target che è una variabile calcolata in base al tempo di creazione dei blocchi precedenti.
Una volta trovato l'hash minore o uguale a questo target, il miner puo' annunciare vittoria e trasmettere l'header del blocco ad altri nodi. L'header include una variabile importante chiamata 'nonce'. Questa è la variabile che è stata alterata in modo da trovare un hash minore o uguale al target.
Un utente Bitcoin puo' accertarsi che quest'ultimo blocco sia valido semplicemente hashando l'header del blocco, e assicurarsi che sia minore del target.
È molto difficile trovare un 'nonce' che generi un hash minore del target. Un attacker non potrà quindi inventarsi un nonce qualsiasi e dichiarare vittoria... dovrà farsi tutto il lavoro.
|
|
|
|
Stemby
Legendary
Offline
Activity: 2450
Merit: 1008
|
|
October 16, 2013, 10:59:30 AM |
|
Per chi volesse una spiegazione più dettagliata, quando un miner (o nodo) comincia a cercare l'hash per l'ultimo blocco, il miner ha come obbiettivo un target che è una variabile calcolata in base al tempo di creazione dei blocchi precedenti.
Una volta trovato l'hash minore o uguale a questo target, il miner puo' annunciare vittoria e trasmettere l'header del blocco ad altri nodi. L'header include una variabile importante chiamata 'nonce'. Questa è la variabile che è stata alterata in modo da trovare un hash minore o uguale al target.
Un utente Bitcoin puo' accertarsi che quest'ultimo blocco sia valido semplicemente hashando l'header del blocco, e assicurarsi che sia minore del target.
È molto difficile trovare un 'nonce' che generi un hash minore del target. Un attacker non potrà quindi inventarsi un nonce qualsiasi e dichiarare vittoria... dovrà farsi tutto il lavoro.
Questo l'avevo già ben chiaro, ma resta la domanda: qual è esattamente la formula usata dal miner per stabilire il target? Notare che tutti i miner devono essere concordi su questo valore! (anche a posteriori)
|
“…virtual currencies, could have a substitution effect on central bank money if they become widely accepted.” ECB Report, October 2012
|
|
|
sktrdie (OP)
|
|
October 16, 2013, 11:50:04 AM |
|
Questo l'avevo già ben chiaro, ma resta la domanda: qual è esattamente la formula usata dal miner per stabilire il target? Notare che tutti i miner devono essere concordi su questo valore! (anche a posteriori)
Si giusto. Ho fatto un po' di ricerca e sembra che il nuovo target viene calcolato con: vecchio_target * max(0.25, min(4,(two weeks/(block n-2016 time - block n time)))) Non riesco a trovarlo nel codice esattamente ma dovrebbe essere più o meno giusto. La variabile importante della formula è il tempo di creazione dei blocchi precedenti. Poi c'è anche questo 2016 che è un valore fisso che permette il cambio del target ogni 2 settimane. Forse ci sono più dettagli da coprire ma in pratica questa formula permette che si generino in media 1 blocco ogni 10 minuti, indipendentemente dall'ammontare ci computazione espressa dai minatori: più potenza c'è, più difficile è il target; meno potenza, più facile diventa il target. Luca
|
|
|
|
Stemby
Legendary
Offline
Activity: 2450
Merit: 1008
|
|
October 16, 2013, 11:53:24 AM |
|
Si giusto. Ho fatto un po' di ricerca e sembra che il nuovo target viene calcolato con: vecchio_target * max(0.25, min(4,(two weeks/(block n-2016 time - block n time))))
Ottimo, grazie. Hai un link? Sarebbe bene aggiungerla al wiki, come documentazione sul concetto di target; meglio ancora se commentata.
|
“…virtual currencies, could have a substitution effect on central bank money if they become widely accepted.” ECB Report, October 2012
|
|
|
rb1205
|
|
October 16, 2013, 01:41:22 PM Last edit: October 17, 2013, 09:48:05 PM by rb1205 |
|
Il codice che calcola il target che un blocco deve soddisfare, e quindi implicitamente anche il retarget, è nel file main.cpp nella funzione GetNextWorkRequired, attualmente alla riga 1285 Riporto le parti più interessanti: int64 nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
Qui viene calcolato il tempo effettivamente passato dall'ultimo blocco all'ultimo del periodo precedente, ovvero il tempo in cui sono stati trovati i 2016 blocchi if (nActualTimespan < nTargetTimespan/4) nActualTimespan = nTargetTimespan/4; if (nActualTimespan > nTargetTimespan*4) nActualTimespan = nTargetTimespan*4;
Questo codice limita lo scostamento del tempo reale tra un quarto e quattro volte l'ideale, in modo che la variazione di difficoltà in un retarget non possa mai essere inferiore al 25% o maggiore del 400%. Detto questo, non mi è chiaro il ragionamento che motiva questo limite, sopratutto per quanto riguarda l'aumento. // Retarget bnNew *= nActualTimespan; bnNew /= nTargetTimespan;
Qui viene effettivamente calcolato il retarget moltiplicando il vecchio target per il rapporto tra tempo reale passato dall'ultimo retarget e il tempo ideale di 2 settimane. Se il tempo è stato maggiore il rapporto è <1 e la difficoltà diminuirà, e viceversa, in modo lineare: se il tempo è stato il 30% meno di 14 giorni, la prossima difficoltà sarà del 30% in più if (bnNew > Params().ProofOfWorkLimit()) bnNew = Params().ProofOfWorkLimit(); Questo ci ricorda che la difficoltà non è infinita.
|
|
|
|
sktrdie (OP)
|
|
October 16, 2013, 08:49:16 PM |
|
ottimo direi! grazie mille.
|
|
|
|
androz
|
|
October 16, 2013, 09:10:33 PM |
|
if (bnNew > Params().ProofOfWorkLimit()) bnNew = Params().ProofOfWorkLimit(); Questo ci ricorda che la difficoltà non è infinita. interessante, quale sarebbe il limite massimo? fantasticando un pò, se quindi v'è un limite alla difficoltà (cosa che non sapevo) teoricamente a un certo punto gli asic del futuro non sarebbero soggetti alla progressiva obsolescenza. nel senso che, ponendo sempre la difficoltà massima, se un ipotetico asic produrrà un btc al giorno, la sua resa sarà sempre la stessa o maggiore.
|
|
|
|
Stemby
Legendary
Offline
Activity: 2450
Merit: 1008
|
|
October 16, 2013, 09:50:12 PM Last edit: October 16, 2013, 10:17:07 PM by Stemby |
|
Grazie mille, fantastico come sempre! Questo codice limita lo scostamento del tempo reale tra un quarto e quattro volte l'ideale, in modo che la variazione di difficoltà in un retarget non possa mai essere inferiore al 25% o maggiore del 400%. Detto questo, non mi è chiaro il ragionamento che motiva questo limite, sopratutto per quanto riguarda l'aumento.
Del limite ero a conoscenza, ma anche a me non è per niente chiaro perché ci sia. In ogni caso si tratta di situazioni davvero estreme, che molto difficilmente vedremo. fantasticando un pò, se quindi v'è un limite alla difficoltà (cosa che non sapevo) teoricamente a un certo punto gli asic del futuro non sarebbero soggetti alla progressiva obsolescenza. nel senso che, ponendo sempre la difficoltà massima, se un ipotetico asic produrrà un btc al giorno, la sua resa sarà sempre la stessa o maggiore.
Anch'io non sapevo della difficoltà massima. Comunque no, perché si raggiungerebbe in meno di 4 anni il dimezzamento, ma poi questo avverrebbe: anche trovando lo stesso numero di blocchi per unità di tempo, il premio man mano diminuirebbe, fino ad azzerarsi ad un certo punto (escludendo le commissioni presenti nel blocco). Ciao!
|
“…virtual currencies, could have a substitution effect on central bank money if they become widely accepted.” ECB Report, October 2012
|
|
|
Ermo
|
|
October 17, 2013, 08:30:13 AM |
|
Grazie mille, fantastico come sempre! Questo codice limita lo scostamento del tempo reale tra un quarto e quattro volte l'ideale, in modo che la variazione di difficoltà in un retarget non possa mai essere inferiore al 25% o maggiore del 400%. Detto questo, non mi è chiaro il ragionamento che motiva questo limite, sopratutto per quanto riguarda l'aumento.
Del limite ero a conoscenza, ma anche a me non è per niente chiaro perché ci sia. In ogni caso si tratta di situazioni davvero estreme, che molto difficilmente vedremo. fantasticando un pò, se quindi v'è un limite alla difficoltà (cosa che non sapevo) teoricamente a un certo punto gli asic del futuro non sarebbero soggetti alla progressiva obsolescenza. nel senso che, ponendo sempre la difficoltà massima, se un ipotetico asic produrrà un btc al giorno, la sua resa sarà sempre la stessa o maggiore.
Anch'io non sapevo della difficoltà massima. Comunque no, perché si raggiungerebbe in meno di 4 anni il dimezzamento, ma poi questo avverrebbe: anche trovando lo stesso numero di blocchi per unità di tempo, il premio man mano diminuirebbe, fino ad azzerarsi ad un certo punto (escludendo le commissioni presenti nel blocco). Ciao! Limitare l'incremento di difficoltà credo che serva per compensare sbalzi troppo elevati quando non c'è un equilibrio di hash, ad es. quando ci sono pochi minatori e uno si mette a pompare e poi a spegnere per poi riguadagnarci dopo. Essendo un dato più statistico che deterministico ha senso. La difficoltà massima è una cosa estrema data dal fatto che sha1 è a lunghezza fissa. Comunque ricordo che le collisioni possibili sono 2^60. Ci vorrebbe un computer quantistico per arrivare a quei livelli, altro che asic !
|
LTC: Lea4dcKi2FuZZecyDqaqvH5T5CJBLuSW2h XPM: AKqTVeegaUS8BJUfFp7QWh4ANUTNFpeiGJ XRP: rMAiUYD4nE2odV8fmRoQE9PzvsNZdNMNNJ
|
|
|
rb1205
|
|
October 17, 2013, 09:55:54 PM |
|
Scusate, mi rendo conto ora lo smile non era sufficiente a far capire il tono della frase. E' innegabile che ci sia un limite alla difficoltà: per l'algoritmo di hashing attuale è di 2256, ovvero circa 1077, ma come dice Ermo è molto di più di quanto i limiti informatici e anche fisici possano permettere di lambire. In realtà è un limite più logico/filosofico che reale, dal punto di vista pratico si può tranquillamente pensare alla difficoltà come una variabile potenzialmente infinita. Tanto più che, qualora in un futuro remoto la difficoltà dovesse effettivamente arrivare da quelle parti, l'algoritmo di hashing sarà stato sostituito con uno più "capiente" molto, molto prima che questo possa diventare un problema
Anche la condizione di controllo da me riportata è più una formalità di programmazione dovuta al passaggio tra variabili di dimensioni diverse che un limite da applicarsi in servizio; non è previsto che si verifichi mai in condizioni normali.
|
|
|
|
|