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.
Topic: Chi decide l'ammontare di zeri per l'hash del proof-of-work? (Read 1919 times)
Grazie mille, fantastico come sempre!
Ciao!
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).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.
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 !
Grazie mille, fantastico come sempre!
Ciao!
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).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.
Ciao!
Code:
if (bnNew > Params().ProofOfWorkLimit())
bnNew = Params().ProofOfWorkLimit();
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.
ottimo direi! grazie mille.
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:
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
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.
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ù
Questo ci ricorda che la difficoltà non è infinita.
Riporto le parti più interessanti:
Code:
int64 nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
Code:
if (nActualTimespan < nTargetTimespan/4)
nActualTimespan = nTargetTimespan/4;
if (nActualTimespan > nTargetTimespan*4)
nActualTimespan = nTargetTimespan*4;
Code:
// Retarget
bnNew *= nActualTimespan;
bnNew /= nTargetTimespan;
Code:
if (bnNew > Params().ProofOfWorkLimit())
bnNew = Params().ProofOfWorkLimit();
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.
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
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) 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.
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.
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.
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!
Ciao!
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.
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.
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
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/Difficulty
Mancano un po' di nozioni se chiedi questo.
Comunque benvenuto
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
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
Jump to: