<p>The consensus rules control <em>exactly</em> 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).</p>
<p>In this case, <code>1cd86a52</code> is incorrect because it represents a negative number. The &quot;compact format&quot; used consists of 8 exponent bits, 1 sign bits, and 23 mantissa bits. The high bit of the <code>d</code> is the sign bit.</p>
<p>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.</p>

CC BY-SA 4.0
2023-11-11T13:31:35.340Z
Thank you for the answer. Okay, so I understand that `1cd86a52` is invalid because it represents a negative number, but then how do I get to `1d00d86a`?
Pedro Martins Timóteo da Costa
CC BY-SA 4.0
2023-11-11T13:37:08.627Z
I think I understand it by looking at https://bitcoin.stackexchange.com/a/2926/139641. If I understood it correctly, because the first digit of the target I calculated is higher than `0x7f`, I should prepend a zero digit and then the compact form would be `1d00d86a`
Pedro Martins Timóteo da Costa
CC BY-SA 4.0
2023-11-11T13:37:16.180Z
It's the mantissa you end up with by picking the next higher exponent.
Pieter Wuille
CC BY-SA 4.0
2023-11-11T13:26:39.500Z
2023-11-11T13:26:39.500Z
Pieter Wuille
<p>The first difficulty adjustment on the network happened at block <code>32256</code>. The time for block <code>32255</code> (one block before the adjustment) is <code>1262152739</code> and the time for block <code>30239</code> (2016 blocks before the adjustment is <code>1261130161</code>.</p>
<p>The <code>bits</code> for all blocks up until <code>32255</code> is <code>1d00ffff</code>, which gives the target <code>00000000FFFF0000000000000000000000000000000000000000000000000000</code>. For reference, I arrived at it by doing the following:</p>
<pre><code>% echo &quot;ibase=16; 00FFFF&quot; |bc
65535
% echo &quot;ibase=16; 1D&quot; |bc
29
% echo &quot;ibase=10; 65535 * 2 ^ (8 * (29 - 3))&quot; | bc
26959535291011309493156476344723991336010898738574164086137773096960
% echo &quot;obase=16; 26959535291011309493156476344723991336010898738574164086137773096960&quot; |bc
FFFF0000000000000000000000000000000000000000000000000000
</code></pre>
<p>After arriving at the current target, I multiplied it by <code>1022578</code> (time it took to mine the blocks from <code>30239</code> to <code>32255</code>) and then divided by <code>1209600</code> (2 weeks in seconds):</p>
<pre><code>% echo &quot;obase=16; 26959535291011309493156476344723991336010898738574164086137773096960 * 1022578 / 1209600&quot; | bc
D86A528BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8BC8B
</code></pre>
<p>Now here is where things get confusing for me: from my understanding, the &quot;bits&quot; should be generated by picking up the first three significant bytes from the target, which would be <code>D86A52</code> and then add the size of the target as the prefix, which would be <code>1C</code> (<code>28</code> in base 10), but
when I retrieve the block <code>32256</code> using Bitcoin Core, I get <code>1d00d86a</code> for the <code>bits</code> field.</p>
<p>The difference between the targets would be pretty much irrelevant:</p>
<pre><code>% echo &quot;ibase=10; obase=16; 14182994 * 2 ^ (8 * (28 - 3))&quot; | bc
D86A5200000000000000000000000000000000000000000000000000
% echo &quot;ibase=10; obase=16; 55402 * 2 ^ (8 * (29 - 3))&quot; | bc
D86A0000000000000000000000000000000000000000000000000000
</code></pre>
<p>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 <code>32256</code> using <code>1cd86a52</code> as the <code>bits</code>, but I don't know if this reasoning is correct.</p>

<mining-theory><difficulty><difficulty-retargetting>
Would it work just fine if "bits" was set to "1cd86a52" instead of "1d00d86a" at the first difficulty adjustment?
Pedro Martins Timóteo da Costa
# Would it work just fine if "bits" was set to "1cd86a52" instead of "1d00d86a" at the first difficulty adjustment?

(Asked by: username_0 on 2023-11-11)

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.

**Tags:** mining-theory, difficulty, difficulty-retargetting


---

## 1 answers

### Answer by username_1 on 2023-11-11. Score: 4 | Accepted answer

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.

> **Comments:**
> **username_0**: Thank you for the answer. Okay, so I understand that `1cd86a52` is invalid because it represents a negative number, but then how do I get to `1d00d86a`?  
> **username_0**: I think I understand it by looking at https://bitcoin.stackexchange.com/a/2926/139641. If I understood it correctly, because the first digit of the target I calculated is higher than `0x7f`, I should prepend a zero digit and then the compact form would be `1d00d86a`  
> **username_1**: It's the mantissa you end up with by picking the next higher exponent.  

---

