Quote from: wmabern on April 14, 2016, 09:46:24 PM

I wasn't necessarily advocating for longer shifts ( I don't think I was, or not in the way I'm thing about it). Maybe I was and didn't even know it

.

I was looking at something like increase the number of payable shifts from say the current 10, to maybe 12 or 15. I don't know if that would be considered making the shifts longer or how that would effect payouts. I'm a newbie to all of this, so I don't really understand how changing one part of the system would have an effect on another part of the system or the users of the pool.

If someone has a few minutes, and could enlighten me in simple-mans English and in just few paragraphs or two, I would greatly appreciate it.

When I hear the term "lengthening the shifts", I think of increasing the time it takes for one complete shift (which currently has been hovering around 5 to 6 hours depending on the hash being put it to the shift) being increased to 8 or 10 hours or something like that to hit 100%.
That wasn't what I was talking about or intending.

The thoughts I'm having is to leave the 5-6 hours it takes to complete a shift untouched so you are still completing the shift counter in the same amount of time as before (until the shift counter reads 100%.) (And at ~5-6 hours)
BUT,
Instead of completed shift work being rolled off the "Still eligible for pay" table after 10 shifts (~55-65 hours), we keep those shifts eligible for pay for, maybe, 2 or 5 more shifts.

Is that what you mean when you say "lengthening the shifts" (because the wording confuses me) and I'm just looking at it in some weird, odd way??
Or, does it make a difference if that is done and does it take longer for payouts or cause lower amounts of payouts?

Please, someone in the know please enlighten me as what the damages would be and why what I propose is such a bad idea. I'm just trying to understand.
Please explain in simple English, (please) as it has taken me 30 minutes or more to type out what I think I'm trying to say. LOL
As I'm not sure if what I typed out was what I have meant to type say anyway! Grin

Thanks for any and all insights!!!

It is common for pools that use PPLNS to set N equal to the network difficulty. That is because the average number of shares to find a block is equal to the network difficulty. BitMinter uses the PPLNS with shifts method and the number of shares paid over all shifts is approximately equal to the current difficulty.

Now, if we increase the shift size or the number of shifts while holding the other value constant, the number of shares paid will be greater than the average number of shares to find a block and the amount paid per share will be less. You appear to be advocating for this type of change. Is there any particular reason you want to increase the number of shifts?

I believe that there are valid arguments for a pool to set the number of shares paid to a value greater than, less than, and equal to the network difficulty. In our case, a pool with low overall network hashrate, I believe we should set N equal to or less than the network difficulty.

I refrained from explaining PPLNS with shifts further as it adds nothing to the overall discussion, but if you wish we can discuss that as well. As an aside, PPLNS with shifts is also sometimes referred to as Pay Per Last N Groups (or shifts) PPLNSG. Yes, I know the acronym looks wrong. It is not my acronym.