<p>You're presenting it as a choice between either allowing miners to choose the difficulty, or having it be implied by previous history.</p>

<p>In fact, neither is true. The target is determined by history (for the reasons you bring up), and the target stored inside the block header <strong>has to</strong> match the value determined by history.</p>

<p>At this point, there is no good reason for this anymore, and a design from scratch could IMO drop the nBits value from the header.</p>

<p>I don't know the original reason, but my guess is that it allowed for stronger contextless validation of block headers. Before version 0.10, Bitcoin Core did not use headers-first synchronization, and thus often did not have all parent headers available when a particular block was being received. Being able to verify that the block has valid PoW (even though the difficulty might be wrong) was a very valuable mechanism for preventing DoS attacks.</p>

CC BY-SA 3.0
2017-10-24T17:46:29.687Z
Sorry for beating the dead horse. May I know why there's no more reason to include the target in each block? Thanks
Viet
CC BY-SA 3.0
2017-10-24T19:33:59.703Z
Name me a reason why it would be needed?
Pieter Wuille
CC BY-SA 3.0
2017-10-25T09:19:03.957Z
Sorry, I'm new to this so I'm sitting on the fence and trying to understand how removing the target improves the current design. I didn't mean to challenge or question your judgement. Thanks.
Viet
CC BY-SA 3.0
2017-10-25T09:27:28.417Z
I didn't mean to offend, and didn't say it improves the design - it's just unnecessary now. You're asking why is it no longer needed. I explained why it used to be needed (contextless validation of headers) and why that doesn't apply anymore (headers-first synchronization since 0.10). The only (known) reason it was needed is gone, so it's not needed anymore.
Pieter Wuille
CC BY-SA 3.0
2018-04-03T11:08:08.353Z
Could you please reference the code which validates the target to match a correct difficulty. I can't find it. I can only see that nodes check the range of the target value. https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L74
Dieter Pisarewski
CC BY-SA 4.0
2018-10-17T01:45:16.290Z
@DieterPisarewski The code should be in the [`ContextualCheckBlockHeader` function](https://github.com/bitcoin/bitcoin/blob/v0.17.0/src/validation.cpp#L3235-L3236). The line you gave above seems to be used in the "contextless" block check.
yaobin
CC BY-SA 3.0
2016-04-23T07:50:16.730Z
2016-04-23T07:50:16.730Z
Pieter Wuille
<p>Currently, <a href="https://en.bitcoin.it/wiki/Difficulty#How_is_difficulty_stored_in_blocks.3F">target is stored in each block</a>. Why is that? Why it is not simply computed by each client based on the previous timestamps from previous blocks? Why it has to be stored within the block?</p>

<p>In other words, doesn't allowing miner to choose the target remove that it is exponentially harder to create a new block? Other miners might have to mine 256 consequent blocks, but I have only to be lucky once and get one block with 8 more zeroes to replace those 256 blocks. While it is less probable, it grows linearly (256x less probable) and not exponentially.</p>

<difficulty>
Why is target stored in the block at all?
Mitar
# Why is target stored in the block at all?

(Asked by: username_0 on 2016-04-23)

Currently, [target is stored in each block](https://en.bitcoin.it/wiki/Difficulty#How_is_difficulty_stored_in_blocks.3F). Why is that? Why it is not simply computed by each client based on the previous timestamps from previous blocks? Why it has to be stored within the block?

In other words, doesn't allowing miner to choose the target remove that it is exponentially harder to create a new block? Other miners might have to mine 256 consequent blocks, but I have only to be lucky once and get one block with 8 more zeroes to replace those 256 blocks. While it is less probable, it grows linearly (256x less probable) and not exponentially.

**Tags:** difficulty


---

## 1 answers

### Answer by username_1 on 2016-04-23. Score: 9 | Accepted answer

You're presenting it as a choice between either allowing miners to choose the difficulty, or having it be implied by previous history.

In fact, neither is true. The target is determined by history (for the reasons you bring up), and the target stored inside the block header **has to** match the value determined by history.

At this point, there is no good reason for this anymore, and a design from scratch could IMO drop the nBits value from the header.

I don't know the original reason, but my guess is that it allowed for stronger contextless validation of block headers. Before version 0.10, Bitcoin Core did not use headers-first synchronization, and thus often did not have all parent headers available when a particular block was being received. Being able to verify that the block has valid PoW (even though the difficulty might be wrong) was a very valuable mechanism for preventing DoS attacks.

> **Comments:**
> **username_2**: Sorry for beating the dead horse. May I know why there's no more reason to include the target in each block? Thanks  
> **username_1**: Name me a reason why it would be needed?  
> **username_2**: Sorry, I'm new to this so I'm sitting on the fence and trying to understand how removing the target improves the current design. I didn't mean to challenge or question your judgement. Thanks.  
> **username_1**: I didn't mean to offend, and didn't say it improves the design - it's just unnecessary now. You're asking why is it no longer needed. I explained why it used to be needed (contextless validation of headers) and why that doesn't apply anymore (headers-first synchronization since 0.10). The only (known) reason it was needed is gone, so it's not needed anymore.  
> **username_3**: Could you please reference the code which validates the target to match a correct difficulty. I can't find it. I can only see that nodes check the range of the target value. https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L74  
> **username_4**: @username_3 The code should be in the [`ContextualCheckBlockHeader` function](https://github.com/bitcoin/bitcoin/blob/v0.17.0/src/validation.cpp#L3235-L3236). The line you gave above seems to be used in the "contextless" block check.  

---

