Bitcoin Forum
October 24, 2017, 06:06:14 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 »  All
  Print  
Author Topic: A proposal for Recent Shared Maximum PPS  (Read 10563 times)
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 2002



View Profile WWW
July 13, 2011, 11:51:26 AM
 #41

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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
1508825174
Hero Member
*
Offline Offline

Posts: 1508825174

View Profile Personal Message (Offline)

Ignore
1508825174
Reply with quote  #2

1508825174
Report to moderator
1508825174
Hero Member
*
Offline Offline

Posts: 1508825174

View Profile Personal Message (Offline)

Ignore
1508825174
Reply with quote  #2

1508825174
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1508825174
Hero Member
*
Offline Offline

Posts: 1508825174

View Profile Personal Message (Offline)

Ignore
1508825174
Reply with quote  #2

1508825174
Report to moderator
1508825174
Hero Member
*
Offline Offline

Posts: 1508825174

View Profile Personal Message (Offline)

Ignore
1508825174
Reply with quote  #2

1508825174
Report to moderator
Sukrim
Legendary
*
Offline Offline

Activity: 2156


View Profile
July 13, 2011, 01:06:26 PM
 #42

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! Wink ) 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! Wink )
* 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.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
Luke-Jr
Legendary
*
Offline Offline

Activity: 2240



View Profile
July 13, 2011, 02:32:20 PM
 #43

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
Donator
Legendary
*
Offline Offline

Activity: 1218


Creator of Litecoin. Director of Eng at Coinbase.


View Profile
July 13, 2011, 06:06:09 PM
 #44

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
Donator
Legendary
*
Offline Offline

Activity: 1218


Creator of Litecoin. Director of Eng at Coinbase.


View Profile
July 25, 2011, 11:13:15 PM
 #45

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
Legendary
*
Offline Offline

Activity: 2156


View Profile
July 26, 2011, 12:17:37 AM
 #46

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.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
coblee
Donator
Legendary
*
Offline Offline

Activity: 1218


Creator of Litecoin. Director of Eng at Coinbase.


View Profile
July 26, 2011, 12:30:57 AM
 #47

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
Legendary
*
Offline Offline

Activity: 2156


View Profile
July 26, 2011, 01:46:26 AM
 #48

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.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
coblee
Donator
Legendary
*
Offline Offline

Activity: 1218


Creator of Litecoin. Director of Eng at Coinbase.


View Profile
July 26, 2011, 02:59:31 AM
 #49

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
Sr. Member
****
Offline Offline

Activity: 407



View Profile
July 26, 2011, 12:01:41 PM
 #50

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
Donator
Legendary
*
Offline Offline

Activity: 2002



View Profile WWW
July 26, 2011, 12:15:56 PM
 #51

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

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
Luke-Jr
Legendary
*
Offline Offline

Activity: 2240



View Profile
July 26, 2011, 03:20:51 PM
 #52

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
Donator
Legendary
*
Offline Offline

Activity: 2002



View Profile WWW
July 26, 2011, 03:30:16 PM
 #53

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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
sirky
Sr. Member
****
Offline Offline

Activity: 407



View Profile
July 26, 2011, 03:35:03 PM
 #54


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
Legendary
*
Offline Offline

Activity: 2240



View Profile
July 26, 2011, 03:37:21 PM
 #55

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
Donator
Legendary
*
Offline Offline

Activity: 2002



View Profile WWW
July 26, 2011, 03:45:21 PM
 #56

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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
Luke-Jr
Legendary
*
Offline Offline

Activity: 2240



View Profile
July 26, 2011, 04:01:20 PM
 #57

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
Sr. Member
****
Offline Offline

Activity: 407



View Profile
July 26, 2011, 04:06:47 PM
 #58

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
Donator
Legendary
*
Offline Offline

Activity: 1218


Creator of Litecoin. Director of Eng at Coinbase.


View Profile
July 26, 2011, 06:41:03 PM
 #59

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
Donator
Legendary
*
Offline Offline

Activity: 1218


Creator of Litecoin. Director of Eng at Coinbase.


View Profile
July 26, 2011, 06:47:35 PM
 #60

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.

Pages: « 1 2 [3] 4 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!