<p>Contrary to popular belief, the difficulty is not actually based on the number of leading zeros, that's just an oversimplification to help people understand what difficulty is. Rather the difficulty is based on the value of the block hash when interpreted as an integer. The difficulty of a block must be less than or equal to a target value. The target value is adjusted every 2016 blocks and is encoded in a compact form in every single block (it is part of the block header).</p>

<p>When a node is syncing, they start with the target value encoded in the genesis block. Every 2016 blocks, a very simple algorithm is run to calculate the target value for the next 2016 blocks. This algorithm is deterministic, so given the same set of blocks, all nodes will result in the same target value calculation. In this way, a node which has validated from the genesis block can know exactly what the target value for the nth block in the blockchain must be.</p>

CC BY-SA 3.0
2017-12-26T21:42:54.627Z
But shouldn't also the actual hash rate of the whole network be involved in the calculation? I mean the whole purpose of the target adjustments is to keep the avg. intervals between blocks constant. Or can this also be inferred from the blocks itself? Perhaps from the timestamps from  those 2016 previous founded blocks (?)
Jiri Kremser
CC BY-SA 3.0
2017-12-26T21:55:31.473Z
The hashrate is indirectly involved by the previous difficulty and the time it took to mine the 2016 blocks. Because the blocks include a timestamp, the actual hashrate at that time is both unnecessary and unknown.
Ava Chow
CC BY-SA 3.0
2017-12-26T17:11:20.083Z
2017-12-26T17:11:20.083Z
Ava Chow
<p>A full node has the capability to verify every block starting from the genesis block up until the last block. It does this by hashing the block header and checking if the hash recorded in the block is same as the computed hash.
Except, the difficulty is not fixed and the number of leading 0s needed are different in different blocks. How does the validating node know that the nth block required k 0s at the beginning of the hash?</p>

<p>eg: An attacker can build an entire blockchain with initial blocks having only 2 or 3 0s which would be easy to compute. The blocks would be valid as the computed hash will match the recorded hash.</p>

<blockchain><bitcoin-core>
While verifying previous blocks, how does the node know the difficulty at nth block?
Arun Satyarth
# While verifying previous blocks, how does the node know the difficulty at nth block?

(Asked by: username_0 on 2017-12-26)

A full node has the capability to verify every block starting from the genesis block up until the last block. It does this by hashing the block header and checking if the hash recorded in the block is same as the computed hash.
Except, the difficulty is not fixed and the number of leading 0s needed are different in different blocks. How does the validating node know that the nth block required k 0s at the beginning of the hash?

eg: An attacker can build an entire blockchain with initial blocks having only 2 or 3 0s which would be easy to compute. The blocks would be valid as the computed hash will match the recorded hash.

**Tags:** blockchain, bitcoin-core


---

## 1 answers

### Answer by username_1 on 2017-12-26. Score: 3 | Accepted answer

Contrary to popular belief, the difficulty is not actually based on the number of leading zeros, that's just an oversimplification to help people understand what difficulty is. Rather the difficulty is based on the value of the block hash when interpreted as an integer. The difficulty of a block must be less than or equal to a target value. The target value is adjusted every 2016 blocks and is encoded in a compact form in every single block (it is part of the block header).

When a node is syncing, they start with the target value encoded in the genesis block. Every 2016 blocks, a very simple algorithm is run to calculate the target value for the next 2016 blocks. This algorithm is deterministic, so given the same set of blocks, all nodes will result in the same target value calculation. In this way, a node which has validated from the genesis block can know exactly what the target value for the nth block in the blockchain must be.

> **Comments:**
> **username_2**: But shouldn't also the actual hash rate of the whole network be involved in the calculation? I mean the whole purpose of the target adjustments is to keep the avg. intervals between blocks constant. Or can this also be inferred from the blocks itself? Perhaps from the timestamps from  those 2016 previous founded blocks (?)  
> **username_1**: The hashrate is indirectly involved by the previous difficulty and the time it took to mine the 2016 blocks. Because the blocks include a timestamp, the actual hashrate at that time is both unnecessary and unknown.  

---

