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.

Community
  • 1
Kostas
  • 183
  • 5
  • 2
    Possible duplicate of Why change the nonce instead of just rehashing? – Jestin Jul 26 '16 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 Jul 27 '16 at 02: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 Jul 27 '16 at 02: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 Jul 27 '16 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 Jul 27 '16 at 15:25
  • @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 Jul 27 '16 at 18:10
  • 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 Jul 27 '16 at 18:11
  • @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 Jul 27 '16 at 18:28
  • @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 Jul 27 '16 at 18:31
  • Let us continue this discussion in chat. – Kostas Jul 27 '16 at 18:52

2 Answers2

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. ;)

Murch
  • 75,206
  • 34
  • 186
  • 622
  • 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 Jul 27 '16 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 Jul 27 '16 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 Jul 27 '16 at 18:27
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.

Nate Eldredge
  • 23,040
  • 3
  • 40
  • 80
  • 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 Jul 27 '16 at 18:51
  • Thanks, with your answer I finally understood what the question was about. :) – Murch Jul 27 '16 at 20:17