Eligius Miners: [POLL] Proposed changes to Eligius Reward System

[wizkid057]

THIS POLL IS NOW SUPERSEDED BY THIS NEW POLL:
https://bitcointalk.org/?topic=100301

Please cast your votes on the new poll. Thanks.

------


After many discussions on IRC, I am putting to vote a change to the Eligius miner reward system.
I would prefer that, on the honor system, only Eligius miners with some amount of EC on their address vote on this poll.

This is a two part proposal.  Please read carefully!


Background/Reasoning:
As of now, the pool has accrued a substantial amount of "extra credit" under the SMPPS system.  This is causing reward payouts for active miners to be significantly lower than 100% PPS.
From what I can tell, a large portion of the "extra credit" is being slowly paid to miners who have stopped mining at the pool entirely, thus slowing the reward payout for active miners who are currently supporting the pool.

I believe that miners who support the pool through good and bad luck times should be rewarded and have a good chance of reaching 100% PPS.  Recently, due to the pool's run of bad luck, many miners have left the pool.  This makes it much harder for the remaining miners to catch up and pay the extra credit to the inactive miners, potentially to the point where it becomes statistically improbable.  These proposals, if adopted, should provide a system which makes mining at Eligius, even during bad luck times, more reasonable and more enticing than the system as it exists now.

On a personal note, I recommend voting YES to both proposals.  I believe that these changes will make the pool more viable in the long term and give miners, new and old, more incentive to mine at the pool.

----

Part 1
For the first part of this proposal, I propose that extra credit payments NOT be made to miners who are not actively mining at the pool.  Further, I propose that extra credit reward payouts be adjusted like so:

• Miners who have an extra credit balance may not be paid more extra credit in a round than they have earned normally for the round. (For example, if you have 1 BTC in EC, and you mine 0.1 BTC in shares, the biggest reward payout you can get from that block would be 0.2 BTC (your earnings plus and equal amount of your extra credit)).
• The extra credit that is not able to be paid to a miner (inactive, low hash rate, etc) under this system will be added to the available funds for paying active miner extra credit.

This setup rewards active miners during unlucky times (such as now) over those who have stopped supporting the pool.

If you believe this is reasonable, then vote "Yes EC Limit".

For details on SMPPS please see http://eligius.st/wiki/index.php/Shared_Maximum_PPS.

-----

Part 2
As the second part of this proposal, I propose that Eligius switches to a reward system based on CPPS with backpay rather than SMPPS.  On average, this should get miners the same amount as SMPPS.  The advantage is that even when the pool is having a run of bad luck, when the pool is lucky for even one block, you will get 100% PPS for that block.

Please read http://eligius.st/wiki/index.php/Capped_PPS for details on CPPS.

I propose that if you agree with the above proposal AND CPPS with backpay that Eligius implement "CPPSBAM" as described in the link above, which rewards only active miners.
If you agree with CPPS with backpay, but not only for active miners, then I propose we use "CPPSEB" as described in the link above.

For the vote, if you agree with CPPS with backpay, please vote an option with "Yes CPPS".

----

Any questions or clarification please post or see us on freenode in #eligius.  I'd be happy to answer questions.

Thanks!

-wk

P.S. - I just want to point out to clear up some misunderstandings that no miners will ever lose any earned extra credit under any of the proposed reward systems.  *Please* read http://eligius.st/wiki/index.php/Capped_PPS#CPPS_with_Backpay_for_Active_Miners_.28CPPSBAM.29 carefully!  It specifically explains that even inactive miners never lose their extra credit under CPPSBAM.

Edit: Clarification that this is for the miner reward system (initially ambiguously referred to as payout system)
Edit: Added P.S. to emphasize CPPSBAM does not mean losing extra credit.

[roomservice]

You should consider reading this carefully:
https://bitcoil.co.il/pool_analysis.pdf

[Luke-Jr]

You should consider reading this carefully:
https://bitcoil.co.il/pool_analysis.pdf

Keeping in mind the author is trying to make specific reward systems look better than others.

[rjk]

You should consider reading this carefully:
https://bitcoil.co.il/pool_analysis.pdf

Keeping in mind the author is trying to make specific reward systems look better than others.

Because they are better.

[wizkid057]

You should consider reading this carefully:
https://bitcoil.co.il/pool_analysis.pdf

Keeping in mind the author is trying to make specific reward systems look better than others.

Because they are better.

I agree that this article does seem biased, and not just because of the numbers.

In any case, the numbers generally don't lie, and I've written a simulation to test many payout methods before proposing these changes.

For my personal analysis:
SMPPS will always fail, statistically, just because any disruption in income will cause a "loss" that is statistically impossible to recover in the long term.  It is also not statistically compatible with the block reward halving while in EC mode.
Proportional is just flat out off the list due to obvious exploits of the system (hopping).
PPLNS has the same drawbacks as proportional except they're slightly offset for longer blocks.  Can still hop on short blocks.
The score systems and other such systems seem to be tailored to the pool operator's profit, IMO.
CPPS variants are reasonable, as they mostly solve the problems of lowering variance, hopping, and miner loyalty.

The issue with all payout systems is that disruptions in the income from blocks (orphans, mainly) throw off the equilibrium that is the heart of the SMPPS/CPPS/PPS/etc systems.  This is why I propose that inactive miners not be paid their backpay if they are not mining for the pool.  This gives the pool as a whole a small way to offset those disruptions by freeing up funds to pay backpay/extra credit during unlucky times.  Without some way of doing so, all "100% PPS" systems will eventually fail, statistically.  

For example, if you bet any number in roulette in any large number of spins with no 0 or 00, on average, you'll break even.  However, throw in even one of the 0 or 00 (to equate to bitcoin, orphaned blocks) and on average, you'll lose no matter what.  http://en.wikipedia.org/wiki/Law_of_large_numbers

-wk

[rjk]

I don't think the paper specifically references CPPS, and I haven't heard of it until now either, so I must assume it is something that has been developed recently. I will reserve judgement on it specifically for that reason until I can learn more about it.

[wizkid057]

I don't think the paper specifically references CPPS, and I haven't heard of it until now either, so I must assume it is something that has been developed recently. I will reserve judgement on it specifically for that reason until I can learn more about it.

No, that paper does not specifically mention CPPS, however, I do not believe it is new.  The specific page I linked describing it was created about a year ago.
 It is a no-pool-risk low variance payout method, so, I suppose it would fall into whatever category in that paper you should see fit.

In my simulations, I pitted CPPS against SMPPS and CPPS always had a much higher chance of pulling out of a rut than SMPPS, mainly since the buffer was never grown substantially since on even or lucky rounds all miners are already fully paid.  SMPPS plays a lot of catch up.  Tacking on the CPPSBAM variant gives the pool a way to have even better odds of keeping a positive buffer for miner payouts.

-wk

[SiegeBreaker]

One comment about part /1/: I agree it is beneficial to limit paying extra credit to active miners first, but I would advise caution on how to classify 'inactive' miners. I use this pool as a backup pool, so my average hashrate is very low, and this pool would become useless to me if there was some arbitrary 'active' MH/s threshold other than '> 0'.

I think the best idea from part 1 is to limit the extra credit rewarded in a round to the amount of normal credit earned, this would automatically reward only active users, without any arbitrary minimums. I think it is also a 'fair' approach in that the rate of extra credit is directly proportional to the rate of active mining.

[Meni Rosenfeld]

I know I shouldn't be posting here, but...

You should consider reading this carefully:
https://bitcoil.co.il/pool_analysis.pdf

Keeping in mind the author is trying to make specific reward systems look better than others.

Because the huge royalties I get from all the DGM pools allow me to change the laws of math?

I know there's not much information content in me saying this, but I was trying to make each reward system look exactly as good as it is. The causality is "Hopping-proof is good -> I developed hopping-proof methods", not "I developed hopping proof methods -> I say hopping-proof is good".

SMPPS will always fail, statistically, just because any disruption in income will cause a "loss" that is statistically impossible to recover in the long term.

Which is basically what I've said, and if I understand the thread correctly this is now becoming visible in practice.

PPLNS has the same drawbacks as proportional except they're slightly offset for longer blocks.  Can still hop on short blocks.

This is false, PPLNS is hopping-proof. You probably misunderstood how PPLNS works (or misimplemented it), most likely thinking it only rewards shares from the current round.

The score systems and other such systems seem to be tailored to the pool operator's profit, IMO.

This is false. The expected profit of the pool op in a score method is 0 (if the fee is 0).

The issue with all payout systems is that disruptions in the income from blocks (orphans, mainly) throw off the equilibrium that is the heart of the SMPPS/CPPS/PPS/etc systems.  This is why I propose that inactive miners not be paid their backpay if they are not mining for the pool.  This gives the pool as a whole a small way to offset those disruptions by freeing up funds to pay backpay/extra credit during unlucky times.  Without some way of doing so, all "100% PPS" systems will eventually fail, statistically.

In true PPS the op is paying from his own funds, and it is his business decision what fee to charge to compensate for the losses and risks.

Score-based methods pay out (roughly) according to actually received rewards so they don't have these problems.

I don't think the paper specifically references CPPS, and I haven't heard of it until now either, so I must assume it is something that has been developed recently. I will reserve judgement on it specifically for that reason until I can learn more about it.

I'd heard of CPPS but I can't write about every crazy non-hopping-proof method someone comes up with.


Putting aside the false modesty: I understand math. Most people don't. If you want to follow the parts of my derivations that you can, and take my word for or query the parts that you don't, great. If not that's your choice but I'd appreciate not going around saying I have some malicious agenda.

[imsaguy]

If you're worried about rewarding current miners, then why aren't you suggesting CPPSRB?

[kuzetsa]

My exact vote was:

YES!!! (limit the extra credit)
...Limiting the EC should also deter pool hopping.

No (I guess?) -- do not change from SMPPS to CPPS with backpay
(or do... I don't care about that part)

...either way I'm fine with ANY change that limits the extra credit from being so slow to payout for active, hardworking miners.

[wizkid057]

If you're worried about rewarding current miners, then why aren't you suggesting CPPSRB?

Because that method still does not give the pool a way to catch up in unlucky rounds when miners are leaving the pool.  Sure, it will more readily reward active miners in long stretches of bad luck.

In any case, CPPSBAM does not just throw away extra credit that inactive miners have earned.  It just simply is not paid to them if they are not active.  If they become active again, then they can easily be paid their extra credit as well as normal CPPS reward.  See http://eligius.st/wiki/index.php/Capped_PPS#CPPS_with_Backpay_for_Active_Miners_.28CPPSBAM.29. 

This is also why Eligius as a backup pool is not really effected by CPPSBAM.  you're not losing out on earnings regardless.  You would only be effected at all if you were to mine a lot on Eligius while in extra credit mode (ie bad luck times) and then stop mining completely, which is hitting on the miner loyalty issue CPPSBAM is designed to correct in the first place.

-wk

[wizkid057]

PPLNS has the same drawbacks as proportional except they're slightly offset for longer blocks.  Can still hop on short blocks.

This is false, PPLNS is hopping-proof. You probably misunderstood how PPLNS works (or misimplemented it), most likely thinking it only rewards shares from the current round.

Actually, turns out the document I had initially read on the topic was of an incorrect implementation.  My mistake.  However, it's still able to be hopped in any case, just not as easily or predictably.

-wk

[wizkid057]

I just want to briefly clarify CPPSBAM to those who may misunderstand it.

It is a very fair system.  It keeps a fairly steady flow of reward to active miners. 

In good luck/positive buffer times, this is 100% PPS all the time. 

In bad luck times, it more hastily rewards immediately active miners in a "you can't get more out then you put in" type setup.

The goal of CPPSBAM is to curb what has happened to Eligius over the past several months where the pool hits a little bit of bad luck in SMPPS, miners get a little less on payout due to extra credit and then leaving the pool only to make the loyal miners take longer to have the buffer catch up.  CPPSBAM is specifically designed to reward the loyal miner who stays with the pool continuously.  The "disloyal" miner does not technically lose anything since they can simply mine the pool in lucky times for a quick payout of all extra credit they have.

-wk

[imsaguy]

I just want to briefly clarify CPPSBAM to those who may misunderstand it.

It is a very fair system.  It keeps a fairly steady flow of reward to active miners. 

In good luck/positive buffer times, this is 100% PPS all the time. 

In bad luck times, it more hastily rewards immediately active miners in a "you can't get more out then you put in" type setup.

The goal of CPPSBAM is to curb what has happened to Eligius over the past several months where the pool hits a little bit of bad luck in SMPPS, miners get a little less on payout due to extra credit and then leaving the pool only to make the loyal miners take longer to have the buffer catch up.  CPPSBAM is specifically designed to reward the loyal miner who stays with the pool continuously.  The "disloyal" miner does not technically lose anything since they can simply mine the pool in lucky times for a quick payout of all extra credit they have.

-wk

several months isn't 'a little bit of bad luck'.  perhaps something is broken and that should be addressed before changing the payout system?

[wizkid057]

I just want to briefly clarify CPPSBAM to those who may misunderstand it.

It is a very fair system.  It keeps a fairly steady flow of reward to active miners. 

In good luck/positive buffer times, this is 100% PPS all the time. 

In bad luck times, it more hastily rewards immediately active miners in a "you can't get more out then you put in" type setup.

The goal of CPPSBAM is to curb what has happened to Eligius over the past several months where the pool hits a little bit of bad luck in SMPPS, miners get a little less on payout due to extra credit and then leaving the pool only to make the loyal miners take longer to have the buffer catch up.  CPPSBAM is specifically designed to reward the loyal miner who stays with the pool continuously.  The "disloyal" miner does not technically lose anything since they can simply mine the pool in lucky times for a quick payout of all extra credit they have.

-wk

several months isn't 'a little bit of bad luck'.  perhaps something is broken and that should be addressed before changing the payout system?

Honestly, I don't believe it would have been several months if we maintained the hash rate of the pool at the time the bad luck (orphans) started.  It was a run of orphans that was the cause of the bad luck, then half of the pool left which pretty much increases the time to pull out of the rut insanely.  CPPSBAM works against miners who leave the pool, plain and simple.  If you don't want to mine the pool and support it, then you don't get paid. Easy as that.  If you feel like supporting the pool later, then by all means "unlock" your EC.

-wk

[Meni Rosenfeld]

PPLNS has the same drawbacks as proportional except they're slightly offset for longer blocks.  Can still hop on short blocks.

This is false, PPLNS is hopping-proof. You probably misunderstood how PPLNS works (or misimplemented it), most likely thinking it only rewards shares from the current round.

Actually, turns out the document I had initially read on the topic was of an incorrect implementation.  My mistake.  However, it's still able to be hopped in any case, just not as easily or predictably.

Hopping means some times are better to mine than others and that this can be deduced from the pool's past. In PPLNS the payouts don't depend on the past, only on the future. If hoppers could see the future and tell when blocks will be found, they would be able to hop. But they can't, so they can't. There is no hopping strategy that would give better-than-random payouts. This has been mathematically proven.

I'm not sure what I've done to deserve your distrust, but I honestly spent some time thinking about these things.

Edit: Ok, I will stop derailing the thread. I'll be happy to continue discussing PPLNS in an on-topic thread such as PPLNS.

[Luke-Jr]

several months isn't 'a little bit of bad luck'.  perhaps something is broken and that should be addressed before changing the payout system?

Several months isn't a little bit, but it is within the normal expectations. How many months of a positive buffer did we have? That's no more likely than extra credit.

That being said, there is also the "the bigger the block, the more likely to be orphaned" problem that lost us 6 blocks before being caught. That has been addressed for the short term (making smaller blocks) and I am working on addressing it for the long term (patching the reference implementation to minimize block propagation time regardless of transaction count).

[imsaguy]

Honestly, I don't believe it would have been several months if we maintained the hash rate of the pool at the time the bad luck (orphans) started.  It was a run of orphans that was the cause of the bad luck, then half of the pool left which pretty much increases the time to pull out of the rut insanely.  CPPSBAM works against miners who leave the pool, plain and simple.  If you don't want to mine the pool and support it, then you don't get paid. Easy as that.  If you feel like supporting the pool later, then by all means "unlock" your EC.

-wk

Certainly you aren't saying that hash rate determines luck.  Otherwise, the little miners don't stand a chance.

[imsaguy]

That being said, there is also the "the bigger the block, the more likely to be orphaned" problem that lost us 6 blocks before being caught. That has been addressed for the short term (making smaller blocks) and I am working on addressing it for the long term (patching the reference implementation to minimize block propagation time regardless of transaction count).

Thank you for this.