Author

Topic: Proper PPLNS lastNshares calculation for script based coin pools - SOLVED (Read 1664 times)

donator
Activity: 2058
Merit: 1054
Nevermind, stupid question.   I sent 0.1 BTC to the address in your sig.  Thanks for your help.

Transaction sent
ID:d2cef4ca0c0abb39480009413b33153203c2f58dee171f43f30b29c259410f92

Cool, thanks!
member
Activity: 112
Merit: 10
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
member
Activity: 112
Merit: 10
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 ?
donator
Activity: 2058
Merit: 1054
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.
full member
Activity: 196
Merit: 100
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://bitcointalksearch.org/topic/pplns-39832.

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?
member
Activity: 112
Merit: 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://bitcointalksearch.org/topic/pplns-39832.

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 ?
donator
Activity: 2058
Merit: 1054
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://bitcointalksearch.org/topic/pplns-39832.

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).
member
Activity: 112
Merit: 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://bitcointalksearch.org/topic/pplns-39832.

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.
donator
Activity: 2058
Merit: 1054
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://bitcointalksearch.org/topic/pplns-39832.

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.
member
Activity: 112
Merit: 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://bitcointalksearch.org/topic/pplns-39832.

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 ?
donator
Activity: 2058
Merit: 1054
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://bitcointalksearch.org/topic/pplns-39832.

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.
member
Activity: 112
Merit: 10
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 ?
full member
Activity: 196
Merit: 100
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.
member
Activity: 112
Merit: 10
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.
legendary
Activity: 3108
Merit: 1359
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".
member
Activity: 112
Merit: 10
member
Activity: 112
Merit: 10
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.
Jump to: