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?


I just started up a miner connecting to slush's pool. 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:


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 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.

  • (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. Mar 16 '12 at 8:50
  • 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? Mar 16 '12 at 16:11
  • Why would they use anything but the lowest efficiently-computable difficulty? Mar 16 '12 at 16:55
  • 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? Mar 16 '12 at 18:42
  • 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. Mar 17 '12 at 2:24

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.