<blockquote>
<p><strong>is it accurate to think about Difficulty as a type of proportion or ratio?</strong></p>
</blockquote>
<p>I think of it as just a number that is an abstract representation of the probability of a mining attempt <em>failing</em>. As with darts or archery etc, smaller targets are more difficult to hit.</p>
<p>difficulty ∝ 1 / targetsize</p>
<hr />
<blockquote>
<p><strong>if it is a floating point number,</strong></p>
</blockquote>
<p><em>As Pieter Wuille clarified, floating point arithmetic is used in recalculating network targets.</em></p>
<p>For my purposes, I find it easiest to ignore difficulty completely and work with targets. Your subject area scope may differ.</p>
<hr />
<blockquote>
<p><strong>I am confused where the &quot;approximation&quot; piece</strong></p>
</blockquote>
<p><em>See Pieter Wuille's clarifying comment:</em></p>
<blockquote>
<p>The difficulty is an approximation [...] because in practice it's a floating-point number, computed to some finite precision.</p>
</blockquote>
<hr />
<blockquote>
<p><strong>the formula used to compare a hash against the Target,</strong></p>
</blockquote>
<pre><code>if hash &lt;= target then success
</code></pre>
<hr />
<p>P.S. <strong>Targets are ranges</strong></p>
<p>Really the target is a sub-range within the range of numbers that can be represented by a 256-bit integer. It is the size of this sub-range as a proportion of the total range that is important. You can achieve the same effect by saying miners have to find a number in the top n% or the bottom n% or any range n% wide anywhere in between. In a range of 0-1000 the target subranges of 0-10 or 990-1000 or 357-367 are all equally difficult to hit using a pseudo-random number generator such as a hashing algorithm. Bitcoin's inventor made an arbitrary choice of one end of the range. If the other end had been chosen the relationship between target and difficulty would not be an inverse one.</p>
<hr />
<blockquote>
<p><strong>Somehow I thought the Target got larger as hashrate increased,</strong></p>
</blockquote>
<p>It is the opposite: the size of the target range is made smaller (more difficult to hit) after total network hashrate increases.</p>
<hr />
<p>P.P.S <strong>Difficulty is a useful concept but a superfluous number for most purposes?</strong></p>
<p><a href="https://developer.bitcoin.org/reference/rpc/getdifficulty.html" rel="nofollow noreferrer">The API docs</a> say</p>
<blockquote>
<p><strong>getdifficulty</strong></p>
<p>Returns the proof-of-work difficulty <em>as a multiple of the minimum difficulty</em>.</p>
</blockquote>
<p>(my emphasis)</p>
<p>Note that the difficulty number is not actually used in mining or block validation, the target is. I believe difficulty is only used as a way of presenting the target to humans in a way that might be more intuitive.</p>

CC BY-SA 4.0
2023-12-23T23:33:08.610Z
Thank you.  When I query my Bitcoin node `getdifficulty` it currently returns 72006146478567.09 , a floating point number.  If Difficulty is not a floating point number, is this transformation just happening at the JSON RPC layer, and why?

`if hash <= target then success` - now I am extra confused.  Somehow I thought the Target got larger as hashrate increased, and that the formula should look more like this: `if hash <= 1 / target then success`.
sha2fiddy
CC BY-SA 4.0
2023-12-24T00:04:10.497Z
See postscripts to answer.
RedGrittyBrick
CC BY-SA 4.0
2023-12-24T02:08:00.553Z
I don't think the rounding in the "bits" representation is relevant here; that's internal to the target computation algorithm. The bits that come out, and its corresponding "rounded" target are the exact values from the perspective of consensus rules. The difficulty is an approximation of that, because in practice it's a floating-point number, computed to some finite precision.
Pieter Wuille
CC BY-SA 4.0
2023-12-24T10:36:53.733Z
Thanks @Pieter, I have updated my answer -- but I am not sure if I improved it or just compounded my errors. If I am heading in the wrong direction here it might be best for me to just delete this answer.
RedGrittyBrick
CC BY-SA 4.0
2023-12-24T13:53:52.067Z
@RedGrittyBrick I think I've confused you more. There are two separate processes: (1) the "bits" encoding that has limited precision, and which is applied during difficulty correction and (2) the conversion from target to difficulty which typically happens using floating-point arithmetic. (1) is a rounding operation, but I don't think it is in any way related to OP's question, and I think you should drop mention of it here. This rounding is done *during* the difficulty correction and the result is the actual network target. (2) is what is OP is asking about.
Pieter Wuille
CC BY-SA 4.0
2023-12-23T23:23:31.067Z
2023-12-24T18:24:37.680Z
2023-12-24T18:24:37.680Z
RedGrittyBrick
<blockquote>
<p>The Bitcoin wiki defines Difficulty as: difficulty = difficulty_1_target / current_target, where difficulty_1_target was the Target during the first Difficulty Epoch (the first 2016 blocks).</p>
</blockquote>
<p>It might be more useful to refer to that as &quot;relative difficulty&quot;, while 1/current_target is the absolute difficulty.</p>
<blockquote>
<p>If yes, is it accurate to think about Difficulty as a type of proportion or ratio?</p>
</blockquote>
<p>Yes, the relative difficulty is the ratio of the absolute difficulty to the original difficulty. The absolute difficulty is the ratio of the total number of possible hash outputs to the number of valid hashes.</p>
<blockquote>
<p>And if it is a floating point number, what is its precision?</p>
</blockquote>
<p>Uhhh... 256 bits?</p>
<p>&quot;Floating point&quot; isn't a type of <em>number</em>, it's a <em>data</em> type. A datatype is a method of <em>representing</em> a number, it's not the number itself. The difficulty is a rational number. It is uniquely defined by the target, which is a 256 bit number.</p>
<p>You can also, if you want, have a floating-point variable that <em>represents</em> this number. What precision that number has depends on what float you use. If you use a signed 32 bit float, it will have 24 bits of significant precision (as opposed to the exponent part). For 64 bits, it will have 53 bits. If you store it as float with fewer than 256 bits, then it will be rounded when it's converted to a float.</p>
<p>It might be useful to compare it to π. π is an irrational number, and has an infinite amount of precision. math.pi() is a float that <em>represents</em> π and has finite precision, and thus is a rounded version of π.</p>
<blockquote>
<p>For more practical use, how would you represent this formula using Difficulty instead of the Target?</p>
</blockquote>
<p>A block is valid if the total number of possible hash values divided by the actual hash value is greater than or equal to the absolute difficulty. Or, equivalently, if the actual hash value divided by the total number of possible hash values is less than or equal to the reciprocal of the absolute difficulty, or the actual hash value divided by the total number of possible hash values is less than or equal to the original difficulty divided by the current difficulty.</p>

CC BY-SA 4.0
2023-12-25T06:16:28.307Z
2023-12-25T06:16:28.307Z
Acccumulation
<blockquote>
<p>Is this definition of Difficulty correct?</p>
</blockquote>
<p>Yes.</p>
<blockquote>
<p>If yes, is it accurate to think about Difficulty as a type of proportion or ratio?</p>
</blockquote>
<p>Yes, it is how many times harder current blocks are to mine than blocks in the first difficulty epoch were.</p>
<p>For reference, difficulty 1 corresponds to (very close to) 4295032833 hash attempts per block. It has a target of (exactly) 26959535291011309493156476344723991336010898738574164086137773096960.</p>
<p>Block 822627 has a target of (exactly) 374406027949793378682501776760424667692437142927048704.</p>
<p>The ratio between these two huge numbers is (approximately) 72006146478567.1. That is the difficulty of block 822627. It is roughly 72006 billion times harder to mine a block today than it was in January 2009.</p>
<blockquote>
<p>And if it is a floating point number, what is its precision?</p>
</blockquote>
<p>Whatever precision you calculate it to. Typical implementations will use a floating-point data type in the computation, which necessary limits its precision.</p>
<p>But it's really just the ratio of two huge numbers. You can calculate it to much higher precision too. Block 822627 has difficulty
72006146478567.09941095874369093485414495333341140374503764945604440...</p>
<p>That much precision isn't needed, as the difficulty is really just used for presenting the hardness of mining a block to humans. Internally the software uses the target, which is exact.</p>
<blockquote>
<p>Lastly, could someone please confirm the formula used to compare a hash against the Target, to see if it mines a valid block?</p>
</blockquote>
<p>The requirement is: <em>block_hash ≤ target</em> (where <em>block_hash</em> is the block hash interpreted as 256-bit little-endian number). The lower the target is, the harder it is to land below it. In a way, the difficulty is a measure for &quot;target lowness&quot;.</p>
<blockquote>
<p>For more practical use, how would you represent this formula using Difficulty instead of the Target?</p>
</blockquote>
<p>Perhaps something like <em>block_hash_diff ≥ difficulty</em>, where <em>block_hash_diff</em> is the ratio between the first block's target (given above) and the block's actual target?</p>

CC BY-SA 4.0
2023-12-24T15:09:42.790Z
Thanks Pieter!  This is super helpful and clears up a lot of my confusion. At difficulty 1, where target is `0xffff * 2**208` or `26959535291011309493156476344723991336010898738574164086137773096960`, I thought the statistical average number of hashes required to find a block was `pow(2, 32)` or `4294967296`, but in your answer you say it is very close to `4295032833`.  Could you share how you arrived at your number?
sha2fiddy
CC BY-SA 4.0
2023-12-24T15:23:08.810Z
The number of valid hashes (2^208 * 0xffff) divided by 2^256 (number of possible hash outcomes) is (very close to) 1/4295032833. More exactly, it is 1/(2^48 / 0xffff).
Pieter Wuille
CC BY-SA 4.0
2023-12-24T15:30:06.133Z
To be entirely precise, the number of valid hashes at difficulty 1 is actually `(0xffff * 2**208) + 1`, as the consensus rule is that the hash value is less than **or equal to** the target. But the effect of that `+ 1` is so small that it's generally ignored.
Pieter Wuille
CC BY-SA 4.0
2023-12-24T18:17:46.553Z
Interesting... in the mining industry, it is common to take an amount of mining shares and multiply by 4294967296 (2^32) to produce an approximate number of hashes.  Divide that by total seconds for an approximate hashrate.  IE, assuming a share difficulty level 1, `appx_hashrate = shares * 4294967296 / seconds`.  I'm now wondering if it would be more accurate to use 4295032833 for the rate of diff 1 shares-to-hashes?
sha2fiddy
CC BY-SA 4.0
2023-12-24T18:43:51.940Z
@sha2fiddy Inside the Stratum protocol used for pool mining there is also a notion of (share) difficulty, however it corresponds to exactly 2^32 hashes per block (so it differs from difficulty as used by the rest of the ecosystem).
Pieter Wuille
CC BY-SA 4.0
2023-12-23T23:30:48.710Z
2023-12-24T00:44:40.253Z
2023-12-24T00:44:40.253Z
Pieter Wuille
<p>My understanding is that Difficulty (aka Network Difficulty) is an approximate representation of the Target, a 256-bit number which is hard to reason about or work with in human-readable Decimal format.</p>
<p>The Bitcoin wiki defines Difficulty as: <code>difficulty = difficulty_1_target / current_target</code>, where <code>difficulty_1_target</code> was the Target during the first Difficulty Epoch (the first 2016 blocks).</p>
<p>Is this definition of Difficulty correct? If yes, is it accurate to think about Difficulty as a type of proportion or ratio? And if it is a floating point number, what is its precision?</p>
<p>I don't often work with hexadecimal or 256-bit numbers, so I am confused where the &quot;approximation&quot; piece comes in, making Difficulty values easier to work with than the Target. Is Difficulty rounded after some decimal place?</p>
<p>Lastly, could someone please confirm the formula used to compare a hash against the Target, to see if it mines a valid block? For more practical use, how would you represent this formula using Difficulty instead of the Target?</p>
<p>Thank you</p>

<hash><difficulty><precision>
What is the numeric precision of Network Difficulty?
sha2fiddy
# What is the numeric precision of Network Difficulty?

(Asked by: username_0 on 2023-12-23)

My understanding is that Difficulty (aka Network Difficulty) is an approximate representation of the Target, a 256-bit number which is hard to reason about or work with in human-readable Decimal format.

The Bitcoin wiki defines Difficulty as: `difficulty = difficulty_1_target / current_target`, where `difficulty_1_target` was the Target during the first Difficulty Epoch (the first 2016 blocks).

Is this definition of Difficulty correct? If yes, is it accurate to think about Difficulty as a type of proportion or ratio? And if it is a floating point number, what is its precision?

I don't often work with hexadecimal or 256-bit numbers, so I am confused where the "approximation" piece comes in, making Difficulty values easier to work with than the Target. Is Difficulty rounded after some decimal place?

Lastly, could someone please confirm the formula used to compare a hash against the Target, to see if it mines a valid block? For more practical use, how would you represent this formula using Difficulty instead of the Target?

Thank you

**Tags:** hash, difficulty, precision


---

## 3 answers

### Answer by username_2 on 2023-12-23. Score: 5 | Accepted answer

> Is this definition of Difficulty correct?

Yes.

> If yes, is it accurate to think about Difficulty as a type of proportion or ratio?

Yes, it is how many times harder current blocks are to mine than blocks in the first difficulty epoch were.

For reference, difficulty 1 corresponds to (very close to) 4295032833 hash attempts per block. It has a target of (exactly) 26959535291011309493156476344723991336010898738574164086137773096960.

Block 822627 has a target of (exactly) 374406027949793378682501776760424667692437142927048704.

The ratio between these two huge numbers is (approximately) 72006146478567.1. That is the difficulty of block 822627. It is roughly 72006 billion times harder to mine a block today than it was in January 2009.

> And if it is a floating point number, what is its precision?

Whatever precision you calculate it to. Typical implementations will use a floating-point data type in the computation, which necessary limits its precision.

But it's really just the ratio of two huge numbers. You can calculate it to much higher precision too. Block 822627 has difficulty
72006146478567.09941095874369093485414495333341140374503764945604440...

That much precision isn't needed, as the difficulty is really just used for presenting the hardness of mining a block to humans. Internally the software uses the target, which is exact.

> Lastly, could someone please confirm the formula used to compare a hash against the Target, to see if it mines a valid block?

The requirement is: *block\_hash ≤ target* (where *block\_hash* is the block hash interpreted as 256-bit little-endian number). The lower the target is, the harder it is to land below it. In a way, the difficulty is a measure for "target lowness".

> For more practical use, how would you represent this formula using Difficulty instead of the Target?

Perhaps something like *block\_hash\_diff ≥ difficulty*, where *block\_hash\_diff* is the ratio between the first block's target (given above) and the block's actual target?

> **Comments:**
> **username_0**: Thanks username_2!  This is super helpful and clears up a lot of my confusion. At difficulty 1, where target is `0xffff * 2**208` or `26959535291011309493156476344723991336010898738574164086137773096960`, I thought the statistical average number of hashes required to find a block was `pow(2, 32)` or `4294967296`, but in your answer you say it is very close to `4295032833`.  Could you share how you arrived at your number?  
> **username_2**: The number of valid hashes (2^208 * 0xffff) divided by 2^256 (number of possible hash outcomes) is (very close to) 1/4295032833. More exactly, it is 1/(2^48 / 0xffff).  
> **username_2**: To be entirely precise, the number of valid hashes at difficulty 1 is actually `(0xffff * 2**208) + 1`, as the consensus rule is that the hash value is less than **or equal to** the target. But the effect of that `+ 1` is so small that it's generally ignored.  
> **username_0**: Interesting... in the mining industry, it is common to take an amount of mining shares and multiply by 4294967296 (2^32) to produce an approximate number of hashes.  Divide that by total seconds for an approximate hashrate.  IE, assuming a share difficulty level 1, `appx_hashrate = shares * 4294967296 / seconds`.  I'm now wondering if it would be more accurate to use 4295032833 for the rate of diff 1 shares-to-hashes?  
> **username_2**: @username_0 Inside the Stratum protocol used for pool mining there is also a notion of (share) difficulty, however it corresponds to exactly 2^32 hashes per block (so it differs from difficulty as used by the rest of the ecosystem).  

---

### Answer by username_1 on 2023-12-23. Score: 3

> **is it accurate to think about Difficulty as a type of proportion or ratio?**

I think of it as just a number that is an abstract representation of the probability of a mining attempt *failing*. As with darts or archery etc, smaller targets are more difficult to hit.

difficulty ∝ 1 / targetsize

---

> **if it is a floating point number,**

*As username_2 username_2 clarified, floating point arithmetic is used in recalculating network targets.*

For my purposes, I find it easiest to ignore difficulty completely and work with targets. Your subject area scope may differ.

---

> **I am confused where the "approximation" piece**

*See username_2 username_2's clarifying comment:*

> The difficulty is an approximation [...] because in practice it's a floating-point number, computed to some finite precision.

---

> **the formula used to compare a hash against the Target,**

```
if hash <= target then success

```

---

P.S. **Targets are ranges**

Really the target is a sub-range within the range of numbers that can be represented by a 256-bit integer. It is the size of this sub-range as a proportion of the total range that is important. You can achieve the same effect by saying miners have to find a number in the top n% or the bottom n% or any range n% wide anywhere in between. In a range of 0-1000 the target subranges of 0-10 or 990-1000 or 357-367 are all equally difficult to hit using a pseudo-random number generator such as a hashing algorithm. Bitcoin's inventor made an arbitrary choice of one end of the range. If the other end had been chosen the relationship between target and difficulty would not be an inverse one.

---

> **Somehow I thought the Target got larger as hashrate increased,**

It is the opposite: the size of the target range is made smaller (more difficult to hit) after total network hashrate increases.

---

P.P.S **Difficulty is a useful concept but a superfluous number for most purposes?**

[The API docs](https://developer.bitcoin.org/reference/rpc/getdifficulty.html) say

> **getdifficulty**
>
> Returns the proof-of-work difficulty *as a multiple of the minimum difficulty*.

(my emphasis)

Note that the difficulty number is not actually used in mining or block validation, the target is. I believe difficulty is only used as a way of presenting the target to humans in a way that might be more intuitive.

> **Comments:**
> **username_0**: Thank you.  When I query my Bitcoin node `getdifficulty` it currently returns 72006146478567.09 , a floating point number.  If Difficulty is not a floating point number, is this transformation just happening at the JSON RPC layer, and why?  `if hash <= target then success` - now I am extra confused.  Somehow I thought the Target got larger as hashrate increased, and that the formula should look more like this: `if hash <= 1 / target then success`.  
> **username_1**: See postscripts to answer.  
> **username_2**: I don't think the rounding in the "bits" representation is relevant here; that's internal to the target computation algorithm. The bits that come out, and its corresponding "rounded" target are the exact values from the perspective of consensus rules. The difficulty is an approximation of that, because in practice it's a floating-point number, computed to some finite precision.  
> **username_1**: Thanks @username_2, I have updated my answer -- but I am not sure if I improved it or just compounded my errors. If I am heading in the wrong direction here it might be best for me to just delete this answer.  
> **username_2**: @username_1 I think I've confused you more. There are two separate processes: (1) the "bits" encoding that has limited precision, and which is applied during difficulty correction and (2) the conversion from target to difficulty which typically happens using floating-point arithmetic. (1) is a rounding operation, but I don't think it is in any way related to OP's question, and I think you should drop mention of it here. This rounding is done *during* the difficulty correction and the result is the actual network target. (2) is what is OP is asking about.  

---

### Answer by username_3 on 2023-12-25. Score: 0

> The Bitcoin wiki defines Difficulty as: difficulty = difficulty\_1\_target / current\_target, where difficulty\_1\_target was the Target during the first Difficulty Epoch (the first 2016 blocks).

It might be more useful to refer to that as "relative difficulty", while 1/current\_target is the absolute difficulty.

> If yes, is it accurate to think about Difficulty as a type of proportion or ratio?

Yes, the relative difficulty is the ratio of the absolute difficulty to the original difficulty. The absolute difficulty is the ratio of the total number of possible hash outputs to the number of valid hashes.

> And if it is a floating point number, what is its precision?

Uhhh... 256 bits?

"Floating point" isn't a type of *number*, it's a *data* type. A datatype is a method of *representing* a number, it's not the number itself. The difficulty is a rational number. It is uniquely defined by the target, which is a 256 bit number.

You can also, if you want, have a floating-point variable that *represents* this number. What precision that number has depends on what float you use. If you use a signed 32 bit float, it will have 24 bits of significant precision (as opposed to the exponent part). For 64 bits, it will have 53 bits. If you store it as float with fewer than 256 bits, then it will be rounded when it's converted to a float.

It might be useful to compare it to π. π is an irrational number, and has an infinite amount of precision. math.pi() is a float that *represents* π and has finite precision, and thus is a rounded version of π.

> For more practical use, how would you represent this formula using Difficulty instead of the Target?

A block is valid if the total number of possible hash values divided by the actual hash value is greater than or equal to the absolute difficulty. Or, equivalently, if the actual hash value divided by the total number of possible hash values is less than or equal to the reciprocal of the absolute difficulty, or the actual hash value divided by the total number of possible hash values is less than or equal to the original difficulty divided by the current difficulty.


---

