4
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?
5
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).
4
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.
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 – 2018-12-03T02:14:36.577
https://github.com/bitcoin/bitcoin/blob/ed12fd83ca7999a896350197533de5e9202bc2fe/src/validation.cpp#L3071 – G. Maxwell – 2018-12-03T02:43:13.597
1Sure, 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 – 2018-12-03T02:55:54.490
1CheckProofOfWork 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 – 2018-12-03T03:02:43.073
1Ok, but it could do that without explicit nBits. – Pieter Wuille – 2018-12-03T03:04:34.783
Thank you for your answers! Very helpful for my historical understanding of nbits. – James C. – 2018-12-03T07:57:10.467
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. – 2018-12-02T20:17:22.990
Did you see https://bitcoin.stackexchange.com/questions/34155/is-it-necessary-for-blocks-to-record-the-nbits-difficulty-parameter?
– Nate Eldredge – 2018-12-02T20:30:43.273Yes 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. – 2018-12-02T21:27:34.763
1Ok. (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 – 2018-12-02T21:32:50.940
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. – 2018-12-02T21:36:06.970