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.

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

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.

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?

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.

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.

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.

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

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

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

I have a proposal for a better SMPPS payout system. See: http://forum.bitcoin.org/index.php?topic=27698

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?

Though in theory, the system is sound. In practice, things can happen. As we saw when they were using bad blocks data, the firstbits address given out may be wrong. You can never be sure that this won't happen again, right?

BTW, this system will only work if you are careful when you take money out of this "savings" account. Since if you create a transaction that has change, the change will go to a random wallet address. You will need to add that wallet address to this spreadsheet in order for it to stay accurate.

So the way I plan to use it is for each address I have in this account, I plan to put the same number of bitcoins in them. So for example, if I have 10 BTC in each of the 12 addresses, I will have 120 BTC total. If I need to transfer money out, I do it in a multiple of 10s. That way, there won't be any change. For anything less than 10 BTC, I just keep in my checking account.

I hope in the future, the client will let me choose which account I want the change in.

Thanks! I didn't realize theymos added it. I made the change to the spreadsheet. Should be much better now... no more html scraping.

Hey, this is an awesome concept. I applaud you guys for coming up with it.

Removing the cases is a good thing because it would be hard for people to have to deal with upper and lower cases. There might be one gotcha though. Do you handle 2 addresses with the same characters but different cases properly. I know this is a rare edge case, but make sure you handle it. For example, 1abcdefghijklmnopqrstuvwxyz and 1abcdefghijklmnopqrstuvwXYZ should not both match to the same firstbits 1abcd. The first one in the block chain should match to 1abcd and then second one should match to 1abcde. Just a thought.

done!

I will say it again. This is a zero-sum game. (see http://en.wikipedia.org/wiki/Zero_sum_game)
If someone in this pool (minipool owners) has a better expected value mining in this pool than otherwise, then someone else (non minipool owners) must have a worse expected value. Not everyone in this pool will benefit! No matter how much the jackpot is or how enticing it is, there still an expected value for it. And for non minipool owerners, that expected value is less than 1%.

LOL.

MrSam, it's true that it's not a full pyramid scheme. But it's still a 2 level pyramid scheme, where you benefit from all the people you got to sign up under you. Pooled mining is a zero-sum game. It's about how the 50 BTC (minus fees) are shared among the miners. Other pools share this 50 BTC bases on shares or score. Your pool adds another twist where 0.5 BTC is only shared among minipool owners. Because it's a zero-sum game, in order for minipool owners earn more, someone has to lose out. And the losers are those without any friends.

This system (like any other pyramid scheme) will collapse in time. In the beginning as people are joining your pool and getting others to join, they will see that they are making more with your pool than other pools. As your miners are able to find less and less people to join, the non minipool owners will realize that they are not benefiting b/c they are not minipool owners (they can't find people to join under them). Those miners will quit the pool. Then their minipool owners will find their mining to be not quite as good and they will quit. Sooner or later, the whole thing will collapse.

It seems like there's no money required to join your pool. But in reality, the "cost" is the lost earnings of the 1% of the 50 BTC found in a block.

This is just like the pyramid emails I get where they ask me to send them $100 and then I can forward the email to 3 of my friends that will each give me $100. The people at the bottom of this pyramid scheme will always lose, because they won't have friends to help them make back the 1% they are losing out on.

Anyways, just my take.