<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2016-02-21T16:26:41.093Z
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
CC BY-SA 3.0
2016-02-21T16:42:32.577Z
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
CC BY-SA 3.0
2016-02-21T16:54:21.443Z
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
CC BY-SA 3.0
2016-02-21T17:01:18.403Z
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
CC BY-SA 3.0
2016-02-21T17:15:51.590Z
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
CC BY-SA 3.0
2016-02-21T22:01:50.927Z
@Glenn You could verify the PoW with but a single hash. But that wouldn't verify that the PoW in fact secures the claimed block, which is what you need to verify.
David Schwartz
CC BY-SA 3.0
2016-02-22T00:46:55.793Z
@DavidSchwartz Thank you for weighing in David. Could you elaborate on what you mean?  I hadn't read about the PoW securing the claimed block is what needs to be verified (at least not in those words).
Glenn
CC BY-SA 3.0
2016-02-22T00:48:41.607Z
The point of the PoW is to secure the block chain. Just proving you did work is not helpful, that work must be tied to the particular block you're securing.
David Schwartz
CC BY-SA 3.0
2016-02-22T01:12:03.027Z
Thank you very much @DavidSchwartz . With this question, I feel I might have ventured into blockchain specifics too early in my context of understanding to already be asking 'what if' questions. But this did contribute to my understanding.  Many thanks to both cdecker and you.
Glenn
CC BY-SA 3.0
2016-02-21T16:09:09.267Z
2016-02-21T16:09:09.267Z
cdecker
<p>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.  </p>

<p>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?</p>

<blockchain><hash><proof-of-work><nonce>
Why change the nonce instead of just rehashing?
Glenn
# Why change the nonce instead of just rehashing?

(Asked by: username_0 on 2016-02-21)

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?

**Tags:** blockchain, hash, proof-of-work, nonce


---

## 1 answers

### Answer by username_1 on 2016-02-21. Score: 5 | Accepted answer

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.

> **Comments:**
> **username_0**: Thank you @username_1 .  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?  
> **username_1**: 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).  
> **username_0**: Thank you username_1. 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?  
> **username_1**: 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.  
> **username_0**: Thank you username_1.  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.  
> **username_2**: @username_0 You could verify the PoW with but a single hash. But that wouldn't verify that the PoW in fact secures the claimed block, which is what you need to verify.  
> **username_0**: @username_2 Thank you for weighing in username_2. Could you elaborate on what you mean?  I hadn't read about the PoW securing the claimed block is what needs to be verified (at least not in those words).  
> **username_2**: The point of the PoW is to secure the block chain. Just proving you did work is not helpful, that work must be tied to the particular block you're securing.  
> **username_0**: Thank you very much @username_2 . With this question, I feel I might have ventured into blockchain specifics too early in my context of understanding to already be asking 'what if' questions. But this did contribute to my understanding.  Many thanks to both username_1 and you.  

---

