A proposal for Recent Shared Maximum PPS

[coblee]

Recently, I've been trying to find a pool that has the most fair payout system that deters pool hopping. Slush system works ok but it's really bad for people that are not doing this 24/7. Deepbit deters pool hopping but the delayed statistics is annoying. I came across Eligius' Shared Maximum Pay Per Share (SMPPS - http://eligius.st/wiki/index.php/Shared_Maximum_PPS) model. This model works well but I believe there is a flaw. When the pool is running lucky, all is good. But when the pool is running unlucky, there is less incentives for people to join the pool because they know that they will not get their full PPS reward because a part of the earnings will need to be shared with other users that were owed rewards from previous unlucky blocks. This could potentially lead to a vicious cycle where if the difficulty increases and the pool's hashrate does not increase to match, the pool will earn less BTC and would not be able to cover the previous debt.

For example, imagine if a SMPPS pool is unlucky and currently running a 100 BTC deficit. Why would I want to join this pool? For every 1 share I contribute, I would have to likely share it with 2 others for the 50 BTC earned. Let's say the next round is an average round. The pool earns 50 BTC, but since the deficit is now 150 BTC, I will only get a third of the payout right away and need to wait for the rest… assuming I will eventually get them. So why not just join a SMPPS pool that is currently lucky? That way, I will get all the PPS rewards that I contribute. I believe this leads to pool hopping not due to long rounds, but due to lucky/unlucky pools.

I have a proposal for a better PPS system that I'm calling Recent Shared Maximum PPS or RSMPPS. The idea is simple. It's basically SMPPS, but instead of paying out the reward to all unpaid PPS proportionally, RSMPPS will favor recent blocks. So it will first proportionally pay out the unpaid PPS for the current block (the one that was just found). If there are any remaining rewards, it will pay them out to the next recent block that has unpaid PPS shares. It will keep doing that by paying out unpaid PPS shares from earlier and earlier blocks until all 50 BTC are paid out. If there are any left, it will keep those for the next unlucky round. This system will have no disadvantage for new miners joining the pool, because rewards will be first paid to the people that actually worked on the current block. So there's no debt burden on new users. And old unpaid PPS shares will get paid out if the pool gets lucky enough. With this system, it's possible for the pool to never get lucky enough to pay out really old unpaid shares. I think that's fair.

What do people think?

[1715178004]

1715178004

[1715178004]

1715178004

[1715178004]

1715178004

[error]

I think people should run like hell from any system that delays payment for any reason other than "120 confirmations".

[simplecoin]

Why not just use a pool that uses the cheat-proof method... It discourages pool hopping, but doesn't devalue shares of intermittent use.

My pool pays out at 120 confirms for each round, discourages pool hopping, but doesn't hold funds.

[coblee]

Which cheat-proof method? The one that delays stats do you don't know you are in a long round?

[simplecoin]

Which cheat-proof method? The one that delays stats do you don't know you are in a long round?

No, search for cheat-proof on the forums. It has nothing to do with delays, it is a painfully complex scoring method I can't begin to simply explain.

It takes a little extra horsepower to run the calculations, but I use it as it seems most fair (my opinion).

My pool's 30min delay is to keep the load lower on my server since the calculations for cheat-proof are so taxing.

[coblee]

cheat-proof seems too complex though. plus i like having near real time (or just 5 mins) delayed stats if possible.

[Luke-Jr]

RSMPPS was something I considered when I was coming up with SMPPS. The key problem with it is, that cheaters (that is, people who only submit useless valid shares) can avoid taking any of the damage from their cheating. Solve that, and we have a winner

I think people should run like hell from any system that delays payment for any reason other than "120 confirmations".

So, you consider "we don't have the money to pay you more" a bad reason? Every pool does that... SMPPS just makes it rare.

Why not just use a pool that uses the cheat-proof method... It discourages pool hopping, but doesn't devalue shares of intermittent use.

As far as I can tell it doesn't have consistent share values... but more importantly, Python can't handle the huge numbers it was giving me, so I couldn't even get a visual example of what it would do. We had a nice analysis and vote on various systems for Eligius. SMPPS won.

My pool pays out at 120 confirms for each round, discourages pool hopping, but doesn't hold funds.

Eligius pays out at 1 confirm (ie, when it finds the block) usually, pays both pool hoppers and regular miners fairly, and only holds funds that nobody has done the work to earn yet.

[coblee]

RSMPPS was something I considered when I was coming up with SMPPS. The key problem with it is, that cheaters (that is, people who only submit useless valid shares) can avoid taking any of the damage from their cheating. Solve that, and we have a winner

Can you elaborate on the submitting useless valid shares? Does SMPPS solve this?

[twmz]

What do people think?

As far as I can tell, the problem with this approach is that the people who stopped mining may never get paid, at least in the hypothetical scenario you originally laid out as the reason for this system over SMPPS.   The oldest shares only get paid when the pool gets lucky enough to "catch up".  But in that case, this system wouldn't have been needed anyway.

In this scenario, you'll just have pool hopping again.  As soon as any unlucky streak starts, I ought to hop out because I may never get paid for the work I am doing now as these will be the "oldest unpaid shares".  I'm better off finding some other pool that isn't having bad luck and coming back to this one only when it gets lucky again.  This is bad for a pool for the same reason that classic pool hopping is a problem--because if everyone does it. the pool hashrate goes to 0 and the pool dies.

I think what this boils down to is that there is no system in which a small pool with a bad luck streak is a good thing for participants.  In SMPPS, you have the situation you described.  Your RSMPPS has the "abandon an unlucky pool" problem I described.  In your alternative, you proposed, you have the In proportional, you'll have pool hoppers.  In score based, "cheat proof" systems, miners still run the risk of not recovering from the unlucky streak prior to the next difficulty change.

The purpose of pools was to insulate individual miners from the variability of being a small solo miner.  With the difficulty as high as it is, small pools just can't do that no matter what payment scheme they use.

[coblee]

Ewal, you got it wrong. Any work you do now will be the newest shares and will be paid out first. So no reason for you to quit if pool is unlucky.

[twmz]

Ewal, you got it wrong. Any work you do now will be the newest shares and will be paid out first. So no reason for you to quit if pool is unlucky.

No, the scenario is an extended unlucky streak that spans multiple blocks.  The unpaid work I do at the beginning of that unlucky streak is the oldest unpaid work when we're at the end of that unlucky streak.

Let's take a simple example where I have enough has power to earn 1 BTC from PPS work on an average length block.  Say there are 4 double length blocks in a row:

* In block 1, I earn 1.0 BTC, but only get paid 0.5 BTC because the pool doesn't have enough to pay me the full amount.  My unpaid work is 0.5 BTC.
* In block 2, the same happens.  I get paid 0.5 and add another 0.5 BTC to my unpaid work.
* ...etc...

After 4 blocks I have 2.0 BTC in unpaid work.  My 0.5 BTC from block 1 is not paid until the pool has had 4 blocks that are half length rounds and is back to "par" or "even luck".  I would have been better off leaving the pool and going somewhere else where luck was net positive when it was clear in block 1 that the round was long and not coming back until the lucky rounds.  To be clear, I'm not getting "more than my fair share" by doing this, but I am impacting the pool by taking my hash power away.  And if everyone does this, the pool goes to 0 MH/s and dies.

I'm not saying SMPPS is any better than this.  My point is that RSMPPS just has a different problem in the face of a long (days long) unlucky streak.  And the only way to reduce the chances that you don't have a multiple-day unlucky streak is to have enough hash power that you are finding a dozen or so blocks per day so that your luck evens out over the course of a couple days instead of over the course of a couple weeks.

[coblee]

There's no solution for having a long unlucky streak. But in your example, at round 1, you wouldnt know that you will have 3 more long rounds coming, so why would you leave? Any more work you put in rd 1 will be the first to be paid when pool gets lucky again.

[coblee]

And at round 4, you wouldn't leave either because it wouldn't affect whether your unpaid reward from earlier rounds will be paid or not. Your chance of getting paid in full for he new work is the same as when you joined in rd 1.

[twmz]

And at round 4, you wouldn't leave either because it wouldn't affect whether your unpaid reward from earlier rounds will be paid or not. Your chance of getting paid in full for he new work is the same as when you joined in rd 1.

You leave in round 1 for the same reason pool hoppers leave in normal pools:  Because it might be a bad to stay and you know of pools that are in a known better state.  If there is an alternate pool elsewhere that is in a "net lucky" streak, you are better off moving.  It can't be worse there where you are now and it might be far better.  Again, this isn't uniquely true for RSMPPS.  That wasn't my point.

You made my point:

There's no solution for having a long unlucky streak.

[Luke-Jr]

RSMPPS was something I considered when I was coming up with SMPPS. The key problem with it is, that cheaters (that is, people who only submit useless valid shares) can avoid taking any of the damage from their cheating. Solve that, and we have a winner

Can you elaborate on the submitting useless valid shares? Does SMPPS solve this?

Only the one share that gets the pool a block is actually useful. Cheaters can reduce pool luck by refusing to submit those. With PPS, the liability is held entirely by the pool operator. With proportional, MPPS, and SMPPS, the liability is distributed among everyone in the pool. With RSMPPS, that liability is distributed among everyone except the cheater.

[fpgaminer]

I will be interested to see how SMPPS pans out in the long run for eligius; how far off it is from paying off 100% of the shares over a long period of time. I'm curious because there might be enough room for an SMPPS+fees pool that acts like a PPS pool with zero risk to the pool-op.

Under SMPPS+fees the pool would still pay 50/difficulty BTC per share. However, it would include Generation Fees (collected by the pool for processing included transactions) in the pot. If collected generation fees end up being greater than the loss due to cheaters then the pool should accumulate a surplus pot in the long run. A large enough surplus would allow it to act like a PPS pool. The pool-op takes on no extra risk, and only gives up the cost of those fees.

This could also be done by including the normal pool fees, the fees normally taken out of the 50BTC reward by the pool-op as his share for operating the pool. This would accumulate a surplus faster, but at the risk of the pool-op not earning a profit or recouping their costs if the cheater percentage is too high.

By the way, Luke-Jr, are the stats on Eligius's surplus displayed anywhere?

[RandyFolds]

And at round 4, you wouldn't leave either because it wouldn't affect whether your unpaid reward from earlier rounds will be paid or not. Your chance of getting paid in full for he new work is the same as when you joined in rd 1.

If there is an alternate pool elsewhere that is in a "net lucky" streak, you are better off moving.  It can't be worse there where you are now and it might be far better.  Again, this isn't uniquely true for RSMPPS.  That wasn't my point.

A 'net lucky' streak is meaningless. The past hashes and blocks have no bearing on the future, save for their influence on difficulty, which is a global modifier and not significant in your example. I agree that a pool way in the hole is probably a deterrent to people coming in, but paying for the work as it was carried out is as fair as can be, even if it isn't ideal for the newcomer. What would be the incentive to stick around if your money was being paid to someone else? You'd drive away more hashing power that you would attract with a large positive SMPPS buffer.

You keep speaking of lucky streaks as if they are a train you can hop on. They do not exist and probability always wins in the end. You'll get your BTC eventually, as long as the pool op is legit. Remember, if you aren't finding blocks and getting paid, neither are they. They have incentive to square up those shares properly.

If someone has a miner go down while they are at work and can't restart it for ten hours, why should it make their previous PPS hashes of less value? The whole reason for PPS is to reduce the influence of time on the pool overall. Why bring it in again as a penalizing factor?

[coblee]

RSMPPS was something I considered when I was coming up with SMPPS. The key problem with it is, that cheaters (that is, people who only submit useless valid shares) can avoid taking any of the damage from their cheating. Solve that, and we have a winner

Can you elaborate on the submitting useless valid shares? Does SMPPS solve this?

Only the one share that gets the pool a block is actually useful. Cheaters can reduce pool luck by refusing to submit those. With PPS, the liability is held entirely by the pool operator. With proportional, MPPS, and SMPPS, the liability is distributed among everyone in the pool. With RSMPPS, that liability is distributed among everyone except the cheater.

I don't get it. If the cheater refuses to submit the winning share, would he be able to submit it elsewhere and get the 50 BTC? If not, is he just doing this to screw over the pool? Why would the liability not be distributed to the cheater in case of RSMPPS?

[Luke-Jr]

RSMPPS was something I considered when I was coming up with SMPPS. The key problem with it is, that cheaters (that is, people who only submit useless valid shares) can avoid taking any of the damage from their cheating. Solve that, and we have a winner

Can you elaborate on the submitting useless valid shares? Does SMPPS solve this?

Only the one share that gets the pool a block is actually useful. Cheaters can reduce pool luck by refusing to submit those. With PPS, the liability is held entirely by the pool operator. With proportional, MPPS, and SMPPS, the liability is distributed among everyone in the pool. With RSMPPS, that liability is distributed among everyone except the cheater.

I don't get it. If the cheater refuses to submit the winning share, would he be able to submit it elsewhere and get the 50 BTC? If not, is he just doing this to screw over the pool? Why would the liability not be distributed to the cheater in case of RSMPPS?

Yep, pretty much just to screw the pool. So long as the cheater is careful going about it, he gets paid full PPS with no penalty under RSMPPS. I won't elaborate, as I don't care to encourage it.

[anodyne]

By the way, Luke-Jr, are the stats on Eligius's surplus displayed anywhere?

I'm not Luke-Jr, but I have the answer anyway, with the pool's block stats page: http://www.eligius.st/~artefact2/blocks/