# Recalculating the target and truncating

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?

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`.
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