Didn't read the forum for two days (busy weekend work)

OK lets see if I can write it clearly.

Accepted 12345678 Diff X/Y GPU 1 pool 3

Y = the difficulty the pool requires and pays

X = the difficulty of the share found

Y is all that matters - X is purely for interest sake only

(and of course X will be greater than or equal to Y for all Accepted shares)

Now the easiest way to remove any confusions is to consider this:

Before vardiff, when you found a block while pool mining on a pool that doesn't pay a block bounty (most pools) you only got paid for a 1 diff share.

It didn't matter that it would have been greater than 1 million difficulty, you still only got paid for a 1 diff share.

To consider the maths is quite simple:

When you mine, on average

half your shares will be above

2 diff (yeah I'm not gonna explain that one

)

So if you are mining at

2 diff then on average

half your shares will be submitted.

The remainder (below

2 diff) are not submitted, or if they were submitted they would be rejected.

That's why each share is worth

2 times as much as a 1 diff share.

Replace

2 with any number N above 1, and

half with 1/N and it's the same.

--

Also note that X is rounded down so it depends on the pool's definition of 1 difficulty.

The value currently used is 26959946667150639794667015087019630673637144422540572481103610249216.0

Yes that's it

Or in hex:

0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff(Edit: and ... I just realised that's wrong at the last place - it should end in 5, not 6 - so the current code is only accurate to 67 places, the 68th place is wrong

)

This does mean that the value for X displayed, may on rare occasions, with a pool that uses correct difficulty values, not be correct.

It doesn't, however, mean that you will ever lose a share due to this.

The pool advertises the difficulty and the share is checked against the pools difficulty.

The problem is simply interpreting that number supplied by the pool and displaying it.

Most pools use that incorrect value for the BTC definitions of 1 difficulty above.

It means they only need to check the first 32bits instead of all 256bits and can stop at the 98.2% mark of processing the triple hash

(yeah even though it's a double hash, it's three times through the 64 steps since the first hash takes 2 goes through)

No idea why they think this is a big issue since the checking code is only a tiny fraction of the code that does the hash and the total gain in hashing is only 1.8% ... unless they trust the midstate you send back ... then it's 3% ... hmm I wonder if any pools risk that.

Anyway, the result it that they Accept an extra share every 65536 shares - so miners don't get extra Rejects, they get a rare extra Accept.

Here's an example of one from back in April:

[2012-04-20 15:50:10] Accepted 00000000.ffff7bc4.7c568d65 GPU 1 thread 3 pool 0

With correct difficulty that would have been rejected.

The correct value for 1 difficulty is:

0x00000000ffff0000000000000000000000000000000000000000000000000000