How is the target section of a block header calculated?

Question

I've been poking around https://en.bitcoin.it/wiki/Target and I've found the current target, but I can't seem to find how it's generated. It's supposedly generated when the difficulty is adjusted, as stated here: https://en.bitcoin.it/wiki/Block_hashing_algorithm, but what exactly is the algorithm for generating the target? If someone could show me some psuedocode that would be great.

Answer 1

The target section of the block header is called nBits in the code. nBits is a 32-bit compact encoding of a 256-bit target threshold. It works like scientific notation, except that it uses base-256 instead of base-10. For example, if nBits is equal to 0x181b8330, you would calculate it like this:

Or, more simply, you'd use the same shorthand you use with regular scientific notation:

At a re-target point (every 2,016th block), Bitcoin Core adjusts nBits according to the rules described in this answer except that it is important to note that when difficulty changes by p percent, nBits is adjusted by the inverse (-p percent). That's because a lower target is harder to reach the way Bitcoin is implemented.

It's also important to note that you can't just adjust the exponent part of nBits in the obvious way because when Satoshi first wrote the code, he inherited from a signed type---so extra care must be taken not to create a negative nBits value. The Bitcoin.org Developer Reference has more details (but be careful, I haven't yet had an expert review that section).

Answer 2

I am not sure how this is actually implemented in the code, but you can approximate the new target (nBits) value with data from the prior 2016th block. Note that as described above nBits is the 32-bit compact encoding of the 256-bit target value.

Here shows the new difficulty (d_new) as:

d_new = d_old * 2 weeks / t_old

where 'old' signifies the previous 2016 blocks, and t_old is the time it took to find those previous 2016 blocks.

Here shows d_new from genesis block values as:

d_new = nBits_genesis / nBits_new, and similarly
d_old = nBits_genesis / nBits_old

Combining these 3 equations results in

nBits_new = (t_old / 2 weeks) * nBits_old

So knowing the timestamps of the new block and the prior 2016th block, and the target of the prior 2016th block, we can approximate the new target value. For example:

block 703584
nBits = 0x170e2632 = 927282 * 256^(23-3)
timestamp 2021-10-04 16:35:19

block 701568 (the prior 2016th block)
nBits = 0x170ed0eb = 970987 * 256^(23-3)
timestamp 2021-09-21 07:34:36

So
t_old = 13 days 9h 33s = 1155633s and 2 weeks = 1209600s
nBits_old = 970987 * 256^(23-3)
Thus the new target is approximately
1155633/1209600 * 256^20
= 0.955384424 * 970987 * 256^20 = 927666 * 256^20

Converting to the compact 32-bit format we get nBits_new ~ 0x170e27b2

The mantissa 927666 (0x0e27b2) is close to the actual mantissa 927282 (0x0e2632). It's a reasonable approximation but obviously the absolute values of the targets are quite different because it's base-256. Error here is likely due to rounding to the nearest second in the timestamps. Even though this is not the explicit calculation done in the code, I hope that it helps in general understanding, including the references here and here.