yeah, to put quite simply... there is no "might get used again"
plus making a database that huge... yeah, no... lol
Topic: Why people keep recomputing hashes? (Read 868 times)
Try reading this little article: https://en.bitcoin.it/wiki/Block_hashing_algorithm
The nonce is not the only thing that changes. There are actually 6 "parts" that get grouped together and hashed, and the nonce range is only one of those. The other 5 all get updated at different intervals, but it's designed so that we're never working on the same work twice. Ever.
Also, see Here. I like the way they worded it: "Even a small change in the message will result in a mostly different hash, due to the avalanche effect." You can see their examples in the wiki article that illustrate this point.
The nonce is not the only thing that changes. There are actually 6 "parts" that get grouped together and hashed, and the nonce range is only one of those. The other 5 all get updated at different intervals, but it's designed so that we're never working on the same work twice. Ever.
Also, see Here. I like the way they worded it: "Even a small change in the message will result in a mostly different hash, due to the avalanche effect." You can see their examples in the wiki article that illustrate this point.
Who is hashing with CPU? Botnets.
If a hash doesn't meet or exceed the current difficulty why store for later when the difficulty is even higher?
If a hash doesn't meet or exceed the current difficulty why store for later when the difficulty is even higher?
Huge amount of CPU power is in the hash.
Why not store all computed hashes in databases and see if one match up?
What am I missing?
In fact every nonce is probably computed again and again and again.... So why not store it for future uses?
Why not store all computed hashes in databases and see if one match up?
What am I missing?
In fact every nonce is probably computed again and again and again.... So why not store it for future uses?
Jump to: