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?

[1715222327]

1715222327

[1715222327]

1715222327

[1715222327]

1715222327

[1715222327]

1715222327

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

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

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.

With RSMPPS, the liability will be distributed among everyone including the cheater also. Let say if the cheater/saboteur finds a winning share after an average length and decides to not submit that share. The pool goes on and keeps looking. And let say it takes another average length to find another winning share. So because of the sabotage, the cheater turns 2 average rounds into a double length round. And he will only get half his work paid. Whereas if he didn't sabotage, he will get paid his full work for the 2 blocks. So the cheater is being penalized for cheating in the case of RSMPPS also, right?

In the end, I think this is an edge case that we don't need to worry about. In order for a cheater to really have a real effect on a block by sabotaging it this way, he needs to have quite big of a hashrate. I can't imagine someone with such a hashrate spend his time throwing away winning blocks just to sabotage a pool. Just imagine... all those winning shares are worth 50 BTC to himself if he solo mined! Who in there right mind would be so stupid.

[anodyne]

Just throwing out an idea here as well... it's quite unpolished, as I came up with it a couple of minutes ago...  

Would a "tax" on old Max rewards be some sort of compromise? I'm thinking of some sort of system that moves accumulated unpaid PPS during longer streaks of bad luck and pays it forward to the the current round... let's say that with two rounds it proceeds as normal, but when the pool goes into the third bad block it starts taking a percentage of the unpaid shares from the first round and adds those to the current round, and if there's a fourth bad round it takes a cut from both round one and two and so on.

That way, the unpaid PPS from those who jump to another pool would gradually be shifted over to those who continue mining.

[coblee]

Just throwing out an idea here as well... it's quite unpolished, as I came up with it a couple of minutes ago...  

Would a "tax" on old Max rewards be some sort of compromise? I'm thinking of some sort of system that moves accumulated unpaid PPS during longer streaks of bad luck and pays it forward to the the current round... let's say that with two rounds it proceeds as normal, but when the pool goes into the third bad block it starts taking a percentage of the unpaid shares from the first round and adds those to the current round, and if there's a fourth bad round it takes a cut from both round one and two and so on.

That way, the unpaid PPS from those who jump to another pool would gradually be shifted over to those who continue mining.

Not exactly sure what you mean by this. What does moving unpaid PPS from previous unlucky rounds to current round mean?

[anodyne]

Just throwing out an idea here as well... it's quite unpolished, as I came up with it a couple of minutes ago...  

Would a "tax" on old Max rewards be some sort of compromise? I'm thinking of some sort of system that moves accumulated unpaid PPS during longer streaks of bad luck and pays it forward to the the current round... let's say that with two rounds it proceeds as normal, but when the pool goes into the third bad block it starts taking a percentage of the unpaid shares from the first round and adds those to the current round, and if there's a fourth bad round it takes a cut from both round one and two and so on.

That way, the unpaid PPS from those who jump to another pool would gradually be shifted over to those who continue mining.

Not exactly sure what you mean by this. What does moving unpaid PPS from previous unlucky rounds to current round mean?

I'm thinking about a way of shifting the deficit forward – in practice it would mean that part of the deficit from old rounds would be added proportionally to the maximum rewards in the current round. It wouldn't increase the direct reward, but new and persistent miners would have a chance to get a larger part back when the pool starts to catch up with the deficit again.

[coblee]

So you mean something similar to RSMPPS but also favor unpaid shares from miners who are still active. So if miner A worked on block 1 (a long block) and didn't get fully paid. And miner B worked on block 2 (another long block) and didn't get fully paid. Miner B stopped mining with the pool, but miner A continued mining. When the pool finally starts to get lucky and has enough BTC to pay the unpaid shares from block 2, we might favor paying miner A for his work on block 1 because he's still active instead of paying miner B for his work on block 2.

I think seems ok. It will give people incentive to keep mining and stick with the pool. But I can't think of a good formula that makes this simple to understand and implement. It might turn away miners due to it being too complicated even though the idea behind it is valid.

[anodyne]

Something along those lines, yes. I guess the only drawback is that if the pool would grow quickly during a bad luck period persistent miners would have to share some of their unpaid credits with new miners, but that's still better than the risk of having the pool stall and maybe never recover. It would probably need some weighting based on contribution throughout the whole stint of bad luck.

I agree that it's a bit complicated, and I also feel that while I think the concept has something I would like to see someone with more number skills than me analyze it.

[zubatej]

So you mean something similar to RSMPPS but also favor unpaid shares from miners who are still active. So if miner A worked on block 1 (a long block) and didn't get fully paid. And miner B worked on block 2 (another long block) and didn't get fully paid. Miner B stopped mining with the pool, but miner A continued mining. When the pool finally starts to get lucky and has enough BTC to pay the unpaid shares from block 2, we might favor paying miner A for his work on block 1 because he's still active instead of paying miner B for his work on block 2.

I think seems ok. It will give people incentive to keep mining and stick with the pool. But I can't think of a good formula that makes this simple to understand and implement. It might turn away miners due to it being too complicated even though the idea behind it is valid.

It seems similar to MaxPPS, which pays you more than proportional on long unlucky rounds only if you have your own surplus credit from participating in short lucky rounds. This method was also proposed for Eligius, but it gained some negative publicity, because some people mistook its effects as withholding payments by operator.

[Artefact2]

Deepbit deters pool hopping but the delayed statistics is annoying.

Haha. Delaying stats doesn't deter pool hopping at all. It's just masturbation.

[anodyne]

So you mean something similar to RSMPPS but also favor unpaid shares from miners who are still active. So if miner A worked on block 1 (a long block) and didn't get fully paid. And miner B worked on block 2 (another long block) and didn't get fully paid. Miner B stopped mining with the pool, but miner A continued mining. When the pool finally starts to get lucky and has enough BTC to pay the unpaid shares from block 2, we might favor paying miner A for his work on block 1 because he's still active instead of paying miner B for his work on block 2.

I think seems ok. It will give people incentive to keep mining and stick with the pool. But I can't think of a good formula that makes this simple to understand and implement. It might turn away miners due to it being too complicated even though the idea behind it is valid.

It seems similar to MaxPPS, which pays you more than proportional on long unlucky rounds only if you have your own surplus credit from participating in short lucky rounds. This method was also proposed for Eligius, but it gained some negative publicity, because some people mistook its effects as withholding payments by operator.

No, it's still the same shared risk principle as the current system since only the maximum reward credit would be affected. The proportional reward for each long round would stay the same, only the accumulated MaxPPS credits would be pushed forward to benefit those who continue to mine until the pool gets lucky again.

[jkminkov]

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?

why you think "cheaters" will ever join your pool if you use cheat proof scoring method, and your surplus will be leached from miners with network issues

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.

it is not possible to recognize a winning share

[gentakin]

it is not possible to recognize a winning share

[citation needed]

Or an explanation. Miners know the hash, and they know the current target, so they can see if it's a winning share.

[twmz]

it is not possible to recognize a winning share

Sure it is.  You just compare the hash you are about to submit with the real difficulty and not just with the target the pool asked you to use.  If the hash is lower than the real target/difficulty, don't submit the share.

[Meni Rosenfeld]

Anyone with the most basic knowledge of stochastic processes can see that SMPPS is a bad method.

There are two valid hopping-proof methods:

1. Geometric method. Cons: Requires implementation in logarithmic scale, has high (but tunable) variance.
PPS is a limit case of this.

2. PPLNS. Cons: Crosses round boundaries.

It looks like your RSMPPS is trying to take SMPPS and make it more like PPLNS. Better just use PPLNS instead.

(In case people mean the geometric method when saying "the cheat-proof method", please don't. "Cheat-proof" is an adjective, not a name. Better edit the thread I guess.)

[coblee]

Anyone with the most basic knowledge of stochastic processes can see that SMPPS is a bad method.

There are two valid hopping-proof methods:

1. Geometric method. Cons: Requires implementation in logarithmic scale, has high (but tunable) variance.
PPS is a limit case of this.

2. PPLNS. Cons: Crosses round boundaries.

It looks like your RSMPPS is trying to take SMPPS and make it more like PPLNS. Better just use PPLNS instead.

(In case people mean the geometric method when saying "the cheat-proof method", please stop. "cheat-proof" is an adjective, not a name. Better edit the thread I guess.)

I agree that both geometric and PPLNS are pool hopping deterring methods and are fair. But correct me if I'm wrong (since I don't know the geometric method that well), they really only work well for people mining 24/7. If I'm not mining 24/7, I will be unfairly punished for looking like a pool hopper. RSMPPS works better in that case. Each submitted share to RSMPPS will always have the same expected return.

[Meni Rosenfeld]

Anyone with the most basic knowledge of stochastic processes can see that SMPPS is a bad method.

There are two valid hopping-proof methods:

1. Geometric method. Cons: Requires implementation in logarithmic scale, has high (but tunable) variance.
PPS is a limit case of this.

2. PPLNS. Cons: Crosses round boundaries.

It looks like your RSMPPS is trying to take SMPPS and make it more like PPLNS. Better just use PPLNS instead.

(In case people mean the geometric method when saying "the cheat-proof method", please stop. "cheat-proof" is an adjective, not a name. Better edit the thread I guess.)

I agree that both geometric and PPLNS are pool hopping deterring methods and are fair. But correct me if I'm wrong (since I don't know the geometric method that well), they really only work well for people mining 24/7. If I'm not mining 24/7, I will be unfairly punished for looking like a pool hopper. RSMPPS works better in that case. Each submitted share to RSMPPS will always have the same expected return.

You are in fact wrong. Both methods I mentioned give you the same expected return no matter when you submit shares or how intermittent your mining. In fact that's my definition for "hopping-proof" - that your expected payout per share is completely independent on when you submitted it.

However, for the geometric method intermittent miners will have even higher variance.

[Sukrim]

Even solo mining is 100% completely hopping proof and gives the expected reward in the long run.

The real question is, how low can variance be pushed without risking pool bankruptcy or making some shares worth a lot more than others or risking not pying some miners at all (a bad luck streak at a hashing peak with this method would mean if difficulty goes up the miners from back then will probably never be paid at all while a SMPPS pool gets deep into red numbers)

[Meni Rosenfeld]

The real question is, how low can variance be pushed without risking pool bankruptcy or making some shares worth a lot more than others or risking not pying some miners at all (a bad luck streak at a hashing peak with this method would mean if difficulty goes up the miners from back then will probably never be paid at all while a SMPPS pool gets deep into red numbers)

With PPLNS, variance is 0 per block for the operator and very low for the participants. Note that there is also variance created by the pool being too small regardless of the scoring method used.

[Luke-Jr]

The real question is, how low can variance be pushed without risking pool bankruptcy or making some shares worth a lot more than others or risking not pying some miners at all (a bad luck streak at a hashing peak with this method would mean if difficulty goes up the miners from back then will probably never be paid at all while a SMPPS pool gets deep into red numbers)

With PPLNS, variance is 0 per block for the operator and very low for the participants. Note that there is also variance created by the pool being to small regardless of the scoring method used.

Real world data begs to differ

[Meni Rosenfeld]

The real question is, how low can variance be pushed without risking pool bankruptcy or making some shares worth a lot more than others or risking not pying some miners at all (a bad luck streak at a hashing peak with this method would mean if difficulty goes up the miners from back then will probably never be paid at all while a SMPPS pool gets deep into red numbers)

With PPLNS, variance is 0 per block for the operator and very low for the participants. Note that there is also variance created by the pool being to small regardless of the scoring method used.

Real world data begs to differ

Empirical data over 4 days means very little. I'm not sure what you're arguing against but I guess "very low" variance is debatable. It is of course higher than proportional.

[Sukrim]

I just wonder if/how it is a problem that PPLNS can (should!) cross block round and difficulty borders, as some shares can be (re-)considered multiple times at payouts then. I don't see any immediate exploitability though.

To me PPS systems still seem to be tha fairest ones, but with SMPPS or RSMPPS there is a risk involved that some shares will never be paid, if the pool hash rate has a peak at a bad luck streak.

Maybe something like 2-week Prop can be established, where at every difficulty change the depts/earnings get set back to 0 and all miners of this round get paid (proportionally?). Downside: You have to wait 2 weeks (or more) for your mining income and cannot get it earlier until the round is finished, no payment out of generations possible (especially tricky once the amount gets cut in half - i wonder what's eligius' strategy for this btw!). Upside: One of the fairest methods I can think of, hopping proof, easy to explain and implement, no need to patch bitcoind.

As a compromise you could also allow miners to pay out 50%(or more/less?) of their earnings immediately and the other ~45-55% get distributed at each difficutly recalculation.

[Meni Rosenfeld]

I just wonder if/how it is a problem that PPLNS can (should!) cross block round and difficulty borders, as some shares can be (re-)considered multiple times at payouts then. I don't see any immediate exploitability though.

Non sequitur. PPLNS has a valid variant where each share is counted at most once. We go back in history and pay the most recent X shares that were never paid. This does require keeping track of a longer history.

Anyway, there shouldn't be a problem with the multiple-payment variant. It just has some more variance than the one-payment variant.

To me PPS systems still seem to be tha fairest ones,

Oblivious shares + p2pool network built on top of centralized pools = viable PPS with reasonable fees. I hope to see it one day.

Maybe something like 2-week Prop can be established, where at every difficulty change the depts/earnings get set back to 0 and all miners of this round get paid (proportionally?). Downside: You have to wait 2 weeks (or more) for your mining income and cannot get it earlier until the round is finished, no payment out of generations possible (especially tricky once the amount gets cut in half - i wonder what's eligius' strategy for this btw!). Upside: One of the fairest methods I can think of, hopping proof, easy to explain and implement, no need to patch bitcoind.

Maybe I'm not getting it, but this looks to me the opposite of hopping-proof. Wait 10 days, if the pool has been lucky mine for it, if not don't.

[Sukrim]

Maybe I'm not getting it, but this looks to me the opposite of hopping-proof. Wait 10 days, if the pool has been lucky mine for it, if not don't.

You then would only get a few% more than usually (luck swings at btcguild in ~+/-10%) but only in the end of a round. There might still be a chance that the luck evens out, though the likelyhood of this gets lower and lower, the further rounds progress.

In the corner case (all pools have this scheme, all miners hop) as soon as the first block in a difficulty is found, all miners jump to that pool...
In the end I guess to start a pool the best strategy would be to start with proportional, write a pool hop implementation and pray (or fake stats...). After you have a decent hash rate switch to SMPPS or RSMPPS but make sure you don't pay out automatically, to lower your risk of getting bankrupt. You could even do transparent fractional reserving this way.

As some people seem to enjoy a higher variance, you could even implement a lottery, where people can buy tickets (automatically?) with each share submitted - the pot then gets distributed after some time (similar to triplemining but not with fixed 1% and maybe different lotteries, daily/weekly/monthly) amongst all ticket holders. This would give the "gamblers" a better chance to have luck or not (something that some seem to like about prop - at least as long as the pool is lucky! ) while not hurting operators or other miners.

What I don't like at both SMPPS and RSMPPS is that the pool can be in dept a lot out of a sudden bad luck streak with potentially no way to recover ever (imagine having a really bad bad luck streak at the time right before the block reward is cut in half and a lot of miners leave!)

An ideal system should have:
* possibility to pay out asap (max. after 120 confirmations by the pool owner)
* lowest variance possible (more variance can be introduced via lottery games etc. but shouldn't be done by the scoring algorithm in my opinion)
* lowest risk possible for the pool operator of having depts or having to delay payouts (max. delay = until the own pool found the next block to include the fee-free payouts to miners)
* highest possible + uniform payout to miners (minus eventual fees - but NOT minus income of pool hoppers! )
* possibility to have live stats and be as transparent as possible

A few systems (even prop) would work quite well, if you take away transparency completely. Others work nicely if the operator takes a big risk or you don't care about instant payouts. Unfortunately even with p2p-pools, oblivious shares (no live transparency as the operator can only AFTER a round show what his secret was) and PPS this is not accomlished + still bears the risk of having a pool operator running away with your money.

[Luke-Jr]

To me PPS systems still seem to be tha fairest ones, but with SMPPS or RSMPPS there is a risk involved that some shares will never be paid, if the pool hash rate has a peak at a bad luck streak.

No, there is no such risk. No matter how bad the luck, every share will always be paid at least something.

[coblee]

What I don't like at both SMPPS and RSMPPS is that the pool can be in dept a lot out of a sudden bad luck streak with potentially no way to recover ever (imagine having a really bad bad luck streak at the time right before the block reward is cut in half and a lot of miners leave!)

With SMPPS, a real bad luck streak right before a huge difficulty increase or block reward being halved could cause the pool to never recover. This is because new incoming rewards will not be enough to payoff the old debt. (Assuming due to the bad luck, there won't be enough new miners to make up for the harder difficulty)

But with RSMPPS, this is not the case. A bad luck streak will only affect the miners mining at that time. This extreme case will look just like a normal proportional pool to the miners. Since for each long round, they are paid their proportional reward and not the ideal PPS reward. If the pool ever recovers from the bad luck, the difference will get paid back. If not, then they won't get more for those shares, but then the miners are not worse off than if they were in a proportional pool. So the RSMPPS pool will not be burden by this old debt.

To me PPS systems still seem to be tha fairest ones, but with SMPPS or RSMPPS there is a risk involved that some shares will never be paid, if the pool hash rate has a peak at a bad luck streak.

Like Luke said, each share will be paid at least something. And that something will be equivalent to what you get in a proportional pool. If the pool gets a short round in the future, you may be reimbursed for the difference.

[coblee]

It looks like your RSMPPS is trying to take SMPPS and make it more like PPLNS. Better just use PPLNS instead.

The problem with PPLNS is that there's a perceived notion that you lose out if you are not a 24/7 miner. Even though, statistically, you are not worse off. To small-time miners, it's easy to think that if they stop their rigs during the day, they might miss out on the next block... especially if they were unlucky at night.

SMPPS solves this problem by assigned a fixed reward per share. So if you stop mining, you know exactly how much you lose out (expected share * reward per share). I can stop/start mining without fear of missing out, even if the fear is not valid.

And RSMPPS fixes SMPPS such that it has zero chance of going bankrupt, and prevents bad luck from killing the pool due to miners leaving.

[Sukrim]

So if you stop mining, you know exactly how much you lose out (expected share * reward per share).

But if you keep mining you never know when (if?) you get paid fully. (only "eventually")

Also a serious withholding attack (can be done right now by writing a proxy and paying Vladimir to point 50 GH/s your way) will lower the reward per share significantly (down to prop.), if I got the concept right.

[coblee]

So if you stop mining, you know exactly how much you lose out (expected share * reward per share).

But if you keep mining you never know when (if?) you get paid fully. (only "eventually")

Also a serious withholding attack (can be done right now by writing a proxy and paying Vladimir to point 50 GH/s your way) will lower the reward per share significantly (down to prop.), if I got the concept right.

You will get paid fully on the next block, unless it's a long round and there's no saved up buffer. In that case, you will get paid when the pool gets lucky again. In the RSMPPS case, if that never happens, you at least got paid as much as you would have if it was a proportional pool.

So are you saying Vladimir can mine at this RSMPPS pool and withhold winning shares? Basically sabotage the pool such that Vladimir will never help find the winning block. So chances are that it will lead to a long round. And miners will only get paid proportionally. In that case, it hurts Vladimir also. And why would Vladimir wanted to do that? And if someone else is paying Vladimir to do that, yes that would hurt the pool. But tell me which pool wouldn't be hurt by this withholding attack?

[Sukrim]

So if you stop mining, you know exactly how much you lose out (expected share * reward per share).

But if you keep mining you never know when (if?) you get paid fully. (only "eventually")

Also a serious withholding attack (can be done right now by writing a proxy and paying Vladimir to point 50 GH/s your way) will lower the reward per share significantly (down to prop.), if I got the concept right.

You will get paid fully on the next block, unless it's a long round and there's no saved up buffer. In that case, you will get paid when the pool gets lucky again. In the RSMPPS case, if that never happens, you at least got paid as much as you would have if it was a proportional pool.

So are you saying Vladimir can mine at this RSMPPS pool and withhold winning shares? Basically sabotage the pool such that Vladimir will never help find the winning block. So chances are that it will lead to a long round. And miners will only get paid proportionally. In that case, it hurts Vladimir also. And why would Vladimir wanted to do that? And if someone else is paying Vladimir to do that, yes that would hurt the pool. But tell me which pool wouldn't be hurt by this withholding attack?

Vlad offers to mine for any pool for 0 variance + 10% extra with up to 50 GH/s. It would hurt any pool, yes - but most of them just for a short time: PPLNS for N shares, Prop + Scored for 1 round, pure PPS would just hurt the operator... But with *SMPPS the whole pool gets hurt for quite some time potentially.

[coblee]

Vlad offers to mine for any pool for 0 variance + 10% extra with up to 50 GH/s. It would hurt any pool, yes - but most of them just for a short time: PPLNS for N shares, Prop + Scored for 1 round, pure PPS would just hurt the operator... But with *SMPPS the whole pool gets hurt for quite some time potentially.

Your point is valid against SMPPS but no so much against RSMPPS. With RSMPPS, the rewards are paid out to recent miners first. So the pool is not burdened by old debt. The only downside with a negative buffer is that if you get lucky in the future, you will payoff the old miners instead of building up a positive buffer for the future.

In reality, I cannot imagine anyone would do this to a pool. In order to cause a pool to build up a negative buffer, that person would have to pay Vlad that same amount plus 10%. So if you wanted to cause a SMPPS to get a negative 100 btc buffer, on average you would have to pay Vladimir to mine 2 blocks worth of work + 10%. So that's 110 btc or $1500. Even then, a negative buffer of 100 btc is not that much to recover from statistically.

[sirky]

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?

So I may have missed something in the last three pages, but I don't see how this really fixes anything.

You correctly pointed out the issue with SMPPS, but even with your system, I don't see the difference.

Let's say you are running a RSMPPS pool that 'is behind'. I am a miner that is looking to be paid fairly.

There is another SMPPS pool out there that 'is ahead' (or some other cheat proof pool, or solo mining, or whatever).

Which am I going to choose?

This round there is a 50% chance that we will solve a block in < N time (where N is difficulty).
There is also a 50% chance that we will solve a block in > N time.

If I enter the 'fair pool' (cheatproof or SMPPS that 'is ahead') my expected earnings from mining here are exactly what they should be.

If I enter the RSMPPS pool, my expected earnings are lower because:
  + If we solve the block in more than N time, I will be underpaid for my shares
  + Not only that, but if we solve several blocks in a row slowly, it makes it even less likely that I get paid what I am owed in a reasonable amount of time.
  + Not only that, but a logical person would never mine at a *SMPPS pool that 'is behind', because of point 1 and 2, so they would quit and you would actually end up NEVER getting paid.

Does this make sense, or am I missing something?

[Meni Rosenfeld]

Does this make sense, or am I missing something?

You are correct. This is a fundamental problem with all *MPPS pools. When the balance is negative, miners know that their payment has a good chance to be delayed. It doesn't matter if the pool pays recent first (RSMPPS), strives for equal payment for all shares (ESMPPS) or pays all unsaturated shares every round (SMPPS). And, since this should quickly cause the collapse of the pool, "delayed" really means "gone forever".

[Luke-Jr]

Does this make sense, or am I missing something?

You are correct. This is a fundamental problem with all *MPPS pools. When the balance is negative, miners know that their payment has a good chance to be delayed. It doesn't matter if the pool pays recent first (RSMPPS), strives for equal payment for all shares (EMPPS) or pays all unsaturated shares every round (SMPPS). And, since this should quickly cause the collapse of the pool, "delayed" really means "gone forever".

Equalized SMPPS is ESMPPS, not EMPPS. Regular MPPS is not "vulnerable" to pool funds running out, because you have your own private limits that you are responsible for maintaining.

No matter what reward method is used, when a pool is down to zero buffer on a long round, it must either underpay or create debt for the pool owner. That is an inevitable fact of pooled mining. Nothing can stop it. *MPPS attempts to mitigate it by offering to make up for the loss later.

CPPSB is logically a combination of RSMPPS and SMPPS: When/if the pool reaches 0 buffer, it starts "discarding" the oldest shares in the round into the "extra credit" buckets, while maintaining full PPS value for the most recent and future shares (this to maintain the best possible deal for current miners, so they don't leave). When and only when it has extra funds on short blocks, it will then pay toward the "extra credit" buckets indiscriminately (backpay), until it is all given full PPS reward, and then start filling the "buffer" bucket.

CPPSEB is similar, but tracks unpaid shares rather than indiscriminate unpaid value totals, and when it's giving backpay tries to distribute it so the unpaid shares are all paid off an equalized amount.

[Meni Rosenfeld]

No matter what reward method is used, when a pool is down to zero buffer on a long round, it must either underpay or create debt for the pool owner. That is an inevitable fact of pooled mining. Nothing can stop it. *MPPS attempts to mitigate it by offering to make up for the loss later.

Your mistake is assuming that the goal of a pool is to reward each share with the statistical average, exactly.

The real goal of a pool is, however, to reward each share with the statistical average, on average (while reducing variance as much as possible). On the one hand you have PPS, which is 0 variance for the miner (with maximal risk to the operator); on the other hand, solo mining which has the highest variance; and a variety of methods in between.

PS. If MPPS is what I think it is, then it is just as bad as the *SMPPS.

[sirky]

No matter what reward method is used, when a pool is down to zero buffer on a long round, it must either underpay or create debt for the pool owner. That is an inevitable fact of pooled mining. Nothing can stop it. *MPPS attempts to mitigate it by offering to make up for the loss later.

This is only true for PPS systems. If you do something like the PPLNS that Meni and I have talked about, the variance is pushed to the miners, and not the pool owner. Discarding transaction fees (as most pools do) you will get exactly what you deserve over the long run, with no worries about being underpaid or about the pool owner going bankrupt.

[Luke-Jr]

No matter what reward method is used, when a pool is down to zero buffer on a long round, it must either underpay or create debt for the pool owner. That is an inevitable fact of pooled mining. Nothing can stop it. *MPPS attempts to mitigate it by offering to make up for the loss later.

Your mistake is assuming that the goal of a pool is to reward each share with the statistical average, exactly.

The real goal of a pool is, however, to reward each share with the statistical average, on average (while reducing variance as much as possible). On the one hand you have PPS, which is 0 variance for the miner (with maximal risk to the operator); on the other hand, solo mining which has the highest variance; and a variety of methods in between.

PS. If MPPS is what I think it is, then it is just as bad as the *SMPPS.

*MPPS fit with your "real goal" much better than any other system currently.

[Meni Rosenfeld]

No matter what reward method is used, when a pool is down to zero buffer on a long round, it must either underpay or create debt for the pool owner. That is an inevitable fact of pooled mining. Nothing can stop it. *MPPS attempts to mitigate it by offering to make up for the loss later.

Your mistake is assuming that the goal of a pool is to reward each share with the statistical average, exactly.

The real goal of a pool is, however, to reward each share with the statistical average, on average (while reducing variance as much as possible). On the one hand you have PPS, which is 0 variance for the miner (with maximal risk to the operator); on the other hand, solo mining which has the highest variance; and a variety of methods in between.

PS. If MPPS is what I think it is, then it is just as bad as the *SMPPS.

*MPPS fit with your "real goal" much better than any other system currently.

This is of course false, given that
1. *MPPS does not fit the goal.
2. Other systems such as PPLNS and the geometric method fit the goal.

[Luke-Jr]

No matter what reward method is used, when a pool is down to zero buffer on a long round, it must either underpay or create debt for the pool owner. That is an inevitable fact of pooled mining. Nothing can stop it. *MPPS attempts to mitigate it by offering to make up for the loss later.

Your mistake is assuming that the goal of a pool is to reward each share with the statistical average, exactly.

The real goal of a pool is, however, to reward each share with the statistical average, on average (while reducing variance as much as possible). On the one hand you have PPS, which is 0 variance for the miner (with maximal risk to the operator); on the other hand, solo mining which has the highest variance; and a variety of methods in between.

PS. If MPPS is what I think it is, then it is just as bad as the *SMPPS.

*MPPS fit with your "real goal" much better than any other system currently.

This is of course false, given that
1. *MPPS does not fit the goal.
2. Other systems such as PPLNS and the geometric method fit the goal.

*MPPS fit the goal more or less exactly. PPLNS and geometric just add variance and obscurity to how well the goal is met.

[sirky]

If you do traditional PPLNS (without scoring) it is still quite fair (compared to things like *MPPS and Proportional), and it doesn't obfuscate anything. It is incredibly simple.

I would love *MPPS as a miner, because I know exactly which pools to mine from, but I would never run one, since it will just take one bad string of luck to put you out of business if your miners are looking to maximize profits.

[coblee]

So I may have missed something in the last three pages, but I don't see how this really fixes anything.

You correctly pointed out the issue with SMPPS, but even with your system, I don't see the difference.

Let's say you are running a RSMPPS pool that 'is behind'. I am a miner that is looking to be paid fairly.

There is another SMPPS pool out there that 'is ahead' (or some other cheat proof pool, or solo mining, or whatever).

Which am I going to choose?

This round there is a 50% chance that we will solve a block in < N time (where N is difficulty).
There is also a 50% chance that we will solve a block in > N time.

If I enter the 'fair pool' (cheatproof or SMPPS that 'is ahead') my expected earnings from mining here are exactly what they should be.

If I enter the RSMPPS pool, my expected earnings are lower because:
  + If we solve the block in more than N time, I will be underpaid for my shares
  + Not only that, but if we solve several blocks in a row slowly, it makes it even less likely that I get paid what I am owed in a reasonable amount of time.
  + Not only that, but a logical person would never mine at a *SMPPS pool that 'is behind', because of point 1 and 2, so they would quit and you would actually end up NEVER getting paid.

Does this make sense, or am I missing something?

You argument is flawed b/c if you assume that you are solving blocks slowly for an extended time, you will get paid just like a proportional pool. How is that worse than a normal prop pool? Yeah, sure it might take a while (until pool gets lucky) for you to get paid your total PPS reward, but at least there's a chance you will get paid.

The problem with any *SMPPS pool is that if there is a bunch to choose from, you would always choose the one that has a positive buffer. So it may lead to pool hopping due to buffer size. RSMPPS does a better job in alleviating that but not fully.

[coblee]

If you do traditional PPLNS (without scoring) it is still quite fair (compared to things like *MPPS and Proportional), and it doesn't obfuscate anything. It is incredibly simple.

I would love *MPPS as a miner, because I know exactly which pools to mine from, but I would never run one, since it will just take one bad string of luck to put you out of business if your miners are looking to maximize profits.

I agree that PPLNS is simple and quite fair, but as a miner, I'm wary of mining at a PPLNS pool. Although I believe it's statistically fair, I don't like the fact that if I don't mine 24/7, my luck will play a lot into my earnings. I will be constantly afraid to take my miners down b/c the pool my run into 5 blocks in a row after N/2 shares (or however many) and I will be paid nothing.

As a miner, I would actually prefer a RSMPPS pool (even with negative buffer) than a PPLNS pool, but that's just me.

[sirky]

So I may have missed something in the last three pages, but I don't see how this really fixes anything.

You correctly pointed out the issue with SMPPS, but even with your system, I don't see the difference.

Let's say you are running a RSMPPS pool that 'is behind'. I am a miner that is looking to be paid fairly.

There is another SMPPS pool out there that 'is ahead' (or some other cheat proof pool, or solo mining, or whatever).

Which am I going to choose?

This round there is a 50% chance that we will solve a block in < N time (where N is difficulty).
There is also a 50% chance that we will solve a block in > N time.

If I enter the 'fair pool' (cheatproof or SMPPS that 'is ahead') my expected earnings from mining here are exactly what they should be.

If I enter the RSMPPS pool, my expected earnings are lower because:
  + If we solve the block in more than N time, I will be underpaid for my shares
  + Not only that, but if we solve several blocks in a row slowly, it makes it even less likely that I get paid what I am owed in a reasonable amount of time.
  + Not only that, but a logical person would never mine at a *SMPPS pool that 'is behind', because of point 1 and 2, so they would quit and you would actually end up NEVER getting paid.

Does this make sense, or am I missing something?

You argument is flawed b/c if you assume that you are solving blocks slowly for an extended time, you will get paid just like a proportional pool. How is that worse than a normal prop pool? Yeah, sure it might take a while (until pool gets lucky) for you to get paid your total PPS reward, but at least there's a chance you will get paid.

The problem with any *SMPPS pool is that if there is a bunch to choose from, you would always choose the one that has a positive buffer. So it may lead to pool hopping due to buffer size. RSMPPS does a better job in alleviating that but not fully.

Because in a proportional pool you get paid far more than you do in PPS on short rounds.

[sirky]

To clarify, this may be what people are missing.

You think that it is fair because at worst, you end up getting paid as if it were a proportional pool.

However, proportional pools are fair because you get the benefit of short rounds to even out the pain of the long rounds.

PPS is fair because you get paid 'what you deserve' even during long rounds, but you actually lose out on short rounds.

So a pool that gives you the payment of a PPS pool on short rounds with the payment of a proportional pool on long rounds should be avoided at all costs.

And that is exactly what a *MPPS pool is if it is significantly 'behind'.

[Sukrim]

True.

In a *MPPS pool you get paid the expected payout in the best case and less in the worst case.

On Prop. you get paid far more than expected in the best case and far less in the worst case (which evens out if there are no hoppers).
Scored/PPLNS is similar, you can have "lucky" shares and "unlucky" shares that are worth more/less than others, it's just not predictable, so you can't hop.

All in all:
As soon as a *MPPS pool gets close to 0, better make a run for the hills and switch pools (if you are a careful miner). RSMPPS seems especially dangerous at the beginning of a loss period (when approaching 0 buffer).

[coblee]

To clarify, this may be what people are missing.

You think that it is fair because at worst, you end up getting paid as if it were a proportional pool.

However, proportional pools are fair because you get the benefit of short rounds to even out the pain of the long rounds.

PPS is fair because you get paid 'what you deserve' even during long rounds, but you actually lose out on short rounds.

So a pool that gives you the payment of a PPS pool on short rounds with the payment of a proportional pool on long rounds should be avoided at all costs.

And that is exactly what a *MPPS pool is if it is significantly 'behind'.

This is only the case for the worst case scenarion. Let's use an example where L is for long rounds and S is for short rounds and we have even luck for this whole time frame. And assume the pool has a huge negative buffer (i.e. significantly behind).

If the scenario is SSSSSSSSSSLLLLLLLLLL (10 short rounds, then 10 long rounds)
Then yes, all the initial short rounds will be paid at PPS and the extras will be used to payoff the negative buffer. In this worst cast scenario, those short rounds are paid only PPS. And the long rounds are only paid proportional.

If the scenario is LLLLLLLLLLSSSSSSSSSS (10 long rounds, then 10 short rounds)
Then the long rounds will be paid proportional and the difference will be added to the negative buffer. When we hit those short rounds, the extras (over PPS) will be used to pay off the recent long rounds. So in the end, you will paid the PPS reward for each share in this timeframe.

And for the average case of LSLSLSLSLSLSLSLSLSLS
It works out well too since each short round would pay for the last long round.

So yes, a negative buffer is not good (because the next short round will be used to payoff the buffer), but it's not as bad as you think.

[coblee]

True.

In a *MPPS pool you get paid the expected payout in the best case and less in the worst case.

On Prop. you get paid far more than expected in the best case and far less in the worst case (which evens out if there are no hoppers).
Scored/PPLNS is similar, you can have "lucky" shares and "unlucky" shares that are worth more/less than others, it's just not predictable, so you can't hop.

All in all:
As soon as a *MPPS pool gets close to 0, better make a run for the hills and switch pools (if you are a careful miner). RSMPPS seems especially dangerous at the beginning of a loss period (when approaching 0 buffer).

Please explain why RSMPPS is especially dangerous.

[Luke-Jr]

In a *MPPS pool you get paid the expected payout in the best case and less in the worst case.

On Prop. you get paid far more than expected in the best case and far less in the worst case (which evens out if there are no hoppers).

Not quite. All variations of *MPPS will pay you extra for formerly underpaid blocks, making them even out even without hoppers. In the scenario where the pool never evens out, neither would proportional.

[Sukrim]

True.

In a *MPPS pool you get paid the expected payout in the best case and less in the worst case.

On Prop. you get paid far more than expected in the best case and far less in the worst case (which evens out if there are no hoppers).
Scored/PPLNS is similar, you can have "lucky" shares and "unlucky" shares that are worth more/less than others, it's just not predictable, so you can't hop.

All in all:
As soon as a *MPPS pool gets close to 0, better make a run for the hills and switch pools (if you are a careful miner). RSMPPS seems especially dangerous at the beginning of a loss period (when approaching 0 buffer).

Please explain why RSMPPS is especially dangerous.

As more recent shares that have still to be paid get paid, shares submitted at the time the pool used up it's buffer will get paid last (or never). On RSMPPS you have to monitor the pool balance even more closely because of this. SMPPS will try to pay these first once it has some luck, so all the shares submitted during a "proportional phase" are at danger of never being paid the full amount.

The difference is that Proportional and PPLNS don't carry this "burden" of formerly under-/overpaid blocks. Once a round ends, you're done and have had luck or not. you can join a pool that has had a huge bad luck strain for 3 months and still get perfectly fine payouts if the luck suddenly changes.
With SMPPS (and especially RSMPPS) it might be the case, that in 2 months from now you might get paid for a share submitted right now.

[sirky]

In a *MPPS pool you get paid the expected payout in the best case and less in the worst case.

On Prop. you get paid far more than expected in the best case and far less in the worst case (which evens out if there are no hoppers).

Not quite. All variations of *MPPS will pay you extra for formerly underpaid blocks, making them even out even without hoppers. In the scenario where the pool never evens out, neither would proportional.

Empirically, perhaps you are right. There could definitely be cases where you will be underpaid for long portions of time in a proportional pool. See BTC Guild currently for an example. They have had bad luck the last several difficulties. But that doesn't matter, because it should even out in the long run. There is no reason not to mine there (other than the fact it is proportional, and seems to be DDoS'ed a lot because it is big).

However, I want to paint a scenario for you. If there were two pools, both *MPPS, one with a 20 block buffer, and one with a 20 block deficit, which would you mine at if you were a brand new miner?

In one pool you are guaranteed a full PPS payout for quite a long time regardless of when the pool finds a block.

In the other you are guaranteed less than full payout for quite a long time, since you have to pay off unpaid shares which others have accumulated. You are getting less than proportional in this case, right?

Does anyone disagree with this?

[Luke-Jr]

In the other you are guaranteed less than full payout for quite a long time, since you have to pay off unpaid shares which others have accumulated. You are getting less than proportional in this case, right?

This is true of SMPPS and, to an extent, ESMPPS, but it is not true of RSMPPS or CPPS* which prioritize the present and future over the past.

[sirky]

In the other you are guaranteed less than full payout for quite a long time, since you have to pay off unpaid shares which others have accumulated. You are getting less than proportional in this case, right?

This is true of SMPPS and, to an extent, ESMPPS, but it is not true of RSMPPS or CPPS* which prioritize the present and future over the past.

Ok, so let's talk specifically about SMPPS and ESMPPS then.

The catch is, the fact that you are a new miner in my above example is irrelevant. Because if you have a lot of shares built up at an SMPPS pool, it still behooves you to switch to the other SMPPS pool, because you are going to make your owed money back at the first pool whether you mine there or not. So if you switch, you get full credit for your current mining efforts, and then you get some trickle from the other pool finding blocks. The problem is that everyone will do this, and the pool will die.

I am not familiar with CPPS* so I cannot comment on it.

RSMPPS is an improvement, in my opinion. However, if the block buffer <= 0, there is still a non-zero chance you could fall into the negatives, and thus, not get paid in full for the next block (if it has to roll over to future blocks). Therefore, as soon as the buffer hit zero, it would behoove you to switch to another pool where you are guaranteed full payout.

Let me know where your complaint with my logic is.

[coblee]

A *MPPS pool with a positive buffer is always better than one with a negative buffer if all else is equal. I'm not denying that. RSMPPS makes it better, but it's still a problem.

All payout methods has their own problems. If there was a perfect one, we wouldn't be discussing this anymore. But in my opinion, *MPPS pools are more fair and RSMPPS does the best job at not causing miners to quit when the buffer goes negative.

[sirky]

A *MPPS pool with a positive buffer is always better than one with a negative buffer if all else is equal. I'm not denying that. RSMPPS makes it better, but it's still a problem.

All payout methods has their own problems. If there was a perfect one, we wouldn't be discussing this anymore. But in my opinion, *MPPS pools are more fair and RSMPPS does the best job at not causing miners to quit when the buffer goes negative.

Well, the only problem with geometric scoring is that it is not really user friendly (hard to understand for average users), and a bit processor intensive for the server.

The only problem with PPLNS is a little weirdness around difficulty changes. If you account for this with some pretty easy scoring, it works perfectly. And I think PPLNS is quite user friendly.

So I contend that there is better out there.

[coblee]

A *MPPS pool with a positive buffer is always better than one with a negative buffer if all else is equal. I'm not denying that. RSMPPS makes it better, but it's still a problem.

All payout methods has their own problems. If there was a perfect one, we wouldn't be discussing this anymore. But in my opinion, *MPPS pools are more fair and RSMPPS does the best job at not causing miners to quit when the buffer goes negative.

Well, the only problem with geometric scoring is that it is not really user friendly (hard to understand for average users), and a bit processor intensive for the server.

The only problem with PPLNS is a little weirdness around difficulty changes. If you account for this with some pretty easy scoring, it works perfectly. And I think PPLNS is quite user friendly.

So I contend that there is better out there.

PPLNS might be better in terms of easy to understand and no disadvantage for previous bad luck. I still have the issue with it where it feels unfair for non-fulltime miners.

[Sukrim]

I still have the issue with it where it feels unfair for non-fulltime miners.

Feels != is...

PPLNS might for example need different stats displays... something along the lines of "every share submitted has a xx% chance of paying 0 BTC, a xx% chance of paying __BTC, a xx% chance of paying __BTC" and so on, and then an average over these numbers below. "Estimated payout" just taken from Prop. will always show too low numbers, as it doesn't take into account that shares can pay out multiple times - so depending on N you might not report quite a bit of the potential earnings.

Giving percentages per share would also be more true to how the system works, than having some estimated rewards that slowly rise and fall with your proportional contribution in the last N shares.

[OneFixt]

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?

Coblee,
BitPenny (website, forum topic) uses the Delayed PPS (CPPSRB - Capped Pay Per Share with Recent Backpay) system which, I believe, accomplishes what you propose.

[Inaba]

Really?  Gonna necro this thread to advertise BitPenny? 

The entire range of *PPS has been debated and hashed over plenty in many other threads since July.  Not really any point in touting yet another one with it's own set of problems.

[Balthazar]

Just yet another necropost  

OneFixt
CPPSRB != RSMPPS