Pool getwork “target”?

Question

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?

Answer 1

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:

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

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