While verifying previous blocks, how does the node know the difficulty at nth block?

0

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.

Arun Satyarth

Posted 2017-12-26T16:09:07.443

Reputation: 135

Answers

3

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.

Andrew Chow

Posted 2017-12-26T16:09:07.443

Reputation: 40 910

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 – 2017-12-26T21:42:54.627

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. – Andrew Chow – 2017-12-26T21:55:31.473

Asked: 2017-12-26T16:09:07.443

Viewed: 78 times

Active: 2017-12-26T21:42:28.477