<p>After the comments, I think your question boils down to this:</p>

<blockquote>
  <p>For the <code>prevBlockHash</code> field of a block header, when computing the hash of the previous block's header, could we exclude its nonce value?</p>
</blockquote>

<p>I can't think of any practical or security problems that would result from this.  A hash of everything except the nonce would still certify all the important data from the block, including the transactions contained in it, and its own <code>prevBlockHash</code> which incorporates by reference all previous blocks.</p>

<p>However, there would be no point in doing that.  We already have to compute the hash of the previous header including the nonce to verify that it is a proof-of-work of the appropriate difficulty.  Having done so, we might as well use this value as the "block ID" for all purposes, including the <code>prevBlockHash</code>.  Computing a different hash value, excluding the nonce, would require more code, more developer time, and more computation time; would add potential for bugs in the hashing code itself; and would lead to a lot of potential confusion when people try to keep track of which part of the code uses which hash.  All this in exchange for no benefit whatsoever, as far as I can tell.</p>

CC BY-SA 3.0
2016-07-27T18:51:40.120Z
I'm thinking along the same lines as well, just wanted to confirm there's not something I'm missing. Thanks for helping me clarify the question.
Kostas
CC BY-SA 3.0
2016-07-27T20:17:35.850Z
Thanks, with your answer I finally understood what the question was about. :)
Murch
CC BY-SA 3.0
2016-07-27T18:41:11.080Z
2016-07-27T18:41:11.080Z
Nate Eldredge
<p>Yes, you're correct. Without the nonce, we could still generate valid blocks.
However, to get a different hash we need to change the input for the hash. The input for the hash is the block header.</p>

<p>If there were no nonce, we would have to change something else about the block header for each try. That would only leave the timestamp or the Merkle root.  Other header items are fixed.<br>
The timestamp is icky, because we would like it to show the actual time. So, we'd have to change the Merkle root.</p>

<p>The Merkle root calculated by hashing all transactions in the Merkle tree where they are listed. If we change e.g. the Coinbase or the order of the transactions in the tree, we could also gain another different combination to try. But to do so, we'd have to recalculate the Merkle root.</p>

<p>Rather, we put a nonce in the header directly that allows us to use the same block candidate for a number of different hashing attempts.</p>

<p>Hence, the nonce is used to introduce randomness <strong>into the blockheader</strong>. That's why it </p>

<p>a) has to be changed, and<br>
 b) has to be in the blockheader. ;)</p>

CC BY-SA 3.0
2016-07-27T14:48:12.747Z
This doesn't answer my question, but it's not your fault :) I rewrote the question to make my point clearer. I understand the use of the nonce. I question why it needs to be considered when calculating the `prevBlockHash` (in the next block).
Kostas
CC BY-SA 3.0
2016-07-27T15:54:32.857Z
I've just read your question again, and I don't understand what you're trying to ask. If the nonce were not part of what was hashed it would a) not contribute to the blockhash, b) could be arbitrary, and c) would serve no purpose. If it's not in the hashed part of the block, why would you add it in the first place. I've already covered what it's function is in my answer, though. So, I'm really confused now.
Murch
CC BY-SA 3.0
2016-07-27T18:27:40.570Z
I think what's missing is that I'm referring to the `prevBlockHash` hash, whereas you refer to the proof-of-work hash calculation. All I ask is if things would break (or if you would lose a significant security property) if you were to write a `calcPrevHash` function that ignores the nonce field. I did yet another rewrite of the question to make this clearer.
Kostas
CC BY-SA 3.0
2016-07-27T05:59:07.153Z
2016-07-27T06:07:05.187Z
2016-07-27T06:07:05.187Z
Murch
<p>I understand the role that the nonce plays in the block header for calculating a hash for a valid proof of work.</p>

<p>But what I ask is: Do we consider the nonce in the <code>prevBlockHash</code> calculation of the previous block because, well, it's in the block header already (for the proof-of-work calculation), and it would be silly to write a <code>calcPrevBlockHash</code> function that calculates the previous block's header by ignoring the nonce?</p>

<p>Or is there a specific security property or assurance that we get when including the nonce in the <code>prevBlockHash</code> calculation of the subsequent block?</p>

<p>For instance, you could argue that we hash the timestamp because we want to capture the time that the block was generated. See answer here: <a href="https://bitcoin.stackexchange.com/questions/12954/why-the-timestamp-component-of-the-block-header/12961#comment16653_12961">Why the timestamp component of the block header?</a> I guess you can argue the same for the nonce field.</p>

<p>But I claim that we could still have the nonce in the block header, and not hash it during the <code>prevBlockHash</code> calculation of the subsequent block, and things would still work. You would still be (a) able to validate this block, and (b) unable to mess around with the transactions in the block, because that would modify the <code>hashMerkeRoot</code> field, and thus render the block invalid.</p>

CC BY-SA 3.0
2016-07-26T19:39:21.200Z
Possible duplicate of [Why change the nonce instead of just rehashing?](http://bitcoin.stackexchange.com/questions/43007/why-change-the-nonce-instead-of-just-rehashing)
Jestin
CC BY-SA 3.0
2016-07-27T02:09:26.193Z
It is not. I understand why the nonce needs to be changed, I question why it needs to be included in the block header, and thus be hashed.
Kostas
CC BY-SA 3.0
2016-07-27T02:24:18.820Z
You still have to include the nonce in the block hash somehow, otherwise what do you change in order to find a good proof-of-work?  And in that case, anyone who tries to validate the block will need to be given the nonce, or have to do a ton of extra work to reconstruct it.  If you don't put it in the block, you'd have to distribute it some other way.
Nate Eldredge
CC BY-SA 3.0
2016-07-27T14:39:58.147Z
@NateEldredge: 1. "You still have to include the nonce in the block hash somehow, otherwise what do you change in order to find a good proof-of-work?" The nonce of course. Why do you *have* to include it in the block hash though? 2. "If you don't put it in the block, you'd have to distribute it some other way." But I never suggested not including the nonce in the block. My question has to do with why we're including it in the block *header*. Is there a reason it needs to be hashed, or is it a "just because" thing.
Kostas
CC BY-SA 3.0
2016-07-27T15:25:46.173Z
@Kostas: So, you have a block header.  You compute the hash of it.  The result doesn't have enough leading zeros to be a valid proof-of-work.  Now what?  You can do whatever you want to the nonce, but it's irrelevant: if it's not in the header, then the data you're hashing doesn't change, and when you hash it again you're just going to get the same not-good-enough hash value.  The hash function is a *function*, after all; giving it the same input always gives the same output.
Nate Eldredge
CC BY-SA 3.0
2016-07-27T18:10:09.110Z
@NateEldredge: We talk about different hashing processes. There's the process where you try to come up with a block header hash that's lower than the target. It makes perfect sense to consider the nonce here. (In fact, the nonce is a key element in this hash calculation.) This is what you refer to, and we agree. However, I refer to the other hashing process that occurs when I want to create block n+1, and wish to refer to block n by its `prevBlockHash`.
Kostas
CC BY-SA 3.0
2016-07-27T18:11:20.210Z
What I ask then is: Is there some specific property that mandates why we need to include the nonce in this `prevBlockHash` hash? Or is it something along the lines of: "Well, it's part of the header because we need it there to calculate the proof-of-work. We actually don't need to include it when doing the `prevBlockHash` thing (we don't get any extra warranties by doing so), but it would be overkill to code a `calcPrevBlockHash` function that ignores the `nonce` field, so we just include it as well in our `prevBlockHash` calcuation."
Kostas
CC BY-SA 3.0
2016-07-27T18:28:10.203Z
@Kostas: Ok, now I think I understand your question.  As it stands, the two processes are one and the same!  I suppose in principle you could make them separate, and exclude the nonce from the latter, but it gains nothing and adds unnecessary complexity.
Nate Eldredge
CC BY-SA 3.0
2016-07-27T18:31:43.753Z
@NateEldredge: Right. `hashBlockHeader()` is what you use for the proof-of-work calculation and the `prevBlockHash` calculation now. (Note: made-up function names.) All I'm asking is: If you were to calculate `prevBlockHash` using a `calcPrevBlockHash()` function that ignores the nonce field, would that break anything? Would you lose any security properties that would currently have?
Kostas
CC BY-SA 3.0
2016-07-27T18:52:37.780Z
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/43096/discussion-between-kostas-and-nate-eldredge).
Kostas
<block-header><nonce>
Reason behind hashing the nonce in prevBlockHash?
Kostas
# Reason behind hashing the nonce in prevBlockHash?

(Asked by: username_0 on 2016-07-26)

I understand the role that the nonce plays in the block header for calculating a hash for a valid proof of work.

But what I ask is: Do we consider the nonce in the `prevBlockHash` calculation of the previous block because, well, it's in the block header already (for the proof-of-work calculation), and it would be silly to write a `calcPrevBlockHash` function that calculates the previous block's header by ignoring the nonce?

Or is there a specific security property or assurance that we get when including the nonce in the `prevBlockHash` calculation of the subsequent block?

For instance, you could argue that we hash the timestamp because we want to capture the time that the block was generated. See answer here: [Why the timestamp component of the block header?](https://bitcoin.stackexchange.com/questions/12954/why-the-timestamp-component-of-the-block-header/12961#comment16653_12961) I guess you can argue the same for the nonce field.

But I claim that we could still have the nonce in the block header, and not hash it during the `prevBlockHash` calculation of the subsequent block, and things would still work. You would still be (a) able to validate this block, and (b) unable to mess around with the transactions in the block, because that would modify the `hashMerkeRoot` field, and thus render the block invalid.

**Tags:** block-header, nonce

> **Comments:**
> **username_1**: Possible duplicate of [Why change the nonce instead of just rehashing?](http://bitcoin.stackexchange.com/questions/43007/why-change-the-nonce-instead-of-just-rehashing)  
> **username_0**: It is not. I understand why the nonce needs to be changed, I question why it needs to be included in the block header, and thus be hashed.  
> **username_2**: You still have to include the nonce in the block hash somehow, otherwise what do you change in order to find a good proof-of-work?  And in that case, anyone who tries to validate the block will need to be given the nonce, or have to do a ton of extra work to reconstruct it.  If you don't put it in the block, you'd have to distribute it some other way.  
> **username_0**: @username_2: 1. "You still have to include the nonce in the block hash somehow, otherwise what do you change in order to find a good proof-of-work?" The nonce of course. Why do you *have* to include it in the block hash though? 2. "If you don't put it in the block, you'd have to distribute it some other way." But I never suggested not including the nonce in the block. My question has to do with why we're including it in the block *header*. Is there a reason it needs to be hashed, or is it a "just because" thing.  
> **username_2**: @username_0: So, you have a block header.  You compute the hash of it.  The result doesn't have enough leading zeros to be a valid proof-of-work.  Now what?  You can do whatever you want to the nonce, but it's irrelevant: if it's not in the header, then the data you're hashing doesn't change, and when you hash it again you're just going to get the same not-good-enough hash value.  The hash function is a *function*, after all; giving it the same input always gives the same output.  
> **username_0**: @username_2: We talk about different hashing processes. There's the process where you try to come up with a block header hash that's lower than the target. It makes perfect sense to consider the nonce here. (In fact, the nonce is a key element in this hash calculation.) This is what you refer to, and we agree. However, I refer to the other hashing process that occurs when I want to create block n+1, and wish to refer to block n by its `prevBlockHash`.  
> **username_0**: What I ask then is: Is there some specific property that mandates why we need to include the nonce in this `prevBlockHash` hash? Or is it something along the lines of: "Well, it's part of the header because we need it there to calculate the proof-of-work. We actually don't need to include it when doing the `prevBlockHash` thing (we don't get any extra warranties by doing so), but it would be overkill to code a `calcPrevBlockHash` function that ignores the `nonce` field, so we just include it as well in our `prevBlockHash` calcuation."  
> **username_2**: @username_0: Ok, now I think I understand your question.  As it stands, the two processes are one and the same!  I suppose in principle you could make them separate, and exclude the nonce from the latter, but it gains nothing and adds unnecessary complexity.  
> **username_0**: @username_2: Right. `hashBlockHeader()` is what you use for the proof-of-work calculation and the `prevBlockHash` calculation now. (Note: made-up function names.) All I'm asking is: If you were to calculate `prevBlockHash` using a `calcPrevBlockHash()` function that ignores the nonce field, would that break anything? Would you lose any security properties that would currently have?  
> **username_0**: Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/43096/discussion-between-username_0-and-username_2-username_2).  

---

## 2 answers

### Answer by username_2 on 2016-07-27. Score: 2 | Accepted answer

After the comments, I think your question boils down to this:

> For the `prevBlockHash` field of a block header, when computing the hash of the previous block's header, could we exclude its nonce value?

I can't think of any practical or security problems that would result from this. A hash of everything except the nonce would still certify all the important data from the block, including the transactions contained in it, and its own `prevBlockHash` which incorporates by reference all previous blocks.

However, there would be no point in doing that. We already have to compute the hash of the previous header including the nonce to verify that it is a proof-of-work of the appropriate difficulty. Having done so, we might as well use this value as the "block ID" for all purposes, including the `prevBlockHash`. Computing a different hash value, excluding the nonce, would require more code, more developer time, and more computation time; would add potential for bugs in the hashing code itself; and would lead to a lot of potential confusion when people try to keep track of which part of the code uses which hash. All this in exchange for no benefit whatsoever, as far as I can tell.

> **Comments:**
> **username_0**: I'm thinking along the same lines as well, just wanted to confirm there's not something I'm missing. Thanks for helping me clarify the question.  
> **username_3**: Thanks, with your answer I finally understood what the question was about. :)  

---

### Answer by username_3 on 2016-07-27. Score: 2

Yes, you're correct. Without the nonce, we could still generate valid blocks.
However, to get a different hash we need to change the input for the hash. The input for the hash is the block header.

If there were no nonce, we would have to change something else about the block header for each try. That would only leave the timestamp or the Merkle root. Other header items are fixed.  
The timestamp is icky, because we would like it to show the actual time. So, we'd have to change the Merkle root.

The Merkle root calculated by hashing all transactions in the Merkle tree where they are listed. If we change e.g. the Coinbase or the order of the transactions in the tree, we could also gain another different combination to try. But to do so, we'd have to recalculate the Merkle root.

Rather, we put a nonce in the header directly that allows us to use the same block candidate for a number of different hashing attempts.

Hence, the nonce is used to introduce randomness **into the blockheader**. That's why it

a) has to be changed, and  
b) has to be in the blockheader. ;)

> **Comments:**
> **username_0**: This doesn't answer my question, but it's not your fault :) I rewrote the question to make my point clearer. I understand the use of the nonce. I question why it needs to be considered when calculating the `prevBlockHash` (in the next block).  
> **username_3**: I've just read your question again, and I don't understand what you're trying to ask. If the nonce were not part of what was hashed it would a) not contribute to the blockhash, b) could be arbitrary, and c) would serve no purpose. If it's not in the hashed part of the block, why would you add it in the first place. I've already covered what it's function is in my answer, though. So, I'm really confused now.  
> **username_0**: I think what's missing is that I'm referring to the `prevBlockHash` hash, whereas you refer to the proof-of-work hash calculation. All I ask is if things would break (or if you would lose a significant security property) if you were to write a `calcPrevHash` function that ignores the nonce field. I did yet another rewrite of the question to make this clearer.  

---

