Bitcoin Forum
April 23, 2018, 04:07:18 PM *
News: Latest stable version of Bitcoin Core: 0.16.0  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Pool OPs and share difficulty  (Read 2071 times)
kano
Legendary
*
Offline Offline

Activity: 2422
Merit: 1039


Linux since 1997 RedHat 4


View Profile
October 30, 2012, 04:39:51 AM
 #1

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

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
1524499638
Hero Member
*
Offline Offline

Posts: 1524499638

View Profile Personal Message (Offline)

Ignore
1524499638
Reply with quote  #2

1524499638
Report to moderator
1524499638
Hero Member
*
Offline Offline

Posts: 1524499638

View Profile Personal Message (Offline)

Ignore
1524499638
Reply with quote  #2

1524499638
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Syke
Legendary
*
Offline Offline

Activity: 2576
Merit: 1003


View Profile
October 30, 2012, 05:09:29 AM
 #2

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.

Buy & Hold
DrHaribo
Legendary
*
Online Online

Activity: 2394
Merit: 1017


Bitminter.com Operator


View Profile WWW
October 30, 2012, 07:16:09 AM
 #3

I use the "slightly below 1" difficulty, like most pools. I guess I did that because everyone else did.  Tongue

But I'll be using correct difficulty 1 now after adding var diff support.

▶▶▶ Bitminter.com - Your trusted mining pool since 2011.
doublec
Legendary
*
Offline Offline

Activity: 1078
Merit: 1000


View Profile
October 30, 2012, 12:14:41 PM
 #4

Bitparking uses 0x00000000ffff0000000000000000000000000000000000000000000000000000 for difficulty 1 shares.
Balthazar
Legendary
*
Offline Offline

Activity: 2310
Merit: 1000


Terran Emperor


View Profile WWW
October 30, 2012, 08:23:09 PM
 #5

We using 0x00000000ffff0000000000000000000000000000000000000000000000000000 for diff1 shares too.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2366
Merit: 1001



View Profile
October 30, 2012, 10:57:29 PM
 #6

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.

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.

kano
Legendary
*
Offline Offline

Activity: 2422
Merit: 1039


Linux since 1997 RedHat 4


View Profile
October 30, 2012, 11:35:54 PM
 #7

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

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Luke-Jr
Legendary
*
Offline Offline

Activity: 2366
Merit: 1001



View Profile
October 30, 2012, 11:51:51 PM
 #8

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.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!