A proposal for Recent Shared Maximum PPS

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

[1714783992]

1714783992

[1714783992]

1714783992

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