Topic: Eligius: Reward method POLL: 2011 August (Read 6240 times)

PPLLNS might still be quite hoppable on difficulty borders, as the last [difficulty] shares are still quite long in the pool of last shares (it might however be ok, since they should be worth more anyways) - I'd suggest having PPLNS with share scoring as suggested by Meni:

• N = the multiplier to global_difficulty (for example 2 or
• Record global difficulty for each share.
• Each share gets a score of 1/global_difficulty
• On payouts: Pay the most recent shares whose sum of scores <= N relative to their normalized score (so if N = 5 and the score is 1/10 --> 1/50th of a block payout, meaning currently 1 BTC)

BitcoinTalk forum stupidly disabled the ability to change votes when I added the new option for PPLLNS on the other poll, so we'll have to start over

Part time miners is the reason why I won't go N < diff*2. That is 86% CDF... maybe not enough.

I'm adding a new option: Pay Per Last Limit-N Shares. PPLLNS differs from PPLNS in that when the difficulty changes upward, N gradually increases as shares arrive, and older shares are not "reinstated" into the N. So if the difficulty goes from 100 to 200, the first share at the new difficulty will be at N=101, the next at N=102, until N reaches 200. This new option will be available for voting with N=diff*8. This gives 99.96% CDF (probability of finding a block). This means when you submit a share, it will be paid a 8 times less than PPS, 8 times more often on average.

Pay Per Last N Shares might encurage miners to continueously mine, but it will also drive away part time miners.

One of the reasons Eligius is popular is because it offers free PPS rewards.  This is atractive for its low variance, but also to part time miners, and as a backup pool, and for pool hoppers to come to on long blocks as a fallback pool.  Switching to PPLNS could drive away all of those users, and their hashing power.

I can see the problem in this scenario. But what's the chance of that happening in reality given the current environment? I don't think it's possible for difficulty to jump by even 100% since that implies total network hash just doubled and stayed that way for like 7 days? Much less 400%.


That's what I usually do, faster to program than to figure out the maths, especially when my paperwork is more prone to errors

I am aware of that.

However, consider the following example:

Difficulty = 10, new difficulty = 40 (max. increase)

Suddenly 3*old_difficulty-1 shares are able to get paid again once the difficulty changes. If the first share in the new difficulty solves the block, 1 share of diff40 + 39 shares of diff10 get paid. This is the reason why lower global difficulty shares need to be valued lower (by scoring with the difficulty they were mined with) than the new ones (or shares submitted at the very end of a difficulty round get more valuable) as they already had their fair chance of being paid.

If N would be a constant 10, it would always be the last 10 shares who get paid, but then as difficulty increases it gets less and less likely that you get paid for a share - if you get paid though, you get paid more --> variance increases.
If N changes with the difficulty, you include some shares multiple times once difficulty (and N) increases, so you need to either weigh them or maybe(?) let N grow with shares submitted, not at once (the first share @diff40 increases N to 11, the next share to N=12 etc. until N=40 is reached).

I guess I just need to write a small program that simulates a pool + some miners and then plots the payments, might be faster than me doing the full maths.

1. Don't confuse the reward system with the payout system.
2. As I said earlier, voting is specifically for the reward system, and one should assume the payout system will be written to fit it.

As it is now, the buffer is part of the reward system and entirely unrelated to the payout system. It is allocated to miner balances on long rounds, and is paid out eventually. The fact that with the current mismatched reward/payout systems this creates a backlog is unrelated to the fact that it does exist and work, just creating a slight delay (IIRC it was always under 3 days even during our worst dry period).

The buffer never pays out, that's what I mean by it doesn't exist.
The coins exist in Eligius' wallet, but it never sends them, it only pays via generated coins.
If there isn't a backlog of users to pay with the generated coins the excess goes into that wallet.  In theory the next time there is a backlog the wallet pays it out.  That's what is shown on the Eligius statistics page with the block wallet funds listed (here), but if you actually look at the payments the server wallet never sends anything at all, despite what that statistics page says.
Check out one of the blocks where it says it paid out >50btc and the "server funds" column went down, you'll find that it paid out 50 with generated btc, and nothing more.

Lack of too many unlucky rounds and the fact there have been plenty of low-percentile fast rounds.

How so?  If you're never paying out with the buffer, only the generated coins from a block?

I think it was already mentioned, in short rounds, PPLNS may reward miners multiple times for the same share. So if you stick with the pool throughout, the chances of that increases, hence encouraging people sticking around even on a long round since the next one might be a short one and you get paid again for those shares in the long round.

Because, if difficulty grows, you re-include some shares at the end of the last difficulty back into your last N shares. This might be exploitable(?).

Why shouldn't it be flexible? After all, as difficulty goes up, the expected number of shares increases. If we want to reward people who stuck through a full expected round, then the reward window of N shares should also adjust accordingly.

Why is your "N" in PPLNS flexible and not a constant (ideally a multiple of 50)?

I would vote for PPLNS with N being 5-10 million or so...

To be honest I'm not even sure why you are still considering methods that don't pay exactly 50 BTC per round. This will inevitably require a delay in some payments and an additional layer of complexity both in the code and for miners. Because, of course, we can only pay 50 BTC a round if you absolutely want to pay with generated coins.

Proportional / Pay Per Share seems like it is guaranteed to always payout less to miners, since it discards extra credit.  Since all the other PPS methods payout at PPS if there is a buffer, and all the methods other than PPPS retain your work done as extra credit (at least to some extent.) PPPS will never be able to catch up and will always be the lowest total payout method.

Well, prior to the current high, the previous buffer high was also around 513 BTC, which went down by to as low as 116BTC before climbing back up to the current 514 BTC. A swing of 400BTC is not a silly amount if you ask me

No, the current setup is SMPPS with a buffer currently at 514 BTC.

What needs to remembered is that the current setup is cranking along at 500Ghash with no buffer at all, ever.
Yet it seems to be successful, making the whole buffer issue discussion look a bit silly.

Given the past performance of eligius with a 50 coin per block max payout and no capability for a positive buffer balance (the "server funds" column on the website means literally nothing), I don't think it's really worth worrying about.

Really given that, the payout per share could be larger if the short blocks actually paid into a positive buffer when there wasn't a balance owed to miners.

No. CPPS* always offers full PPS for each share when it's submitted. Only when the buffer + current block funds are exhausted does it begin discarding or moving the oldest current-round shares to the future "backpay queue", to make sure it can continue to offer full PPS to the current miners.

The whole point of CPPS* is that past history has no bearing on present or future earnings.

I see what you mean, because of what happens on short rounds. But the variants are no better - when there's a buffer there's a buffer against bad pool luck and you have a better chance of getting 100% of your share's worth. When lots of people have backpay waiting on long rounds you'll be getting paid only for a part of your work. So based on previous performance you can see that your expected value is lower due to bad previous pool luck and you would avoid the pool. So after a long streak of bad luck there would be no point in mining the pool when you're expecting maybe 90% of PPS on a long block and only 100% on a short block

with PPLNS you'd be getting 80%-120%, so more variance, but previous performance has no bearing on your decision whether to mine the pool or not

That doesn't make sense. People are more likely to hop off with straight CPPS than with the variants thereof.

straight CPPS is better, you don't want people mining only when there's a large buffer and hopping off when it seems that the buffer is getting small

I voted for PPLNS, although a low-fee pure PPS wouldn't be too bad either.

Even better if you could somehow select which payment mode you prefer.

The closest match in this poll to the current setup is ESMPPS

I like the current setup, ideally the change would be to use the "server" funds to pay outstanding balances as well as the 50btc from blocks.
It'd be perfect at that point IMO.

No, because on short rounds, the extra goes toward the N on future rounds in a buffer. Also, straight CPPS isn't being considered, just the CPPSB and CPPSEB variants.

capped pay per share is the same as PPNLS that pays each share only once (the variant that goes back and pays the unpaid shares instead of double paying the same shares) and N = difficulty

Inb4 Meni Rosenfeld saying "PPLNS is the only one worth choosing".

Oh, true, people might be mistaking it for the regular proportional. It's named in a way that might confuse people.

Well, maybe the hoppers are all voting

I can't quite understand why people vote for PPPS... It's the only one I didn't vote for myself.

Luke, if you do end up implementing PPPS as the reward system, make sure you have an easy way to switch it to ... well, any one of the others.

Well, I mean if the pool survives the block. Once the block is over, might as well come back.

I might be wrong about this but I imagine PPPS would actually rebuild it's buffer slower due to the fact that all the "sensible" miners will have left as soon as the pool looks like it will go into the negatives. The resulting mass-exodus will cut down the pool's hashing rate and prolong the time it takes to find future blocks.

CPPSRB would fit with the existing names better.

I think I intentionally left RSMPPS off the poll, and voted for PPLNS and CPPSB

There is a significant risk when PPPS is negative, but the upside is that it gets to rebuild a buffer sooner rather than trying to pay people off first and possibly getting even further into the negative. So in theory, it might stay on the up-side more often than a *MPPS or CPPS*B method.

Yes.  

Regarding Proportional / Pay Per Share isn't it the case that once the pool is in a round that has taken it into the negative, that there is no incentive to stay at the pool.  i.e. As long as there is at least one other pool somewhere that is not in the same situation, it makes sense to hop to them because staying at Eligius when the pool's funds are exhausted means getting paid possibly significantly below "normal reward per share" with no counterbalance mechanism in future rounds.  

It's not as obvious in the sample graphs because the unlucky streaks are mostly at the end and the graphs don't show what happens if those 14 days were followed by 2-3 days of better than average luck.  All of the schemes other than Prop/PPS would have shot back up and gotten close to the overall theoretical PPS line, but Prop/PPS would have stayed 1.5 BTC below that line forever.

Bailing on a Prop/PPS pool when it goes negative is a different kind of hopping than 43% hopping that doesn't harm the other miners on the pool by taking earnings out of their pockets.  That said, if everyone does it, then the pool shrivels up and dies if even a 3-4 day long bad luck streak ever happens.  What am I missing?  I feel like I must be missing something since so many people are voting for it.

I'd like to propose a variant of CPPS that borrows from RSMPPS. Maybe call it RCPPS.
This variant will pay out full PPS pay to the most recent unpaid X shares, where X is the difficulty. So every time a block is found, the last X shares that were not paid will be paid. If the latest round is a short round, most recent unpaid shares from previous rounds (if any) will be paid.

This does a better at focusing on the current and future miners. The downside is that pool needs to keep track of more info about each share.

Luke-Jr, what do you think?

PPLNS is the only one that pays more when pool has good luck, right?

For now, let's assume the payout system will be rewritten to match the reward system.

Any thoughts on recoding the payout system as part of this? 

Knowing if payouts would still be exclusively via ~50 BTC generate txs or if you are looking at mixing in (or otherwise using in some automated way) sendmany txs will make a difference in which reward methods I would vote for.

BitcoinTalk Forum has screwed up the poll. Please vote on the new one here.

Please:

• vote your preference(s) for Eligius's next reward method (you can choose more than one!)
• only vote if you at least intend to use Eligius after the change (assume your vote is chosen)
• only vote if you understand the different reward methods, and shortcomings of each method

There is presently no planned date or ETA for this change: it may happen next week, next month, or never.

Summaries:

• Pay Per Last N Shares
• Pay Per Last Limit-N Shares
• Equalized Shared Maximum Pay Per Share
• Proportional / Pay Per Share
• Capped Pay Per Share with Backpay
• Capped Pay Per Share with Equalized Backpay

See also: Real-world example graphs for most payout methods