As pools shift into using vardiff (which they really all will have to very soon) there will of course be the issue of someone wanting to calculate what their expected payout is with a vardiff pool and getting a different answer ... bitcoins are 8 decimal places ...
With ASIC-era difficulties, I think the difference won't even be noticable at 8 decimal places. 
Topic: Pool OPs and share difficulty (Read 2206 times)
Yes I have known about it for a very long time also.
(though I suspected all pools used the ffffffff... value which as replies above point out - isn't the case)
I only implemented the work difficulty calculation in cgminer recently (6 weeks ago) and had to decide how to implement it then.
I just never got around to posting this thread until yesterday/today
The place where it is most obvious (as I mentioned above) is when you solo mine.
The share difficulty displayed should of course match network difficulty - but it doesn't due to my definition of what 1 difficulty is in order to match the higher hash rate 1 difficulty getwork pools.
The problem I'm trying to avoid is that I'd prefer it to calculate it based on how nbits is calculated (correctly)
Then people using pools like doublec's and Balthazar's would also get correct stats from cgminer.
But the other pools who don't use ffff0000 wont get accurate stats.
As pools shift into using vardiff (which they really all will have to very soon) there will of course be the issue of someone wanting to calculate what their expected payout is with a vardiff pool and getting a different answer ... bitcoins are 8 decimal places ...
(though I suspected all pools used the ffffffff... value which as replies above point out - isn't the case)
I only implemented the work difficulty calculation in cgminer recently (6 weeks ago) and had to decide how to implement it then.
I just never got around to posting this thread until yesterday/today
The place where it is most obvious (as I mentioned above) is when you solo mine.
The share difficulty displayed should of course match network difficulty - but it doesn't due to my definition of what 1 difficulty is in order to match the higher hash rate 1 difficulty getwork pools.
The problem I'm trying to avoid is that I'd prefer it to calculate it based on how nbits is calculated (correctly)
Then people using pools like doublec's and Balthazar's would also get correct stats from cgminer.
But the other pools who don't use ffff0000 wont get accurate stats.
As pools shift into using vardiff (which they really all will have to very soon) there will of course be the issue of someone wanting to calculate what their expected payout is with a vardiff pool and getting a different answer ... bitcoins are 8 decimal places ...
Do you use the correct difficulty values, or like most (every?) pool in the past and present, use a slightly higher value defining 1 difficulty?
At the moment most pools accept 1 extra share in every 65,536 valid 1 difficulty shares since they use the value
0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
for 1 difficulty instead of
0x00000000ffff0000000000000000000000000000000000000000000000000000
Not a big deal ... except ... the result of this is that all displayed calculations are technically incorrect after about 4.5 decimal places.
There has always been a distinction between Bitcoin difficulty (bdiff) and pool difficulty (pdiff), and for good reason.At the moment most pools accept 1 extra share in every 65,536 valid 1 difficulty shares since they use the value
0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
for 1 difficulty instead of
0x00000000ffff0000000000000000000000000000000000000000000000000000
Not a big deal ... except ... the result of this is that all displayed calculations are technically incorrect after about 4.5 decimal places.
Pool difficulty aims to be easily checked. By trailing with ffs, only the first N octets need to be checked.
Bitcoin difficulty aims to be a 32-bit floating-point number with 24-bit precision. This cannot* represent round pdiff values, and results in (known and now expected) loss of precision when the difficulty adjusts.
The difference is so subtle that it doesn't make sense to make a distinction (except maybe pool rewarding, which probably already does).
* With a little more thought, bdiff FP could have been designed to work nicer with round pdiffs, but a lot of Bitcoin could have been done better in subtle ways like this.
We using 0x00000000ffff0000000000000000000000000000000000000000000000000000 for diff1 shares too.
Bitparking uses 0x00000000ffff0000000000000000000000000000000000000000000000000000 for difficulty 1 shares.
I use the "slightly below 1" difficulty, like most pools. I guess I did that because everyone else did. 
But I'll be using correct difficulty 1 now after adding var diff support.
But I'll be using correct difficulty 1 now after adding var diff support.
Not a big deal ... except ... the result of this is that all displayed calculations are technically incorrect after about 4.5 decimal places.
Like you said, not a big deal if the estimated hashrate is off by .045%, since with variance the estimate is going to be all over the place anyhow.
Of course you won't lose any shares/blocks - it's just displayed/reported difficulty information that is wrong.
That's the key. As long as work isn't lost, it's a non-issue.
A question I'd actually like to ask all pool OPs who use getwork ...
Do you use the correct difficulty values, or like most (every?) pool in the past and present, use a slightly higher value defining 1 difficulty?
At the moment most pools accept 1 extra share in every 65,536 valid 1 difficulty shares since they use the value
0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
for 1 difficulty instead of
0x00000000ffff0000000000000000000000000000000000000000000000000000
Not a big deal ... except ... the result of this is that all displayed calculations are technically incorrect after about 4.5 decimal places.
If you solo mine to bitcoind, the values displayed will be noticeably incorrect - though not really a big deal.
If you check the last share difficulty of your solo mine bitcoind pool it should be block difficulty, but it's out by a bit due to this.
Of course you won't lose any shares/blocks - it's just displayed/reported difficulty information that is wrong.
I wrote the code in cgminer that does this difficulty calculation for "getwork" and I matched what the pools do and thus give the same answer as the pools do.
However, it would be good if I could fix this if the pools used the proper values.
... or maybe getwork will go away soon and it won't be an issue.
Edit: an example of a valid share, that actually isn't 1 difficulty:
[2012-10-27 14:53:51] Accepted ffff12e6 Diff 0/1 MMQ 0 pool 0
Do you use the correct difficulty values, or like most (every?) pool in the past and present, use a slightly higher value defining 1 difficulty?
At the moment most pools accept 1 extra share in every 65,536 valid 1 difficulty shares since they use the value
0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
for 1 difficulty instead of
0x00000000ffff0000000000000000000000000000000000000000000000000000
Not a big deal ... except ... the result of this is that all displayed calculations are technically incorrect after about 4.5 decimal places.
If you solo mine to bitcoind, the values displayed will be noticeably incorrect - though not really a big deal.
If you check the last share difficulty of your solo mine bitcoind pool it should be block difficulty, but it's out by a bit due to this.
Of course you won't lose any shares/blocks - it's just displayed/reported difficulty information that is wrong.
I wrote the code in cgminer that does this difficulty calculation for "getwork" and I matched what the pools do and thus give the same answer as the pools do.
However, it would be good if I could fix this if the pools used the proper values.
... or maybe getwork will go away soon and it won't be an issue.
Edit: an example of a valid share, that actually isn't 1 difficulty:
[2012-10-27 14:53:51] Accepted ffff12e6 Diff 0/1 MMQ 0 pool 0
Jump to: