Why do miners increase the nonce to compute a block hash rather than just generating a random block hash? It seems to me that both approaches would have the same likeliness of finding a result that is below the target.

If the answer is that it is quicker to increase the nonce instead of just generating a random hash to find a valid result, could you show this in a mathematical/statistical way?


The hashing function used in Bitcoin is deterministic, that is hashing the same input, i.e., block header, will always result in the same output. This is necessary so that others can also check that a Proof-of-Work is valid.

This means that in order to compute a new hash the input to the hash function needs to be altered. The easiest way to alter the input is changing the nonce since this is a free-form field that may take any value. Other ways to modify the input is for example swapping transactions or modifying the coinbase transaction, which would require that the merkle root be recomputed in the header. The timestamp is also a popular choice, however its values are limited by a range of acceptable times.

In case you are wondering why we don't simply rehash the output of the previous hashing function to get the next value: this would destroy the proof-of-work mechanism, which requires an easy to verify proof that the issuer has performed some work. The key here is easy: if we iteratively hash the results of the previous solution then the verifying party would also have to perform this work to check that the issuer has performed the work. when varying the input this does not happen since given the input the verifier can perform a single hash operation and check the result.

  • Thank you @cdecker . That makes sense. Could you explain what you mean with "when varying the input this does not happen since given the input the verifier can perform a single hash operation and check the result"? Isn't a single hash operation always enough for verification? – Glenn Feb 21 '16 at 16:26
  • Exactly, that's the difference between altering the input (verifier just takes PoW, hashes and checks the output) and the iterative case (verifier would have to take block header and hash it exactly the same number of times as the issuer did). – cdecker Feb 21 '16 at 16:42
  • Thank you cdecker. Just trying to wrap my head around the would-be verification In the iterative case...RE: your previous comment - if the verifier takes the block header and the issuer's final hash, wouldn't one hash operation also be enough? In that case, the verifier would have all necessary input (blockheader + the issuer's final hash) and one single hash operation would allow the verifier to check the resulting output and see if it's valid, no? – Glenn Feb 21 '16 at 16:54
  • He could not connect the header to the pre-image that is being passed along, this would allow an intermediary node to modify the header arbitrarily without invalidating the proof-of-work. So let's say SHA256(...n-1 times...(header) ...) is the preimage of SHA256(...n times...(header)...) which is a PoW, then the verifier would be able to verify that SHA256(pre-image) is a PoW but not that this pre-image is n-1 nested SHA256 calls on the header without actually doing these calls. – cdecker Feb 21 '16 at 17:01
  • Thank you cdecker. I thought that verifying a PoW consisted of only performing a single hash operation to check whether the issuer's 'solution' resulted in a valid output (in which case, both scenarios -altering input and the iterative case- would require the same amount of work to verify). From your answer I gather that the entire work (or at least logic behind the 'solution') also needs to be verified. – Glenn Feb 21 '16 at 17:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.