Bitcoin Forum
May 26, 2024, 12:23:31 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Proper PPLNS lastNshares calculation for script based coin pools - SOLVED  (Read 1650 times)
the1silverwolf (OP)
Member
**
Offline Offline

Activity: 112
Merit: 10



View Profile
May 30, 2013, 04:27:12 PM
Last edit: May 30, 2013, 09:29:05 PM by the1silverwolf
 #1

As most of you know the PPLNS calculation in mmcFE by default is based upon a fixed number in the configuration file.  This isn't really the way PPLNS is supposed to work.  It needs to be based upon the block difficulty at the time.

The normal calculation that I can find is difficulty * 2 = lastNshares, but this doesn't make sense for script based coins, even if you multiply the difficulty * 65536 as cgminer does.

Example, WDC's current difficulty is 1.62864385.  1.62864385 * 65536 = 106,168.32, which as I understand it is why CGMINER reports 107k as the block difficulty (it rounds).  But this would yield a lastNshares value of 212,337 (rounded) shares.  This doesn't make any sense as the average number of shares necessary to solve a block on my WDC pool is a little over 12,000 at the moment.

Since scrypt mining is about 1/1000 as efficient as SHA256 mining (kh/s instead of mh/s) I thought about dividing this figure by 1,000, but that also yields a number that doesn't make any sense, namely 212 shares (rounded).

Dividing the figure by 10 would yield 21,233 shares and that seems reasonable.  Some rounds are more than that and some are less, but I just picked that out of thin air and would like some input on what a proper calculation would be.

Hopefully someone with a better understanding of the math involved can chime in and help me out here.  I'd like to thank you guys in advance for your time.  I searched the forums but did not find anything relevant.

--
the1silverwolf
the1silverwolf (OP)
Member
**
Offline Offline

Activity: 112
Merit: 10



View Profile
May 30, 2013, 05:28:15 PM
 #2

No Ideas ?

--
the1silverwolf
Balthazar
Legendary
*
Offline Offline

Activity: 3108
Merit: 1358



View Profile
May 30, 2013, 05:38:59 PM
 #3

Some pools using dynamic N calculation from diff, some doesn't. Actually, you can choose any value which you like. Higher N values (100k or even 500k diff32-diff64 shares on some pools) decreases the variance and makes payout system reaction slower. Extremely low N values could be used for fun, something like "pyramidal mining".
the1silverwolf (OP)
Member
**
Offline Offline

Activity: 112
Merit: 10



View Profile
May 30, 2013, 06:56:20 PM
 #4

Some pools using dynamic N calculation from diff, some doesn't. Actually, you can choose any value which you like. Higher N values (100k or even 500k diff32-diff64 shares on some pools) decreases the variance and makes payout system reaction slower. Extremely low N values could be used for fun, something like "pyramidal mining".

Thanks for the reply, I appreciate your time.  But I was trying to figure out how it's actually supposed to work originally.

--
the1silverwolf
niteryder
Full Member
***
Offline Offline

Activity: 196
Merit: 100


View Profile
May 30, 2013, 06:58:01 PM
 #5

Some pools using dynamic N calculation from diff, some doesn't. Actually, you can choose any value which you like. Higher N values (100k or even 500k diff32-diff64 shares on some pools) decreases the variance and makes payout system reaction slower. Extremely low N values could be used for fun, something like "pyramidal mining".


I wouldn't mind finding out more on the dynamic N.
the1silverwolf (OP)
Member
**
Offline Offline

Activity: 112
Merit: 10



View Profile
May 30, 2013, 07:08:05 PM
 #6

From what I can tell by reading the description (http://silverwolf.ath.cx/wdc/about) I think it's supposed to be the expected number of shares needed to solve a block.

Short rounds would have shares from previous rounds considered, long rounds would have shares from the beginning of the round ignored.

Does everyone agree with that assessment or am I missing something ?

--
the1silverwolf
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1054



View Profile WWW
May 30, 2013, 07:09:13 PM
 #7

It needs to be based upon the block difficulty at the time.
Well, that's not the correct way either. Every share needs to be scored based on the difficulty at the time it is submitted, see https://bitcointalk.org/index.php?topic=39832.0.

The fact that in scrypt the hashrate is lower is irrelevant. You'll want the window to be a few times larger than the time to find a block, 2 * difficulty should work fine.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
the1silverwolf (OP)
Member
**
Offline Offline

Activity: 112
Merit: 10



View Profile
May 30, 2013, 07:30:26 PM
 #8

It needs to be based upon the block difficulty at the time.
Well, that's not the correct way either. Every share needs to be scored based on the difficulty at the time it is submitted, see https://bitcointalk.org/index.php?topic=39832.0.

The fact that in scrypt the hashrate is lower is irrelevant. You'll want the window to be a few times larger than the time to find a block, 2 * difficulty should work fine.

Then maybe I am not understanding what "difficulty" in this example is.  WDC difficulty is 1.62864385 (or it was when I made my OP).  How do you correlate that to number of shares ?

--
the1silverwolf
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1054



View Profile WWW
May 30, 2013, 07:38:24 PM
Last edit: May 30, 2013, 07:53:06 PM by Meni Rosenfeld
 #9

It needs to be based upon the block difficulty at the time.
Well, that's not the correct way either. Every share needs to be scored based on the difficulty at the time it is submitted, see https://bitcointalk.org/index.php?topic=39832.0.

The fact that in scrypt the hashrate is lower is irrelevant. You'll want the window to be a few times larger than the time to find a block, 2 * difficulty should work fine.

Then maybe I am not understanding what "difficulty" in this example is.  WDC difficulty is 1.62864385 (or it was when I made my OP).  How do you correlate that to number of shares ?
More likely I'm unfamiliar with the WDC terminology. In Bitcoin and Litecoin the average number of (difficulty-1) shares per block is equal to the difficulty. If in WDC it is difficulty*65536 then by all means you should multiply by 65536.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
the1silverwolf (OP)
Member
**
Offline Offline

Activity: 112
Merit: 10



View Profile
May 30, 2013, 07:45:30 PM
 #10

It needs to be based upon the block difficulty at the time.
Well, that's not the correct way either. Every share needs to be scored based on the difficulty at the time it is submitted, see https://bitcointalk.org/index.php?topic=39832.0.

The fact that in scrypt the hashrate is lower is irrelevant. You'll want the window to be a few times larger than the time to find a block, 2 * difficulty should work fine.

Then maybe I am not understanding what "difficulty" in this example is.  WDC difficulty is 1.62864385 (or it was when I made my OP).  How do you correlate that to number of shares ?
More likely I'm unfamiliar with the WDC terminology. In Bitcoin and Litecoin the average number of (difficulty-1) shares per block is equal to the difficulty. If in WDC it is difficulty*65536 then by all means you should multiply by 65536.

It should be the same as litecoin.  Most of the altcoins are clones of litecoin.  But current litecoin difficulty is 602.33824219 which would make the lastNvalue 1,204.  That can't be right though.

--
the1silverwolf
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1054



View Profile WWW
May 30, 2013, 07:57:25 PM
 #11

It needs to be based upon the block difficulty at the time.
Well, that's not the correct way either. Every share needs to be scored based on the difficulty at the time it is submitted, see https://bitcointalk.org/index.php?topic=39832.0.

The fact that in scrypt the hashrate is lower is irrelevant. You'll want the window to be a few times larger than the time to find a block, 2 * difficulty should work fine.

Then maybe I am not understanding what "difficulty" in this example is.  WDC difficulty is 1.62864385 (or it was when I made my OP).  How do you correlate that to number of shares ?
More likely I'm unfamiliar with the WDC terminology. In Bitcoin and Litecoin the average number of (difficulty-1) shares per block is equal to the difficulty. If in WDC it is difficulty*65536 then by all means you should multiply by 65536.

It should be the same as litecoin.  Most of the altcoins are clones of litecoin.  But current litecoin difficulty is 602.33824219 which would make the lastNvalue 1,204.  That can't be right though.
You're right, I see now that Litecoin pools too use fractional difficulty shares (https://github.com/litecoin-project/litecoin/wiki/Comparison-of-mining-pools). In all cases the average number of shares per block is (Difficulty / share difficulty) so your N will be X * (Difficulty / share difficulty).

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
the1silverwolf (OP)
Member
**
Offline Offline

Activity: 112
Merit: 10



View Profile
May 30, 2013, 08:10:00 PM
 #12

It needs to be based upon the block difficulty at the time.
Well, that's not the correct way either. Every share needs to be scored based on the difficulty at the time it is submitted, see https://bitcointalk.org/index.php?topic=39832.0.

The fact that in scrypt the hashrate is lower is irrelevant. You'll want the window to be a few times larger than the time to find a block, 2 * difficulty should work fine.

Then maybe I am not understanding what "difficulty" in this example is.  WDC difficulty is 1.62864385 (or it was when I made my OP).  How do you correlate that to number of shares ?
More likely I'm unfamiliar with the WDC terminology. In Bitcoin and Litecoin the average number of (difficulty-1) shares per block is equal to the difficulty. If in WDC it is difficulty*65536 then by all means you should multiply by 65536.

It should be the same as litecoin.  Most of the altcoins are clones of litecoin.  But current litecoin difficulty is 602.33824219 which would make the lastNvalue 1,204.  That can't be right though.
You're right, I see now that Litecoin pools too use fractional difficulty shares (https://github.com/litecoin-project/litecoin/wiki/Comparison-of-mining-pools). In all cases the average number of shares per block is (Difficulty / share difficulty) so your N will be X * (Difficulty / share difficulty).

Ok, ok.  so to put the share difficulty and the block difficulty in the same range I will multiply the difficulty by 65536 and compare to difficulty 16 shares (in the same scale as reported by cgminer) as generated by the server.

So the formula would be 2 * (BlockDiff / ShareDiff) (Difficulty values are used as reported by cgminer)

the result would be 2 * (106,734.80 / 16) = 13,341.85

Round it up to 13,342 and use that for the lastNshares value.  Is that correct ?

--
the1silverwolf
niteryder
Full Member
***
Offline Offline

Activity: 196
Merit: 100


View Profile
May 30, 2013, 08:18:39 PM
 #13

It needs to be based upon the block difficulty at the time.
Well, that's not the correct way either. Every share needs to be scored based on the difficulty at the time it is submitted, see https://bitcointalk.org/index.php?topic=39832.0.

The fact that in scrypt the hashrate is lower is irrelevant. You'll want the window to be a few times larger than the time to find a block, 2 * difficulty should work fine.

Then maybe I am not understanding what "difficulty" in this example is.  WDC difficulty is 1.62864385 (or it was when I made my OP).  How do you correlate that to number of shares ?
More likely I'm unfamiliar with the WDC terminology. In Bitcoin and Litecoin the average number of (difficulty-1) shares per block is equal to the difficulty. If in WDC it is difficulty*65536 then by all means you should multiply by 65536.

It should be the same as litecoin.  Most of the altcoins are clones of litecoin.  But current litecoin difficulty is 602.33824219 which would make the lastNvalue 1,204.  That can't be right though.
You're right, I see now that Litecoin pools too use fractional difficulty shares (https://github.com/litecoin-project/litecoin/wiki/Comparison-of-mining-pools). In all cases the average number of shares per block is (Difficulty / share difficulty) so your N will be X * (Difficulty / share difficulty).

Ok, ok.  so to put the share difficulty and the block difficulty in the same range I will multiply the difficulty by 65536 and compare to difficulty 16 shares (in the same scale as reported by cgminer) as generated by the server.

So the formula would be 2 * (BlockDiff / ShareDiff) (Difficulty values are used as reported by cgminer)

the result would be 2 * (106,734.80 / 16) = 13,341.85

Round it up to 13,342 and use that for the lastNshares value.  Is that correct ?



Wouldn't just averaging the shares over the last 10 or more blocks found in a pool be the same?
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1054



View Profile WWW
May 30, 2013, 08:22:02 PM
 #14

Ok, ok.  so to put the share difficulty and the block difficulty in the same range I will multiply the difficulty by 65536 and compare to difficulty 16 shares (in the same scale as reported by cgminer) as generated by the server.

So the formula would be 2 * (BlockDiff / ShareDiff) (Difficulty values are used as reported by cgminer)

the result would be 2 * (106,734.80 / 16) = 13,341.85

Round it up to 13,342 and use that for the lastNshares value.  Is that correct ?
Sounds right. But again I'd prefer it if people used the accurate variant to prevent difficulty retarget hopping.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
the1silverwolf (OP)
Member
**
Offline Offline

Activity: 112
Merit: 10



View Profile
May 30, 2013, 08:35:52 PM
Last edit: June 10, 2013, 08:52:48 PM by the1silverwolf
 #15

Ok, ok.  so to put the share difficulty and the block difficulty in the same range I will multiply the difficulty by 65536 and compare to difficulty 16 shares (in the same scale as reported by cgminer) as generated by the server.

So the formula would be 2 * (BlockDiff / ShareDiff) (Difficulty values are used as reported by cgminer)

the result would be 2 * (106,734.80 / 16) = 13,341.85

Round it up to 13,342 and use that for the lastNshares value.  Is that correct ?
Sounds right. But again I'd prefer it if people used the accurate variant to prevent difficulty retarget hopping.

Well... The payout code does score the shares and it uses that data in it's payout calculations.

The main object of my posting was to fix what I see as the most glaring problem with mmcFE pools payout logic that I haven't already fixed yet, it's that everybody uses a fixed lastNshares value that isn't based upon anything.  it's just an arbitrary value.

worldcoinpool.com for example says they use 100,000 shares.  I don't know if they really do or not but that's what their about page says.  I just wanted to implement a more or less correct dynamic value that will keep pace through difficulty increases and decreases and I believe this will do that for me.

I greatly appreciate your assistance btw.  Can I send you some WDC to thank you ?

--
the1silverwolf
the1silverwolf (OP)
Member
**
Offline Offline

Activity: 112
Merit: 10



View Profile
May 30, 2013, 09:15:10 PM
 #16

Ok, ok.  so to put the share difficulty and the block difficulty in the same range I will multiply the difficulty by 65536 and compare to difficulty 16 shares (in the same scale as reported by cgminer) as generated by the server.

So the formula would be 2 * (BlockDiff / ShareDiff) (Difficulty values are used as reported by cgminer)

the result would be 2 * (106,734.80 / 16) = 13,341.85

Round it up to 13,342 and use that for the lastNshares value.  Is that correct ?
Sounds right. But again I'd prefer it if people used the accurate variant to prevent difficulty retarget hopping.

Well... The payout code does score the shares and it uses that data in it's payout calculations, I have to admit though that I don't fully understand how it's doing that.

The main object of my posting was to fix what I see as the most glaring problem with mmcFE pools payout logic that I haven't already fixed yet, it's that everybody uses a fixed lastNshares value that isn't based upon anything.  it's just an arbitrary value.

worldcoinpool.com for example says they use 100,000 shares.  I don't know if they really do or not but that's what their about page says.  I just wanted to implement a more or less correct dynamic value that will keep pace through difficulty increases and decreases and I believe this will do that for me.

I greatly appreciate your assistance btw.  Can I send you some WDC to thank you ?

Nevermind, stupid question.   I sent 0.1 BTC to the address in your sig.  Thanks for your help.

Transaction sent
ID:d2cef4ca0c0abb39480009413b33153203c2f58dee171f43f30b29c259410f92

--
the1silverwolf
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1054



View Profile WWW
May 30, 2013, 10:08:59 PM
 #17

Nevermind, stupid question.   I sent 0.1 BTC to the address in your sig.  Thanks for your help.

Transaction sent
ID:d2cef4ca0c0abb39480009413b33153203c2f58dee171f43f30b29c259410f92

Cool, thanks!

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!