<p>Meni's answer is good. I just want to give some practical detail method about difficulty calculation, perhaps helpful for future views of this question's answer.</p>
<p>Let's take a look at Satoshi's genesis block header (part of related info):</p>
<pre><code>$ bitcoin-cli getblockhash 0
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

$ bitcoin-cli getblockheader 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
{
  ...
  &quot;height&quot;: 0,
  ...
  &quot;bits&quot;: &quot;1d00ffff&quot;,
  &quot;difficulty&quot;: 1,
  ...
}
</code></pre>
<p>As we can see above, the genesis block has a '1' difficulty and '1d00ffff' bits. The <a href="https://bitcoin.stackexchange.com/questions/23912/how-is-the-target-section-of-a-block-header-calculated">bitcoin bits</a> means the 'target' hash value, the new generated block must meet a condition: block header's double SHA-256 hash value must less than this 'target' value.</p>
<p>The '1d00ffff' bits value in genesis block means the 'target' value:</p>
<pre><code>[0x00000000,0xffff,{0x00..0x00}]
                   {0x00..0x00} at above has 26 bytes 0x00.
</code></pre>
<p>Then, to find a new block, you must search that 32 bits nNonce value (and nTimes and the hashMerkleRoot also) until the block hash value has 4 bytes zero leading.
By the way, the nNonce is one of the fields in block header structure:</p>
<pre class="lang-c prettyprint-override"><code>struct header_structure{            // BYTES   NAME
    uint32_t nVersion;              // 4       version
    uint8_t hashPrevBlock[32];      // 32      previous block header hash
    uint8_t hashMerkleRoot[32];     // 32      merkle root hash
    uint32_t nTime;                 // 4       time
    uint32_t nBits;                 // 4       target
    uint32_t nNonce;                // 4       nonce
};
</code></pre>
<p>Because SHA-256 algorithm (as well as any cryptographically secure hash algorithm) produces output that will appear <a href="https://crypto.stackexchange.com/questions/12822/are-the-sha-family-hash-outputs-practically-random">like an uniformly random sequence</a>, the practical 'trial and error' method is the only way to find a new block to meet the condition. The probability to find a block with the 4 bytes zero leading hash value is 1/(2^32), that means the average 'trial and error&quot; numbers are exactly 2^32 (i.e. 4G).</p>
<p>For human easy understanding about this 'target' hash value, We define the term 'difficulty', which means the average 'trial and error&quot; numbers to find a block to meet the 'target' condition. And we define the 'difficulty' unit:
1 'difficulty' = 4G hashes</p>
<p>Then, till today, the bitcoin blockchain height reach 501509, let's take a look at its header:</p>
<pre><code>$ bitcoin-cli getblockheader 0000000000000000006c5532f4fd9ee03e07f94df165c556b89c495e97680147
{
  ...
  &quot;height&quot;: 501509,
  ...
  &quot;bits&quot;: &quot;18009645&quot;,
  &quot;difficulty&quot;: 1873105475221.611,
  ...
}
</code></pre>
<p>The block 501509's bits = 0x18009645, it's the compact format of 256 bits integer, its 256 bits format is:</p>
<pre><code>[0x00000000,0x00000000,0x009645,{0x00..0x00}]
                                {0x00..0x00} at above has 21 bytes 0x00.
that is  0x009645 * (256 ^ 21） 
The genesis block's target is  ( 0x00ffff * 256 ^ 26 ）which is the difficulty unit '1.0'.
So, the difficulty 
= (0x00ffff * 256 ^ 26）/ (0x009645 * 256 ^ 21)
= 65535/38469 * (256^5)
= 1.703579505575918 * 2^40
= 1873105475221.611
</code></pre>
<p>So far, you have all the detail about how to calculate the 'difficulty'.
In some cases, we also use the simple format <strong>1.7T</strong> to say the difficulty, in above example：</p>
<pre><code>(1.703579505575918 * 2^40) = 1.703579505575918T
1T = 2^40 = 1024^4
</code></pre>

CC BY-SA 4.0
2018-08-06T18:31:37.997Z
1d is 29 in Dec(not 26). SHS is SHA
Boris Ivanov
CC BY-SA 4.0
2018-08-07T08:13:25.227Z
thanks @BorisIvanov, the typo error `SHS` has been fixed. But `1d` indeed means 26 bytes zero tail instead of 29, please read the example detail showed above.
gary
CC BY-SA 4.0
2018-08-07T15:29:10.150Z
ah yeah. Significand
Boris Ivanov
CC BY-SA 4.0
2024-01-29T14:00:00.627Z
Finally, one person that really explain the calculation, thank you very much
RafaelJan
CC BY-SA 4.0
2017-12-29T04:30:57.010Z
2023-08-21T15:40:28.203Z
2023-08-21T15:40:28.203Z
gary
<p>I would like to give my 2 cents here, by expliciting the relationship between the probability of mining a block given the current target <code>t</code> and the corresponding difficulty <code>d</code> as it is calculated in bitcoin core.</p>

<p>So cryptographic hash functions are idealized by the random oracle abstraction [<a href="https://en.wikipedia.org/wiki/Random_oracle]" rel="noreferrer">https://en.wikipedia.org/wiki/Random_oracle]</a>. We can therefore model the output of the <code>doubleSHA256</code> hash function used in PoW as a uniform variable in the space <code>{0,1}^256</code>, i.e. arrays of 256 bits. Thus the probability of a single hash <code>h</code> being a valid hash is:</p>

<pre><code>p = P(h &lt; t) = t /( 2^{256} - 1 )
</code></pre>

<p>On the other hand <code>d</code> is calculated as follows, just as @gary explained before only transformed into decimals:</p>

<pre><code>d = ( (2^{16} - 1) * 2^{8*26} ) / t = ( (2^{16} -1) * 2^{208} ) / t
</code></pre>

<p>The implementation is in [<a href="https://github.com/bitcoin/bitcoin/blob/master/src/rpc/blockchain.cpp]" rel="noreferrer">https://github.com/bitcoin/bitcoin/blob/master/src/rpc/blockchain.cpp]</a>, line 60, function <code>GetDifficulty</code>. Actually if someone can explain how exactly the code maps to the formula above, that would be helpful. Combining those two formulas we obtain:</p>

<pre><code>d = ( (2^{16} -1) * 2^{208} ) / ( p * (2^{256} - 1) ) ~ 2^{-32} / p
</code></pre>

<p>Analyzing this last expression the difficulty is the ratio between the probability of obtaining a hash lower than <code>2^{224}</code> (which is the lowest decimal number that has a binary representation using 256 bits starting with 32 zero bits) and the probability of obtaining a valid hash based on the current target <code>t</code>. This is a direct implication of defining, in the genesis block, as <strong>difficulty 1</strong> the one associated to the hexadecimal target <strong>0x1d00ffff</strong>, expressed in what I think is called the 32-bit compact form for 256-bit numbers.</p>

<p>A nice question I believe is why this specific compact form was chosen for representing the target.</p>

CC BY-SA 4.0
2019-01-27T14:48:54.383Z
Upvoted! The compact form provides 3 most significant bytes for the target, in the min difficulty the 3 most significant bytes are 00ffff.
James C.
CC BY-SA 4.0
2019-01-27T14:19:10.440Z
2019-01-27T14:19:10.440Z
giancarloGiuffra
<p>The <a href="https://bitcoin.stackexchange.com/questions/8806/what-is-difficulty-and-how-it-relates-to-target">Bitcoin difficulty</a> started at 1 (and can never go below that). Then for every 2016 blocks that are found, the timestamps of the blocks are compared to find out how much time it took to find 2016 blocks, call it T. We want 2016 blocks to take 2 weeks, so if T is different, we multiply the difficulty by (2 weeks / T) - this way, if the hashrate continues the way it was, it will now take 2 weeks to find 2016 blocks.</p>

<p>For example, if it took only 10 days it means difficulty is too low and thus will be increased by 40%.</p>

<p>The difficulty can increase or decrease depending on whether it took less or more than 2 weeks to find 2016 blocks. Generally, the difficulty will decrease after the network hashrate drops.</p>

<p>If the correction factor is greater than 4 (or less than 1/4), then 4 or 1/4 are used instead, to prevent the change to be too abrupt.</p>

<p>There is a bug in the implementation, due to which the calculation is based on the time to find the last 2015 blocks rather than 2016. Fixing it would require a hard fork and is thus deferred for now.</p>

<p>It is possible to give a rough estimate for the next difficulty change, based on the time to find the recent blocks. Nobody can make longer-term predictions for the future difficulty reliably, but anyone is free to speculate based on exchange rate trends, Moore's law and other hardware advances.</p>

CC BY-SA 3.0
2013-06-11T22:23:06.347Z
Is that bug still there? Shouldn't there be a GitHub issue for that so that people can keep track of the status... With such bugs in the protocol, it will be hard for the Bitcoin ecosystem to move away from the situation in which the Satoshi client devs set all the rules.
Steven Roose
CC BY-SA 3.0
2013-06-12T15:19:32.937Z
@StevenRoose: AFAIK it is, but I will leave it to people who are more involved with the core code to comment... This is adequate for a separate SE question.
Meni Rosenfeld
CC BY-SA 3.0
2014-03-14T18:35:56.613Z
Good answer, but one small, but capital point is eluded: how do the nodes in the network agree on what is the difficulty ?
deadalnix
CC BY-SA 3.0
2014-03-15T21:36:15.107Z
@deadalnix: The difficulty of a block is a deterministic calculation based on the data of the previous blocks. All nodes independently do the same calculation and get the same result.
Meni Rosenfeld
CC BY-SA 3.0
2014-03-16T01:18:52.630Z
@MeniRosenfeld thank you for that answer. But to me, it just move the problem around. As I understand you answer, the computation is made from the timestamp available in the blocks. But then, how does a p2p network agree on the timestamp ?
deadalnix
CC BY-SA 3.0
2014-03-16T16:10:23.307Z
@deadalnix: The timestamp is a part of the block, which means that whoever found the block decides what to put in it. The timestamp must be no sooner than the median of the past 11 blocks. Also, if a node receives a block with a timestamp more than 2 hours in the future it will reject it and not propagate it.
Meni Rosenfeld
CC BY-SA 3.0
2014-07-18T18:25:45.933Z
References to the Bitcoin specifications or codebase would be much appreciated.  Revising your answer is strongly preferred over shoving stuff into the comments.
Indolering
CC BY-SA 3.0
2014-07-20T04:38:26.167Z
@Indolering: The stuff in the comments is not part of the core answer. They are replies to specific followup questions.
Meni Rosenfeld
CC BY-SA 3.0
2014-08-05T03:08:13.183Z
@Meni, so if I want to calculate the round completion should I do CURRENT_BLOCK_COUNT_IN_THIS_ROUND/2015 instead of CURRENT_BLOCK_COUNT_IN_THIS_ROUND/2016 ???
mixdev
CC BY-SA 3.0
2014-08-05T09:35:28.060Z
@mixdev: The "round" (difficulty retarget) is done every 2016 blocks. But the recalculation currently is not prev_target*TIME_FOR_LAST_2016_Blocks/1209600, it's prev_target*TIME_FOR_LAST_2015_Blocks/1209600.
Meni Rosenfeld
CC BY-SA 4.0
2018-06-05T08:51:21.977Z
So this basically means that errors will add up as every time only the last epoch time is considered? This would mean that stating in 2140 the last bitcoin will be mined is wrong as it could be years or even decades before that.
tobi
CC BY-SA 4.0
2018-06-05T09:50:02.670Z
@tobi: The off-by-one bug is responsible for blocks being found 0.05% slower on average than the "official" 2016 per two weeks. There is a separate issue that causes another 0.05% slowdown. Together they amount to only 1 month slowdown over a century. However, there is a separate effect that causes blocks to be found faster due to the increase in hashrate. This is more significant and the last coin will be mined probably 1-2 years too early because of this.
Meni Rosenfeld
CC BY-SA 4.0
2018-06-05T09:53:02.120Z
@tobi: The total amount of speedup due to hashrate increase can be calculated as roughly log (difficulty) * 2 weeks. This is the main reason block halving parties are at a different date each time - November in 2012, July in 2016 etc.
Meni Rosenfeld
CC BY-SA 4.0
2018-06-05T12:24:46.420Z
yes I was referring to the speedup due to increasing hashrate and not the 2015 blocks bug
tobi
CC BY-SA 4.0
2018-06-05T13:15:37.803Z
@tobi: Oh ok. Previous comments were about the bug, and "errors" hinted that it's the bug, so I assumed we're talking about that. So, yes. If we assume that around 2140 the hashrate will be around *1B what it is now, the schedule will be ahead by 96 weeks, or almost two years. But there is yet another effect - a delay caused by the fact that in the beginning, the difficulty was 1 even though the hashrate wasn't enough to justify it.
Meni Rosenfeld
CC BY-SA 3.0
2012-12-18T19:43:54.000Z
2016-04-21T12:22:27.020Z
2017-04-13T12:47:36.647Z
Meni Rosenfeld
<p>Can anyone explain me in the plain English how difficulty is calculated. I have a very approximate understanding that it is calculated based on the amount of hash power in all the bitcoin community over a specific period of time. But this is very vague.</p>

<p>Also I understand it can change very rapidly. Can it only increase? Is there any formula how to calculate it or predict it?</p>

<p>Thanks for a detailed answer, Meni Rosenfeld. Just to make sure I got everything right. I am summing up all the time, it took to generate the last 2016 blocks. And then apply the formula. </p>

CC BY-SA 3.0
2012-12-19T14:18:30.203Z
I think follow up questions are better as comments to the answer. Basically yes, but no summing is actually needed - you can just take the timestamps of the last block and of the one 2016 blocks before, and subtract.
Meni Rosenfeld
<difficulty><difficulty-retargetting>
How is difficulty calculated?
Salvador Dali
# How is difficulty calculated?

(Asked by: username_0 on 2012-12-18)

Can anyone explain me in the plain English how difficulty is calculated. I have a very approximate understanding that it is calculated based on the amount of hash power in all the bitcoin community over a specific period of time. But this is very vague.

Also I understand it can change very rapidly. Can it only increase? Is there any formula how to calculate it or predict it?

Thanks for a detailed answer, username_1 username_1. Just to make sure I got everything right. I am summing up all the time, it took to generate the last 2016 blocks. And then apply the formula.

**Tags:** difficulty, difficulty-retargetting

> **Comments:**
> **username_1**: I think follow up questions are better as comments to the answer. Basically yes, but no summing is actually needed - you can just take the timestamps of the last block and of the one 2016 blocks before, and subtract.  

---

## 3 answers

### Answer by username_1 on 2012-12-18. Score: 92 | Accepted answer

The [Bitcoin difficulty](https://bitcoin.stackexchange.com/questions/8806/what-is-difficulty-and-how-it-relates-to-target) started at 1 (and can never go below that). Then for every 2016 blocks that are found, the timestamps of the blocks are compared to find out how much time it took to find 2016 blocks, call it T. We want 2016 blocks to take 2 weeks, so if T is different, we multiply the difficulty by (2 weeks / T) - this way, if the hashrate continues the way it was, it will now take 2 weeks to find 2016 blocks.

For example, if it took only 10 days it means difficulty is too low and thus will be increased by 40%.

The difficulty can increase or decrease depending on whether it took less or more than 2 weeks to find 2016 blocks. Generally, the difficulty will decrease after the network hashrate drops.

If the correction factor is greater than 4 (or less than 1/4), then 4 or 1/4 are used instead, to prevent the change to be too abrupt.

There is a bug in the implementation, due to which the calculation is based on the time to find the last 2015 blocks rather than 2016. Fixing it would require a hard fork and is thus deferred for now.

It is possible to give a rough estimate for the next difficulty change, based on the time to find the recent blocks. Nobody can make longer-term predictions for the future difficulty reliably, but anyone is free to speculate based on exchange rate trends, Moore's law and other hardware advances.

> **Comments:**
> **username_7**: Is that bug still there? Shouldn't there be a GitHub issue for that so that people can keep track of the status... With such bugs in the protocol, it will be hard for the Bitcoin ecosystem to move away from the situation in which the Satoshi client devs set all the rules.  
> **username_1**: @username_7: AFAIK it is, but I will leave it to people who are more involved with the core code to comment... This is adequate for a separate SE question.  
> **username_8**: Good answer, but one small, but capital point is eluded: how do the nodes in the network agree on what is the difficulty ?  
> **username_1**: @username_8: The difficulty of a block is a deterministic calculation based on the data of the previous blocks. All nodes independently do the same calculation and get the same result.  
> **username_8**: @username_1 thank you for that answer. But to me, it just move the problem around. As I understand you answer, the computation is made from the timestamp available in the blocks. But then, how does a p2p network agree on the timestamp ?  
> **username_1**: @username_8: The timestamp is a part of the block, which means that whoever found the block decides what to put in it. The timestamp must be no sooner than the median of the past 11 blocks. Also, if a node receives a block with a timestamp more than 2 hours in the future it will reject it and not propagate it.  
> **username_9**: References to the Bitcoin specifications or codebase would be much appreciated.  Revising your answer is strongly preferred over shoving stuff into the comments.  
> **username_1**: @username_9: The stuff in the comments is not part of the core answer. They are replies to specific followup questions.  
> **username_10**: @username_1, so if I want to calculate the round completion should I do CURRENT_BLOCK_COUNT_IN_THIS_ROUND/2015 instead of CURRENT_BLOCK_COUNT_IN_THIS_ROUND/2016 ???  
> **username_1**: @username_10: The "round" (difficulty retarget) is done every 2016 blocks. But the recalculation currently is not prev_target*TIME_FOR_LAST_2016_Blocks/1209600, it's prev_target*TIME_FOR_LAST_2015_Blocks/1209600.  
> **username_11**: So this basically means that errors will add up as every time only the last epoch time is considered? This would mean that stating in 2140 the last bitcoin will be mined is wrong as it could be years or even decades before that.  
> **username_1**: @username_11: The off-by-one bug is responsible for blocks being found 0.05% slower on average than the "official" 2016 per two weeks. There is a separate issue that causes another 0.05% slowdown. Together they amount to only 1 month slowdown over a century. However, there is a separate effect that causes blocks to be found faster due to the increase in hashrate. This is more significant and the last coin will be mined probably 1-2 years too early because of this.  
> **username_1**: @username_11: The total amount of speedup due to hashrate increase can be calculated as roughly log (difficulty) * 2 weeks. This is the main reason block halving parties are at a different date each time - November in 2012, July in 2016 etc.  
> **username_11**: yes I was referring to the speedup due to increasing hashrate and not the 2015 blocks bug  
> **username_1**: @username_11: Oh ok. Previous comments were about the bug, and "errors" hinted that it's the bug, so I assumed we're talking about that. So, yes. If we assume that around 2140 the hashrate will be around *1B what it is now, the schedule will be ahead by 96 weeks, or almost two years. But there is yet another effect - a delay caused by the fact that in the beginning, the difficulty was 1 even though the hashrate wasn't enough to justify it.  

---

### Answer by username_2 on 2017-12-29. Score: 22

username_1's answer is good. I just want to give some practical detail method about difficulty calculation, perhaps helpful for future views of this question's answer.

Let's take a look at Satoshi's genesis block header (part of related info):

```
$ bitcoin-cli getblockhash 0
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

$ bitcoin-cli getblockheader 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
{
  ...
  "height": 0,
  ...
  "bits": "1d00ffff",
  "difficulty": 1,
  ...
}

```

As we can see above, the genesis block has a '1' difficulty and '1d00ffff' bits. The [bitcoin bits](https://bitcoin.stackexchange.com/questions/23912/how-is-the-target-section-of-a-block-header-calculated) means the 'target' hash value, the new generated block must meet a condition: block header's double SHA-256 hash value must less than this 'target' value.

The '1d00ffff' bits value in genesis block means the 'target' value:

```
[0x00000000,0xffff,{0x00..0x00}]
                   {0x00..0x00} at above has 26 bytes 0x00.

```

Then, to find a new block, you must search that 32 bits nNonce value (and nTimes and the hashMerkleRoot also) until the block hash value has 4 bytes zero leading.
By the way, the nNonce is one of the fields in block header structure:

```c
struct header_structure{            // BYTES   NAME
    uint32_t nVersion;              // 4       version
    uint8_t hashPrevBlock[32];      // 32      previous block header hash
    uint8_t hashMerkleRoot[32];     // 32      merkle root hash
    uint32_t nTime;                 // 4       time
    uint32_t nBits;                 // 4       target
    uint32_t nNonce;                // 4       nonce
};

```

Because SHA-256 algorithm (as well as any cryptographically secure hash algorithm) produces output that will appear [like an uniformly random sequence](https://crypto.stackexchange.com/questions/12822/are-the-sha-family-hash-outputs-practically-random), the practical 'trial and error' method is the only way to find a new block to meet the condition. The probability to find a block with the 4 bytes zero leading hash value is 1/(2^32), that means the average 'trial and error" numbers are exactly 2^32 (i.e. 4G).

For human easy understanding about this 'target' hash value, We define the term 'difficulty', which means the average 'trial and error" numbers to find a block to meet the 'target' condition. And we define the 'difficulty' unit:
1 'difficulty' = 4G hashes

Then, till today, the bitcoin blockchain height reach 501509, let's take a look at its header:

```
$ bitcoin-cli getblockheader 0000000000000000006c5532f4fd9ee03e07f94df165c556b89c495e97680147
{
  ...
  "height": 501509,
  ...
  "bits": "18009645",
  "difficulty": 1873105475221.611,
  ...
}

```

The block 501509's bits = 0x18009645, it's the compact format of 256 bits integer, its 256 bits format is:

```
[0x00000000,0x00000000,0x009645,{0x00..0x00}]
                                {0x00..0x00} at above has 21 bytes 0x00.
that is  0x009645 * (256 ^ 21） 
The genesis block's target is  ( 0x00ffff * 256 ^ 26 ）which is the difficulty unit '1.0'.
So, the difficulty 
= (0x00ffff * 256 ^ 26）/ (0x009645 * 256 ^ 21)
= 65535/38469 * (256^5)
= 1.703579505575918 * 2^40
= 1873105475221.611

```

So far, you have all the detail about how to calculate the 'difficulty'.
In some cases, we also use the simple format **1.7T** to say the difficulty, in above example：

```
(1.703579505575918 * 2^40) = 1.703579505575918T
1T = 2^40 = 1024^4

```

> **Comments:**
> **username_3**: 1d is 29 in Dec(not 26). SHS is SHA  
> **username_2**: thanks @username_3, the typo error `SHS` has been fixed. But `1d` indeed means 26 bytes zero tail instead of 29, please read the example detail showed above.  
> **username_3**: ah yeah. Significand  
> **username_4**: Finally, one person that really explain the calculation, thank you very much  

---

### Answer by username_5 on 2019-01-27. Score: 7

I would like to give my 2 cents here, by expliciting the relationship between the probability of mining a block given the current target `t` and the corresponding difficulty `d` as it is calculated in bitcoin core.

So cryptographic hash functions are idealized by the random oracle abstraction [<https://en.wikipedia.org/wiki/Random_oracle]>. We can therefore model the output of the `doubleSHA256` hash function used in PoW as a uniform variable in the space `{0,1}^256`, i.e. arrays of 256 bits. Thus the probability of a single hash `h` being a valid hash is:

```
p = P(h < t) = t /( 2^{256} - 1 )

```

On the other hand `d` is calculated as follows, just as @username_2 explained before only transformed into decimals:

```
d = ( (2^{16} - 1) * 2^{8*26} ) / t = ( (2^{16} -1) * 2^{208} ) / t

```

The implementation is in [<https://github.com/bitcoin/bitcoin/blob/master/src/rpc/blockchain.cpp]>, line 60, function `GetDifficulty`. Actually if someone can explain how exactly the code maps to the formula above, that would be helpful. Combining those two formulas we obtain:

```
d = ( (2^{16} -1) * 2^{208} ) / ( p * (2^{256} - 1) ) ~ 2^{-32} / p

```

Analyzing this last expression the difficulty is the ratio between the probability of obtaining a hash lower than `2^{224}` (which is the lowest decimal number that has a binary representation using 256 bits starting with 32 zero bits) and the probability of obtaining a valid hash based on the current target `t`. This is a direct implication of defining, in the genesis block, as **difficulty 1** the one associated to the hexadecimal target **0x1d00ffff**, expressed in what I think is called the 32-bit compact form for 256-bit numbers.

A nice question I believe is why this specific compact form was chosen for representing the target.

> **Comments:**
> **username_6**: Upvoted! The compact form provides 3 most significant bytes for the target, in the min difficulty the 3 most significant bytes are 00ffff.  

---

