1

The target on the block at height 32,255 was:

0x00000000ffff0000000000000000000000000000000000000000000000000000

After the adjustment, the target on the following block at height 32,256 was:

0x00000000d86a0000000000000000000000000000000000000000000000000000

The time between block 30,240 and block 30,255 was 1022578 seconds. If we divide this by the expected time over 2016 blocks we get a ratio of:

1022578 / 1209600 = 0.84538525132275

If we multiply the previous target by this ratio to get the new target, we get:

0x00000000ffff0000000000000000000000000000000000000000000000000000 * 0.84538525132275 =
0x00000000d86a528bc8bc90000000000000000000000000000000000000000000

What are the rules for truncating this result to get the target as stored the in the block header?

I understand that the target is converted to bits and loses some precision, but why is it that we're only including the first two significant bytes of d86a when we could include the three bytes of d86a52 in the bits field?

1 Answer 1

2

When encoding from target to bits, in the custom uint8 encoding used in bitcoin, bit 0x00800000 denotes the sign.

So any value greater than 0x7fffff would actually be considered a negative number.

Therefore, 0x00d86a must be used when encoding the target to bits instead of 0xd86a52.


Pieter Wuille's answer here: Why 1D00FFFF and not 1CFFFFFF as target in genesis block

I believe the actual code itself can be found in the GetCompact() method in https://github.com/bitcoin/bitcoin/blob/master/src/arith_uint256.cpp

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.