11

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?

Improve this question
5
  • 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.
    Dec 2, 2018 at 20:17
  • Did you see bitcoin.stackexchange.com/questions/34155/…?
    – Nate Eldredge
    Dec 2, 2018 at 20:30
  • 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, 2018 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 Eldredge
    Dec 2, 2018 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, 2018 at 21:36

2 Answers 2

Reset to default
12

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

Improve this answer
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.

Improve this answer
6
  • 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.
    – Pieter Wuille
    Dec 3, 2018 at 2:14
  • 1
    github.com/bitcoin/bitcoin/blob/…
    – G. Maxwell
    Dec 3, 2018 at 2:43
  • 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.
    – Pieter Wuille
    Dec 3, 2018 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. Maxwell
    Dec 3, 2018 at 3:02
  • 2
    Ok, but it could do that without explicit nBits.
    – Pieter Wuille
    Dec 3, 2018 at 3:04

Your Answer

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

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