<p>You are right, it could happen you are finding a hash that meets the pool target but not the highest possible target. But because the difficulty is way higher than one, and therefore the share wouldnt finish the block anyway, its not in their interest. You have done your work and you will get your share. They just make it a bit easier for you, by passing a higher target than possible.</p>

<p>Another possible reason:
Comparing a hash to the highest possible target would take more time, because you have to check the whole hash (checking the zeros at the end as well). With the non-truncated target you only need to check until the first F occures because than its at least equal or lower.</p>

CC BY-SA 3.0
2014-06-09T17:11:04.700Z
Right, but only a mere 0.00000001 of hashes  got the first "F" matching. Trivially speeding up this  0.00000001 of hashes is hardly going to improve running speed...
Pacerier
CC BY-SA 3.0
2014-06-09T16:22:24.967Z
2014-06-09T16:22:24.967Z
Dennis Kriechel
<p><a href="https://en.bitcoin.it/wiki/Difficulty" rel="nofollow">Bitcoin Wiki (Difficulty)</a>:</p>

<blockquote>
  <p>The highest possible target (difficulty 1) is defined as 0x1d00ffff,
  which gives us a hex target of </p>

<pre><code>0x00000000FFFF0000000000000000000000000000000000000000000000000000
</code></pre>
  
  <p>It should be noted that pooled mining often uses non-truncated
  targets, which puts "pool difficulty 1" at</p>

<pre><code>0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
</code></pre>
</blockquote>

<p>From what I know, using non-truncated targets puts the <a href="https://en.bitcoin.it/wiki/Target" rel="nofollow">target</a> at a higher number than the network would accept. In other words, we may end up finding a hash accepted by the "pooled mining" (lower than non-truncated), yet rejected by the network (higher than truncated).</p>

<p>Why do people use non-truncated mining targets?</p>

<p>Why not simply use the actual truncated targets so that we can have a more accurate picture of the network and avoid <em>overheads</em> incurred as such?</p>

<protocol><difficulty>
What's the advantage of using non-truncated mining targets?
Pacerier
# What's the advantage of using non-truncated mining targets?

(Asked by: username_0 on 2014-06-09)

[Bitcoin Wiki (Difficulty)](https://en.bitcoin.it/wiki/Difficulty):

> The highest possible target (difficulty 1) is defined as 0x1d00ffff,
> which gives us a hex target of
>
> ```
> 0x00000000FFFF0000000000000000000000000000000000000000000000000000
>
> ```
>
> It should be noted that pooled mining often uses non-truncated
> targets, which puts "pool difficulty 1" at
>
> ```
> 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
>
> ```

From what I know, using non-truncated targets puts the [target](https://en.bitcoin.it/wiki/Target) at a higher number than the network would accept. In other words, we may end up finding a hash accepted by the "pooled mining" (lower than non-truncated), yet rejected by the network (higher than truncated).

Why do people use non-truncated mining targets?

Why not simply use the actual truncated targets so that we can have a more accurate picture of the network and avoid *overheads* incurred as such?

**Tags:** protocol, difficulty


---

## 1 answers

### Answer by username_1 on 2014-06-09. Score: 1

You are right, it could happen you are finding a hash that meets the pool target but not the highest possible target. But because the difficulty is way higher than one, and therefore the share wouldnt finish the block anyway, its not in their interest. You have done your work and you will get your share. They just make it a bit easier for you, by passing a higher target than possible.

Another possible reason:
Comparing a hash to the highest possible target would take more time, because you have to check the whole hash (checking the zeros at the end as well). With the non-truncated target you only need to check until the first F occures because than its at least equal or lower.

> **Comments:**
> **username_0**: Right, but only a mere 0.00000001 of hashes  got the first "F" matching. Trivially speeding up this  0.00000001 of hashes is hardly going to improve running speed...  

---

