Topic: Eligius Miners: [POLL] Proposed changes to Eligius Reward System - page 4. (Read 11689 times)

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

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

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

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

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

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.

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

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

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


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

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.

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

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

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.

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

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

Because they are better.

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

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