<p>Directly committing to the nbits allows you to determine how much work was used to produce the header statelessly before looking for (or fetching) information about prior headers.</p>

<p>This can help fend of DOS attacks sending junk headers to force you to do work determining or fetching their ancestors.</p>

CC BY-SA 4.0
2018-12-03T02:14:36.577Z
A heuristic for DoS prevention that made use of this existed in Bitcoin Core before the introduction of headers-first synchronization. Right now, I don't think it's used for anything in Core.
Pieter Wuille
CC BY-SA 4.0
2018-12-03T02:43:13.597Z
https://github.com/bitcoin/bitcoin/blob/ed12fd83ca7999a896350197533de5e9202bc2fe/src/validation.cpp#L3071
G. Maxwell
CC BY-SA 4.0
2018-12-03T02:55:54.490Z
Sure, it lets us check whether the PoW matches the difficulty of headers without context. But an attacker could claim any value at that point, and we'd only detect it in the contextual validation. I don't think any meaningful attack is prevented by this.
Pieter Wuille
CC BY-SA 4.0
2018-12-03T03:02:43.073Z
CheckProofOfWork also checks nbits is at least the minimum. It could check 'apparent work' instead,  which would be almost as good, but you could for example flood with "lucky shares" from a hypoethical 1 block per second diff=0.1 altcoin. So it is different, even if not in an important way.
G. Maxwell
CC BY-SA 4.0
2018-12-03T03:04:34.783Z
Ok, but it could do that without explicit nBits.
Pieter Wuille
CC BY-SA 4.0
2018-12-03T07:57:10.467Z
Thank you for your answers! Very helpful for my historical understanding of nbits.
James C.
CC BY-SA 4.0
2018-12-03T00:57:42.120Z
2018-12-03T00:57:42.120Z
G. Maxwell
<p>They aren't really necessary. The reason that they are included can only be known by Satoshi, and AFAIK, he did not state why he chose to include nBits in the block header (or many other things that are just arbitrary). This is one of the many things that Satoshi chose to do and no one really knows why. It remains in the block header today because removing it would require a hard fork and there really is not much benefit to be gained by removing it.</p>

<p>The nBits field can be useful, and it likely was included as a convenience sort of thing. Instead of having to have the full chain history in order to know the current difficulty, you can instead look at the nBits. But that is just speculation, and full nodes don't use the nBits to determine the current difficulty (except those of the genesis block).</p>

CC BY-SA 4.0
2018-12-02T23:07:47.977Z
2018-12-02T23:07:47.977Z
Ava Chow
<p>Difficulty or target is implied by chain history, so why does it need to be explicit in the header? I suppose it exposes miner-intended-difficulty, but I don't see why that would be relevant without chain context. </p>

<p>So it seemingly represents redundant data in the header, unless there are any historical reasons for this design choice?</p>

CC BY-SA 4.0
2018-12-02T20:17:22.990Z
So there are other SE questions/answers which imply that this was historical. But, what was the purpose of header bits to begin with? Was it an oversight?
James C.
CC BY-SA 4.0
2018-12-02T20:30:43.273Z
Did you see https://bitcoin.stackexchange.com/questions/34155/is-it-necessary-for-blocks-to-record-the-nbits-difficulty-parameter?
Nate Eldredge
CC BY-SA 4.0
2018-12-02T21:27:34.763Z
Yes thank you. Still confuses me. SPV still needs to validate header chain from genesis, even if not all headers are stored, so that difficulty can be computed from header chain history. Bits not required.
James C.
CC BY-SA 4.0
2018-12-02T21:32:50.940Z
Ok.  (In general, it's nice if you can include links to relevant questions that you've already seen, to avoid *redundant* suggestions :-).  I agree that I also can't see any reason why it's particularly necessary.  It's quite possible it was just for convenience / laziness on Satoshi's part, as it was easier than having the node store the data somewhere else, or else he simply didn't think it all the way through.  Sadly we can't ask him.
Nate Eldredge
CC BY-SA 4.0
2018-12-02T21:36:06.970Z
Thank you. I meant your link was new to me, not that I had already viewed it, it was useful! I wasn’t clear about that.
James C.
<block><difficulty><block-header><difficulty-retargetting>
Why are block header bits necessary? (Valid difficulty is already implied by chain history)
James C.
# Why are block header bits necessary? (Valid difficulty is already implied by chain history)

(Asked by: username_0 on 2018-12-02)

Difficulty or target is implied by chain history, so why does it need to be explicit in the header? I suppose it exposes miner-intended-difficulty, but I don't see why that would be relevant without chain context.

So it seemingly represents redundant data in the header, unless there are any historical reasons for this design choice?

**Tags:** block, difficulty, block-header, difficulty-retargetting

> **Comments:**
> **username_0**: So there are other SE questions/answers which imply that this was historical. But, what was the purpose of header bits to begin with? Was it an oversight?  
> **username_1**: Did you see https://bitcoin.stackexchange.com/questions/34155/is-it-necessary-for-blocks-to-record-the-nbits-difficulty-parameter?  
> **username_0**: Yes thank you. Still confuses me. SPV still needs to validate header chain from genesis, even if not all headers are stored, so that difficulty can be computed from header chain history. Bits not required.  
> **username_1**: Ok.  (In general, it's nice if you can include links to relevant questions that you've already seen, to avoid *redundant* suggestions :-).  I agree that I also can't see any reason why it's particularly necessary.  It's quite possible it was just for convenience / laziness on Satoshi's part, as it was easier than having the node store the data somewhere else, or else he simply didn't think it all the way through.  Sadly we can't ask him.  
> **username_0**: Thank you. I meant your link was new to me, not that I had already viewed it, it was useful! I wasn’t clear about that.  

---

## 2 answers

### Answer by username_4 on 2018-12-02. Score: 12 | Accepted answer

They aren't really necessary. The reason that they are included can only be known by Satoshi, and AFAIK, he did not state why he chose to include nBits in the block header (or many other things that are just arbitrary). This is one of the many things that Satoshi chose to do and no one really knows why. It remains in the block header today because removing it would require a hard fork and there really is not much benefit to be gained by removing it.

The nBits field can be useful, and it likely was included as a convenience sort of thing. Instead of having to have the full chain history in order to know the current difficulty, you can instead look at the nBits. But that is just speculation, and full nodes don't use the nBits to determine the current difficulty (except those of the genesis block).


---

### Answer by username_2 on 2018-12-03. Score: 5

Directly committing to the nbits allows you to determine how much work was used to produce the header statelessly before looking for (or fetching) information about prior headers.

This can help fend of DOS attacks sending junk headers to force you to do work determining or fetching their ancestors.

> **Comments:**
> **username_3**: A heuristic for DoS prevention that made use of this existed in Bitcoin Core before the introduction of headers-first synchronization. Right now, I don't think it's used for anything in Core.  
> **username_2**: https://github.com/bitcoin/bitcoin/blob/ed12fd83ca7999a896350197533de5e9202bc2fe/src/validation.cpp#L3071  
> **username_3**: Sure, it lets us check whether the PoW matches the difficulty of headers without context. But an attacker could claim any value at that point, and we'd only detect it in the contextual validation. I don't think any meaningful attack is prevented by this.  
> **username_2**: CheckProofOfWork also checks nbits is at least the minimum. It could check 'apparent work' instead,  which would be almost as good, but you could for example flood with "lucky shares" from a hypoethical 1 block per second diff=0.1 altcoin. So it is different, even if not in an important way.  
> **username_3**: Ok, but it could do that without explicit nBits.  
> **username_0**: Thank you for your answers! Very helpful for my historical understanding of nbits.  

---

