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.