2

The first difficulty adjustment on the network happened at block 32256. The time for block 32255 (one block before the adjustment) is 1262152739 and the time for block 30239 (2016 blocks before the adjustment is 1261130161.

The bits for all blocks up until 32255 is 1d00ffff, which gives the target 00000000FFFF0000000000000000000000000000000000000000000000000000. For reference, I arrived at it by doing the following:

% echo "ibase=16; 00FFFF" |bc
65535
% echo "ibase=16; 1D" |bc
29
% echo "ibase=10; 65535 * 2 ^ (8 * (29 - 3))" | bc
26959535291011309493156476344723991336010898738574164086137773096960
% echo "obase=16; 26959535291011309493156476344723991336010898738574164086137773096960" |bc
FFFF0000000000000000000000000000000000000000000000000000

After arriving at the current target, I multiplied it by 1022578 (time it took to mine the blocks from 30239 to 32255) and then divided by 1209600 (2 weeks in seconds):

% echo "obase=16; 26959535291011309493156476344723991336010898738574164086137773096960 * 1022578 / 1209600" | bc
D86A528BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8B

Now here is where things get confusing for me: from my understanding, the "bits" should be generated by picking up the first three significant bytes from the target, which would be D86A52 and then add the size of the target as the prefix, which would be 1C (28 in base 10), but when I retrieve the block 32256 using Bitcoin Core, I get 1d00d86a for the bits field.

The difference between the targets would be pretty much irrelevant:

% echo "ibase=10; obase=16; 14182994 * 2 ^ (8 * (28 - 3))" | bc
D86A5200000000000000000000000000000000000000000000000000
% echo "ibase=10; obase=16; 55402 * 2 ^ (8 * (29 - 3))" | bc
D86A0000000000000000000000000000000000000000000000000000

I imagine these types of things happen because there's not a single source of truth for the target value of the network, meaning each node calculates the target independently and as such, these small differences can occur, but because the difference is so small the nodes would just have accepted it if I mined block 32256 using 1cd86a52 as the bits, but I don't know if this reasoning is correct.

Vojtěch Strnad
  • 8,292
  • 2
  • 12
  • 40
Pedro Martins Timóteo da Costa
  • 191
  • 4

1 Answers1

4

The consensus rules control exactly which difficulty a block needs to have (except on testnet3, where in certain circumstances a difficulty=1 block is allowed, in addition to the normally computed value).

In this case, 1cd86a52 is incorrect because it represents a negative number. The "compact format" used consists of 8 exponent bits, 1 sign bits, and 23 mantissa bits. The high bit of the d is the sign bit.

The rules require that the minimal exponent (which represents a power of 256, not of 2) is used for which the mantissa does not overflow.

Pieter Wuille
  • 105,497
  • 9
  • 194
  • 308