<p>I just started up a miner connecting to <a href="http://mining.bitcoin.cz/" rel="nofollow">slush's pool</a>.  The <code>getwork</code> my miner sent was answered with this:</p>

<pre><code>{"id": "1",
 "result": {"hash1": "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
            "data": "00000001c5993e03c08cea1b78a2190865f68698c069a8033d60e5e70000082a00000000e0884a966424aac62b4997dc0bae1c60fab2ba12887fa842f07c9cacaf24b4534f3b53931a0c290b00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
            "midstate": "390b85042008bac15b6ce310d791c8612610a0c5ee441b252ee6abee70bf742a",
            "target": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000"
           },
 "error": null
}
</code></pre>

<p>The target it gave me is 64 hex digits long.  That's around 2^256, and as such is <em>bigger</em> than the maximum target of 2^(256-32)-1.  Then I realised the target is 'little-endian', meaning it's byte-by-byte backwards.  Reversing it gives:</p>

<pre><code>00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
</code></pre>

<p>which is exactly 2^(256-32)-1, the maximum target.</p>

<p>So slush's pool at least is asking me to solve blocks of difficulty 1.</p>

<p>I know <a href="https://en.bitcoin.it/wiki/P2Pool" rel="nofollow">P2Pool</a> sets the difficulty to be higher, so that shares on the P2Pool sharechain will be found around every 10 seconds.  Currently to achieve that it's giving out work with difficulty <code>609.82</code>, but it changes every few seconds based on the recent rate of finding P2Pool shares.</p>

<p>Edit: I just checked, and it turns out I'm wrong.  Here's a <code>getwork</code> from the P2Pool instance I'm running:</p>

<pre><code>{"error": null,
 "jsonrpc": "2.0",
 "id": 0,
 "result": {"hash1": "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
            "target": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000",
            "submitold": true,
            "identifier": "15578",
            "data": "000000011e90271e3071e27e4b16142162e54a68776176deeef5fe6e000001a800000000534e460eb3798f9d4149c56dddf486610512007201745fefd7661cedbde821fa4f3b5c461a0c290b00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
            "midstate": "acb6f89399060ab343bbd17e3a6cccb89c2211af189bec8da15284a1d5e87b29"
           }
}
</code></pre>

<p>Notice the target is the same as on slush's pool.  It represents a difficulty of 1.  So the miner thinks it's looking for shares of difficulty 1, but P2Pool rejects any share the miner submits which has a difficulty of less than <code>609.82</code>, or whatever the pool's difficulty is at the time.</p>

CC BY-SA 3.0
2012-03-16T08:50:33.203Z
(nitpick) The minimum target is actually 0xFFFF00000.... The value shown above actually corresponds to difficulty 0.999985. As this target allows the same optimizations for miners as real difficulty 1, this slightly higher target is used.
Pieter Wuille
CC BY-SA 3.0
2012-03-16T16:11:45.127Z
Hmmm, I knew that.  I wonder why I got it wrong, twice, in my answer above!  And why don't the mining pools use difficulty 1 instead of difficulty 0.999985?
Chris Moore
CC BY-SA 3.0
2012-03-16T16:55:44.980Z
Why would they use anything but the lowest efficiently-computable difficulty?
Pieter Wuille
CC BY-SA 3.0
2012-03-16T18:42:41.970Z
The difficulty is a constant in either case isn't it?  How does computational efficiency enter into this?  Are you saying it's easier to use bnProofOfWorkLimit because it's already defined than to use 0xFFFF<<n and have to spend the time to figure out what n should be?
Chris Moore
CC BY-SA 3.0
2012-03-17T02:24:45.350Z
Most miner software simply checks inside its tight loop whether the first 32 bits of the hash result are zero, which implicitly corresponds to difficulty 0.999985. Afterwards, outside of the main loop, results are verified to match the actual target. If a mining pool would require full difficulty 1, they'd see 0.0015% less shares, which are computed anyway.
Pieter Wuille
CC BY-SA 3.0
2012-02-15T07:08:32.790Z
2012-02-15T07:24:13.800Z
2012-02-15T07:24:13.800Z
Chris Moore
<p>Most pools define their target value (minimum value required to earn a "share"), as:</p>

<pre><code>T = 2 ** (256 - 32) - 1
= 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
</code></pre>

<p>The Bitcoin protocol defines a difficulty of 1 as a target of:</p>

<pre><code>D = 0xffff * 2**208
= 0x00000000ffff0000000000000000000000000000000000000000000000000000
</code></pre>

<p>They are nearly equal:</p>

<pre><code>T/D = 1.0000152590218967
</code></pre>

<p>The precise target used for earning shares could be set to a larger number, but that would increase the number of getwork requests sent to the server as shares would be easier to find.  Note that if you decrease the size of target, you would reduce the probability of finding ANY valid shares for a given block header (unless you allow changing the timestamp as well as the nonce).  As it stands, the expected number of shares found per getwork request is approximately 1 (when the target has 32 leading zero bits).</p>

CC BY-SA 3.0
2012-03-17T19:28:00.583Z
2012-03-17T19:28:00.583Z
mckoss
<p>In a getwork request, bitcoind sends a target corresponding to the current block's bits value. Do the major pools send the same target as one would expect from bitcoind, difficulty of "1" target, or perhaps something else?</p>

<protocol><mining-pools><bitcoind><getwork><difficulty>
Pool getwork "target"?
ThePiachu
# Pool getwork "target"?

(Asked by: username_0 on 2012-02-15)

In a getwork request, bitcoind sends a target corresponding to the current block's bits value. Do the major pools send the same target as one would expect from bitcoind, difficulty of "1" target, or perhaps something else?

**Tags:** protocol, mining-pools, bitcoind, getwork, difficulty


---

## 2 answers

### Answer by username_1 on 2012-02-15. Score: 1 | Accepted answer

I just started up a miner connecting to [slush's pool](http://mining.bitcoin.cz/). The `getwork` my miner sent was answered with this:

```
{"id": "1",
 "result": {"hash1": "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
            "data": "00000001c5993e03c08cea1b78a2190865f68698c069a8033d60e5e70000082a00000000e0884a966424aac62b4997dc0bae1c60fab2ba12887fa842f07c9cacaf24b4534f3b53931a0c290b00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
            "midstate": "390b85042008bac15b6ce310d791c8612610a0c5ee441b252ee6abee70bf742a",
            "target": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000"
           },
 "error": null
}

```

The target it gave me is 64 hex digits long. That's around 2^256, and as such is *bigger* than the maximum target of 2^(256-32)-1. Then I realised the target is 'little-endian', meaning it's byte-by-byte backwards. Reversing it gives:

```
00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

```

which is exactly 2^(256-32)-1, the maximum target.

So slush's pool at least is asking me to solve blocks of difficulty 1.

I know [P2Pool](https://en.bitcoin.it/wiki/P2Pool) sets the difficulty to be higher, so that shares on the P2Pool sharechain will be found around every 10 seconds. Currently to achieve that it's giving out work with difficulty `609.82`, but it changes every few seconds based on the recent rate of finding P2Pool shares.

Edit: I just checked, and it turns out I'm wrong. Here's a `getwork` from the P2Pool instance I'm running:

```
{"error": null,
 "jsonrpc": "2.0",
 "id": 0,
 "result": {"hash1": "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
            "target": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000",
            "submitold": true,
            "identifier": "15578",
            "data": "000000011e90271e3071e27e4b16142162e54a68776176deeef5fe6e000001a800000000534e460eb3798f9d4149c56dddf486610512007201745fefd7661cedbde821fa4f3b5c461a0c290b00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
            "midstate": "acb6f89399060ab343bbd17e3a6cccb89c2211af189bec8da15284a1d5e87b29"
           }
}

```

Notice the target is the same as on slush's pool. It represents a difficulty of 1. So the miner thinks it's looking for shares of difficulty 1, but P2Pool rejects any share the miner submits which has a difficulty of less than `609.82`, or whatever the pool's difficulty is at the time.

> **Comments:**
> **username_2**: (nitpick) The minimum target is actually 0xFFFF00000.... The value shown above actually corresponds to difficulty 0.999985. As this target allows the same optimizations for miners as real difficulty 1, this slightly higher target is used.  
> **username_1**: Hmmm, I knew that.  I wonder why I got it wrong, twice, in my answer above!  And why don't the mining pools use difficulty 1 instead of difficulty 0.999985?  
> **username_2**: Why would they use anything but the lowest efficiently-computable difficulty?  
> **username_1**: The difficulty is a constant in either case isn't it?  How does computational efficiency enter into this?  Are you saying it's easier to use bnProofOfWorkLimit because it's already defined than to use 0xFFFF<<n and have to spend the time to figure out what n should be?  
> **username_2**: Most miner software simply checks inside its tight loop whether the first 32 bits of the hash result are zero, which implicitly corresponds to difficulty 0.999985. Afterwards, outside of the main loop, results are verified to match the actual target. If a mining pool would require full difficulty 1, they'd see 0.0015% less shares, which are computed anyway.  

---

### Answer by username_3 on 2012-03-17. Score: 2

Most pools define their target value (minimum value required to earn a "share"), as:

```
T = 2 ** (256 - 32) - 1
= 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

```

The Bitcoin protocol defines a difficulty of 1 as a target of:

```
D = 0xffff * 2**208
= 0x00000000ffff0000000000000000000000000000000000000000000000000000

```

They are nearly equal:

```
T/D = 1.0000152590218967

```

The precise target used for earning shares could be set to a larger number, but that would increase the number of getwork requests sent to the server as shares would be easier to find. Note that if you decrease the size of target, you would reduce the probability of finding ANY valid shares for a given block header (unless you allow changing the timestamp as well as the nonce). As it stands, the expected number of shares found per getwork request is approximately 1 (when the target has 32 leading zero bits).


---

