1

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? 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.

Improve this question
10
  • 2
    Possible duplicate of Why change the nonce instead of just rehashing?
    – Jestin
    Commented Jul 26, 2016 at 19:39
  • 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
    Commented Jul 27, 2016 at 2:09
  • 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? 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
    Commented Jul 27, 2016 at 2:24
  • @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
    Commented Jul 27, 2016 at 14:39
  • @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
    Commented Jul 27, 2016 at 15:25

2 Answers 2

Reset to default
2

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.

Improve this answer
2
  • 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
    Commented Jul 27, 2016 at 18:51
  • Thanks, with your answer I finally understood what the question was about. :)
    – Murch ♦
    Commented Jul 27, 2016 at 20:17
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. ;)

Improve this answer
3
  • 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
    Commented Jul 27, 2016 at 14:48
  • 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 ♦
    Commented Jul 27, 2016 at 15:54
  • 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
    Commented Jul 27, 2016 at 18:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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