Pool Hopping: The SIMPLE Solution!

[JoelKatz]

Correct me if I'm wrong, but I believe crossing pool boundaries would mean the "window" could be as long as you wanted. Even 24 hours.

I believe that's correct, which is actually pretty nice.

There could still be 'jackpot' rounds if multiple blocks are found within the window. But there is no way to know that a share is more or less likely to be in the jackpot before you work for it, so that provides no incentive to pool hop. Every share submitted has precisely the same chance to be part of the payoff for any number of found blocks.

[1714778580]

1714778580

[1714778580]

1714778580

[1714778580]

1714778580

[1714778580]

1714778580

[Meni Rosenfeld]

IMO SMPPS is a bad method.

why is that? the only problem I see is that an unlucky pool will get a bad reputation for delaying payments for shares a long time

In a nutshell, if an SMPPS pool with no fees runs long enough, with probability 1 it will eventually reach a point of such unluckiness that its payouts will be miniscule. Miners will leave and the pool will never recover. At that point miners with pending payments will never receive them. So, the claim that "you will get your due reward eventually" is refuted based on the pool's inevitable collapse.

Correct me if I'm wrong, but I believe crossing pool boundaries would mean the "window" could be as long as you wanted. Even 24 hours.

First, defining the window in terms of units of time is bad. You need to define it in terms of number of shares.

But yes, I guess in the multiple-payment variant, you could make the window long. But this will also mean you'll have to make sure you're handling difficulty changes properly.

In the single-payment variant, the window must be less than the difficulty by some margin.

[JoelKatz]

In a nutshell, if an SMPPS pool with no fees runs long enough, with probability 1 it will eventually reach a point of such unluckiness that its payouts will be miniscule. Miners will leave and the pool will never recover. At that payment miners with pending payments will never receive them.

I don't understand why you say this. With SMPPS, every submitted share has precisely the same expected payout regardless of the past performance of the pool.

[NickW]

Correct me if I'm wrong, but I believe crossing pool boundaries would mean the "window" could be as long as you wanted. Even 24 hours.

First, defining the window in terms of units of time is bad. You need to define it in terms of number of shares.

But yes, I guess in the multiple-payment variant, you could make the window long. But this will also mean you'll have to make sure you're handling difficulty changes properly.

In the single-payment variant, the window must be less than the difficulty by some margin.

Defining in terms of time rather than shares is absolutely fine provided the period is long for the smaller pools. It also means it's always constant (in time) even when the hash rate of the pool fluctuates. A window which is always constant and defined by time makes it much simpler for the average miner to understand. Payments are not calculated by a miner's proportional time in a pool, but by the proportion of the shares they submitted in the window to the total number of shares in the window. The Window still slides with the discovery of a new block in that pool.

Yes, it would have to involve calculating payment from the same shares more than once if blocks are found over a much shorter period than the window. I'd think it may even be best to have a window longer than the expected time to find a block to decrease payout variance. You would not have to make any adjustments for difficulty changes.

I don't see a single-payment variant working well with this method.

[JoelKatz]

Defining in terms of time rather than shares is absolutely fine provided the period is long for the smaller pools.

It can be in shares or time. If the window contains more shares, it will likely also contain more found blocks, but they will be divided over the greater shares. The expected revenue per share will be precisely the same, and that's all that's needed.

If a time window has n shares and m blocks, the payout per share will be 50m/n. If later that time window has 2n shares submitted, it will be expected to find twice as many blocks. The payout will be 50(2m)/(2n) which is precisely the same.

[Meni Rosenfeld]

In a nutshell, if an SMPPS pool with no fees runs long enough, with probability 1 it will eventually reach a point of such unluckiness that its payouts will be miniscule. Miners will leave and the pool will never recover. At that payment miners with pending payments will never receive them.

I don't understand why you say this. With SMPPS, every submitted share has precisely the same expected payout regardless of the past performance of the pool.

Only if you assume people are willing to wait arbitrarily long for their rewards. The lower the pool's current balance, the longer it will take to get the full payout, and people will lose patience. Add to this the fact that people will fear the collapse of the pool, a self-fulfilling prophecy which will prevent ever getting the payment. When the pool is in the red, massive abandonment is a schelling focal point.

[Meni Rosenfeld]

Correct me if I'm wrong, but I believe crossing pool boundaries would mean the "window" could be as long as you wanted. Even 24 hours.

First, defining the window in terms of units of time is bad. You need to define it in terms of number of shares.

But yes, I guess in the multiple-payment variant, you could make the window long. But this will also mean you'll have to make sure you're handling difficulty changes properly.

In the single-payment variant, the window must be less than the difficulty by some margin.

Defining in terms of time rather than shares is absolutely fine

No, it will make the pool vulnerable to hopping based on pool hashrate fluctuations. It is more profitable to mine for the pool when the current hashrate is higher than the average over the current window.

[JoelKatz]

In a nutshell, if an SMPPS pool with no fees runs long enough, with probability 1 it will eventually reach a point of such unluckiness that its payouts will be miniscule. Miners will leave and the pool will never recover. At that payment miners with pending payments will never receive them.

I don't understand why you say this. With SMPPS, every submitted share has precisely the same expected payout regardless of the past performance of the pool.

Only if you assume people are willing to wait arbitrarily long for their rewards.

They don't have to wait arbitrarily long. They only have to wait until the SMPPS pool accumulates whatever the number of shares chosen for N is. At that point, they will get whatever payment their share is going to generate.

The lower the pool's current balance, the longer it will take to get the full payout, and people will lose patience. Add to this the fact that people will fear the collapse of the pool, a self-fulfilling prophecy which will prevent ever getting the payment. When the pool is in the red, massive abandonment is a schelling focal point.

I don't follow you. What do you mean by the "pool's current balance"?

The way a SMPPS pool works is this: People submit shares to the pool. The pool tries to find blocks. When it finds a block, it pays out on each of the N shares received prior to finding that block, paying 50/N bitcoins. N can be chosen large enough so that most shares pay out.

You do have to wait until the pool finds a block to get paid though. So this won't work very well for very small pools. But once a pool is large enough to find a block at least once a day, there's no reason to think it would shrink.

[JoelKatz]

No, it will make the pool vulnerable to hopping based on pool hashrate fluctuations. It is more profitable to mine for the pool when the current hashrate is higher than the average over the current window.

No it won't. When the hashrate is higher, the number of shares per window will be higher, resulting in lower payouts per block found. Of course more block will be found, equaling things out perfectly.

[Meni Rosenfeld]

In a nutshell, if an SMPPS pool with no fees runs long enough, with probability 1 it will eventually reach a point of such unluckiness that its payouts will be miniscule. Miners will leave and the pool will never recover. At that payment miners with pending payments will never receive them.

I don't understand why you say this. With SMPPS, every submitted share has precisely the same expected payout regardless of the past performance of the pool.

Only if you assume people are willing to wait arbitrarily long for their rewards.

They don't have to wait arbitrarily long. They only have to wait until the SMPPS pool accumulates whatever the number of shares chosen for N is. At that point, they will get whatever payment their share is going to generate.

The lower the pool's current balance, the longer it will take to get the full payout, and people will lose patience. Add to this the fact that people will fear the collapse of the pool, a self-fulfilling prophecy which will prevent ever getting the payment. When the pool is in the red, massive abandonment is a schelling focal point.

I don't follow you. What do you mean by the "pool's current balance"?

The way a SMPPS pool works is this: People submit shares to the pool. The pool tries to find blocks. When it finds a block, it pays out on each of the N shares received prior to finding that block, paying 50/N bitcoins. N can be chosen large enough so that most shares pay out.

You do have to wait until the pool finds a block to get paid though. So this won't work very well for very small pools. But once a pool is large enough to find a block at least once a day, there's no reason to think it would shrink.

You're talking about PPLNS. I was talking about SMPPS. PPLNS is a great method as I've mentioned here and elsewhere.

No, it will make the pool vulnerable to hopping based on pool hashrate fluctuations. It is more profitable to mine for the pool when the current hashrate is higher than the average over the current window.

No it won't. When the hashrate is higher, the number of shares per window will be higher, resulting in lower payouts per block found. Of course more block will be found, equaling things out perfectly.

Read carefully. I said "current hashrate > average hash rate over the window". The number of shares per window depends on the average hashrate over the window, not the current hashrate. Meanwhile, the chance your share will be included in a payout does depend on the current hashrate.

[NickW]

Defining in terms of time rather than shares is absolutely fine provided the period is long for the smaller pools.

It can be in shares or time. If the window contains more shares, it will likely also contain more found blocks, but they will be divided over the greater shares. The expected revenue per share will be precisely the same, and that's all that's needed.

If a time window has n shares and m blocks, the payout per share will be 50m/n. If later that time window has 2n shares submitted, it will be expected to find twice as many blocks. The payout will be 50(2m)/(2n) which is precisely the same.

I understand this completely. The reason smaller pools should have a longer window is to reduce variance. Non 24-7 miners in small pools with a small window (relative to average time to find a block) are going to have payouts all over the place.

[Sukrim]

If you do PPLNS instead of PPLNM (with M standing for "minutes") you don't even need to consider time windows. You could then tune variance by just looking back more/less shares.

[BurningToad]

Meni Rosenfeld, could you do some math for me, since you seem to like to do it and like to say that SMPPS is a bad method?

I understand that over an infinite time period, there is a certain probability that a SMPPS pool will be very negative (or very positive, etc.)  

However, I have a question.  Based on the current stats at https://arsbitcoin.com/stats.php, (SMPPS Buffer size, current hashrate).  And assuming that current hashrate is constant (lets say 210 GH/s), BTC reward per block stays at 50, difficulty is constant (if this matters), what is the probability that the SMPPS buffer will go below 0 in the next year?

I think it should be possible to calculate this, but I am not very qualified to do so.  It seems like you are.

It seems obvious to me that, for example, it IS less likely that the buffer will go negative, within a year, now that the buffer is ~685 BTC vs starting with a 0 BTC buffer. Sure, it is still possible to reach a very negative buffer, but the higher the buffer is, the longer this is likely to take, correct?

And I know that we are lucky.  I'm not saying that everyone should switch to SMPPS, because the buffer could just have likely gone to negative ~685 BTC as positive.  I'm just curious what the numbers say for my current situation.



 

[Meni Rosenfeld]

Meni Rosenfeld, could you do some math for me, since you seem to like to do it and like to say that SMPPS is a bad method?

I understand that over an infinite time period, there is a certain probability that a SMPPS pool will be very negative (or very positive, etc.)  

However, I have a question.  Based on the current stats at https://arsbitcoin.com/stats.php, (SMPPS Buffer size, current hashrate).  And assuming that current hashrate is constant (lets say 210 GH/s), BTC reward per block stays at 50, difficulty is constant (if this matters), what is the probability that the SMPPS buffer will go below 0 in the next year?

I think it should be possible to calculate this, but I am not very qualified to do so.  It seems like you are.

It seems obvious to me that, for example, it IS less likely that the buffer will go negative, within a year, now that the buffer is ~685 BTC vs starting with a 0 BTC buffer. Sure, it is still possible to reach a very negative buffer, but the higher the buffer is, the longer this is likely to take, correct?

And I know that we are lucky.  I'm not saying that everyone should switch to SMPPS, because the buffer could just have likely gone to negative ~685 BTC as positive.  I'm just curious what the numbers say for my current situation.

I'll need to think a little about this, in the meantime I'll solve the easier problem of what is the probability the balance will be negative exactly one year from now (which would be 50% if we started at 0). With the current parameters, the pool will find in a year 210*10^9*86400*365.24 = 6.627*10^18 hashes, which is 6.627*10^18/2^32 = 1.543*10^9 shares, which is on average 1.543*10^9/1564057 = 986.5 blocks. Since this is distributed Poissonly, this is also the variance in the number of blocks found, so the standard deviation is sqrt(986.5) = 31.41. Our current balance is 685/50 = 13.7 blocks, so using the normal approximation to the Poisson, the probability that our balance will be less than 0 is the probability that a standard normal variable will be less than -13.7/31.41 = -0.4362, which is 33.13%. So the head start we have doesn't help too much.

Of course, the probability that the balance will be negative at some point during the year is higher, stay tuned...

[DrHaribo]

I'm considering different ways to implement variations of PPLNS in my pool. I like the idea of PPLNM, but I think it is vulnerable to pool hopping, as some said earlier in this thread.

PPLNM (pay-per-last-N-minutes):
If you mine for one hour while hashrate is low and leave before it goes higher for one hour,
1. there are fewer proofs-of-work in your hour, so they are worth more, and
2. there is a high chance of payout on those proofs, because the hashrate is high in the second hour.
This should result in above average pay.

Mining for an hour with high hashrate, then leaving before others mine one hour with low hashrate, has opposite effects. This means below average pay.

If the pool hashrate goes up and down, and you only mine at the bottom of the curve, you get a bigger share of the payments, doing a smaller share of the work.

Since there is an incentive for joining when the hashrate is going up, and leaving when it is going down, pool hoppers could create a rollercoaster effect on the pool hashrate, and the value of a proof-of-work would be very irregular. I guess it would take a few pool hoppers to make this happen though.

Maybe this is very exaggerated, but at least in theory pool hopping would work.

[Meni Rosenfeld]

Of course, the probability that the balance will be negative at some point during the year is higher, stay tuned...

Ok, according to my model, the probability is about 66%. This is reaffirmed by simulations I've run.

This is assuming the pool's proportion of the total network hashrate is as given, if it becomes higher the probability will increase.

I'm considering different ways to implement variations of PPLNS in my pool. I like the idea of PPLNM, but I think it is vulnerable to pool hopping, as some said earlier in this thread.

PPLNM (pay-per-last-N-minutes):
If you mine for one hour while hashrate is low and leave before it goes higher for one hour,
1. there are fewer proofs-of-work in your hour, so they are worth more, and
2. there is a high chance of payout on those proofs, because the hashrate is high in the second hour.
This should result in above average pay.

Mining for an hour with high hashrate, then leaving before others mine one hour with low hashrate, has opposite effects. This means below average pay.

If the pool hashrate goes up and down, and you only mine at the bottom of the curve, you get a bigger share of the payments, doing a smaller share of the work.

I don't think these will be the exact dynamics. There are two separate effects:

1. Stickyness: If you've already mined in this round, this increases your incentive to continue mining, since you'll raise the pool's hashrate and help it find a block before your old shares depreciate.
2. Opportunism: The probability that a block will be found before your new shares depreciate depends on the hashrate in the near future. On the other hand, their value if a block is found soon depends (inversely) on the average hashrate over the last N minutes. Thus, you are incentivized to mine when the hashrate is higher than the average.

What is the magnitude of the effect? Not too high, probably, but why take the risk when there is a purely advantageous alternative?

[DrHaribo]

Of course, the probability that the balance will be negative at some point during the year is higher, stay tuned...

Ok, according to my model, the probability is about 66%. This is reaffirmed by simulations I've run.

How is the probablity if there is a "withhold good proofs-of-work" attack with 1% of the pool's hashing power? What if the attacker has 50% of the hashing power?

This sort of attack would surely hurt any pool, but it would completely annihilate a small pool running any PPS-based payment method. I suppose someone would have to really hate you to waste hashing power destroying you instead of making money. But it's still a weakness with PPS-based methods, including SMPPS.

What is the magnitude of the effect? Not too high, probably, but why take the risk when there is a purely advantageous alternative?

I agree, PPLNM may be just fine in practice, but PPLNS looks even safer.

Still, there is the question of picking N. You could choose N/2, N, N*2, or perhaps a fixed value, say 1 million? I'm still thinking about how the choice of N will influence payouts for 24/7 miners, "casual" miners, and pool hoppers.

How is PPLNS affected at or near the time the difficulty changes? Can the difficulty change benefit poolhoppers in some way?

Is this something you can easily plug into your simulator?

[BurningToad]

Thanks Meni Rosenfeld!

[Meni Rosenfeld]

Of course, the probability that the balance will be negative at some point during the year is higher, stay tuned...

Ok, according to my model, the probability is about 66%. This is reaffirmed by simulations I've run.

How is the probablity if there is a "withhold good proofs-of-work" attack with 1% of the pool's hashing power? What if the attacker has 50% of the hashing power?

For the 1% case I get about 74% (I didn't triple-check it so I'm not certain that's correct). For 50% it will be virtually 100%.

What is the magnitude of the effect? Not too high, probably, but why take the risk when there is a purely advantageous alternative?

Still, there is the question of picking N. You could choose N/2, N, N*2, or perhaps a fixed value, say 1 million? I'm still thinking about how the choice of N will influence payouts for 24/7 miners, "casual" miners, and pool hoppers.

The way I see it, Increasing N has the following effects:
1. No effect on the average payout per share, no matter the mining pattern.
2. Less variance, again for all patterns (perhaps felt the most by intermittent miners).
3. More time in the beginning of the pool where there aren't N last shares and you need to decide what to do with the leftovers (give to the operator? Charity? Distribute among miners proportionally?)
4. More time between mining to knowing what your due payment is and receiving it.
5. If difficulty changes are not handled properly, more disruption caused by them.

How is PPLNS affected at or near the time the difficulty changes? Can the difficulty change benefit poolhoppers in some way?

I think the way to handle difficulty changes while remaining 100% hopping-proof is:
1. Express N in terms of blocks. For example you can choose N to be 1 block, and it will remain 1 block even after difficulty change.
2. Assign to each submitted share a score of 1/difficulty (the difficulty at the time of submitting the share).
3. When a block is found, distribute the reward among the last shares with a total score of N, proportionally to their scores.

Note also that for the geometric method I have studied this matter more thoroughly and can confirm that it remains correct in face of difficulty changes.

Thanks Meni Rosenfeld!

You're welcome .

[sirky]

*long confused post deleted*

Hey guys, I just want to make sure I understand what Meni is saying:

Shares to use from this round:
s1 = min(sum of all shares this difficulty, N * current difficulty)
Shares to use from last round:
s2 = min((1 - sum of all scores this round based on the last s1 shares) * N * old difficulty, 0)

All further calculations are based on only including the shares that you have submitted in the last s1 + s2 shares.

A miner's score:
(your valid shares this round / this difficulty + your valid shares last round / that difficulty)

A miner's payout:
50 * score