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?

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.Dec 2 '18 at 21:27

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.
– Nate EldredgeDec 2 '18 at 21:32

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.Dec 2 '18 at 21:36

2 Answers
2

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

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 WuilleDec 3 '18 at 2:14

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 WuilleDec 3 '18 at 2:55

1

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. MaxwellDec 3 '18 at 3:02

1

Ok, but it could do that without explicit nBits.
– Pieter WuilleDec 3 '18 at 3:04