Pool Hopping: The SIMPLE Solution!

[Meni Rosenfeld]

*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

Looks ok, if "round" means "difficulty adjustment period". Note that for very small pools or long windows, it is conceivable that the window will include shares from two adjustment periods back, which you'll also have to include in the calculation.

[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

Looks ok, if "round" means "difficulty adjustment period". Note that for very small pools or long windows, it is conceivable that the window will include shares from two adjustment periods back, which you'll also have to include in the calculation.

Yes, it does. And I will do a full fix.

And also:
 + s2 does not need the min, since the left will be 0 anyway if the entire score comes from the current difficulty
 + you need to divide the miner score by N

[sirky]

Here is some psuedocode which tells you how many shares to go back for PPLNS where you set N as a multiple of the difficulty:

currScore = 0; //score for this block
score[] //score for each round (most current difficulty first)
totalScore = sum(all scores over all blocks);
difficulty[] //the difficulty history (most current difficulty first)
shares[] //shares to use for calculations from a difficulty
totalSharesDiff[] //total shares mined during a difficulty
diffCount = 0;
quit = false;


while(!quit){
   shares[diffCount] = min(ceiling((N - currScore) * difficulty[diffCount]), totalSharesDiff[currScore])
   
   currScore += shares[diffCount] / difficulty[diffCount]

   if(currScore >= max(N, totalScore))
      quit = true
   diffCount++;
}

usedShares = sum(shares[]) //how many shares we actually go back in the DB when calculating payout


Here is a sample:

difficulty:
100   //oldest
500
1000   //newest - will be first in the array

totalSharesDiff:
413  //oldest
712
109  //newest - will be first in the array

N:
2

shares[0] = min (2 * 1000, 109) = 109
currScore = 109 / 1000 = .109
.109 < 2


shares[1] = min (1.891 * 500, 712) = 712
currScore += 712 / 500 = 1.424 + .109 = 1.533
1.533 < 2

shares[2] = min (ceiling(.467 * 100), 413) = min (47, 413) = 47
currScore += 47/100 = 1.533 + .47 = 2.003
2.003 >= 2

usedShares=868

Let me know if people agree with this. If there are any pools that are interested in actually using this I can create some psuedocode for actually calculating payouts to miner's as well.

[sirky]

Although, there is no reason that you wouldn't just include a score column in the database, and then you could just pull last x scores where sum(scores) < N

Which is exactly what Meni said.

Don't I feel silly

Anyway, maybe the above might be useful for someone

[Sukrim]

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.

So with 2 miners in the pool: miner A who submits 10 shares when difficulty was 10 and miner B who afterwards submits 1 share when the difficulty drops to 5 + hits a block, miner B gets 20% from the next block?

What I would also find interesting would be how to handle payout fluctuations (either right now already with transactions fees or more drastic in the future when the change to 25 BTC/block comes), especially in a PPS scenario.

Another thing I thought of is fractional reserving on SMPPS pools. If you don't do automatic payouts, or only at relatively high BTC values or intervals, you could temporarily go in a minus too without harming anyone (as you still have a lot of BTC from people that didn't pay out or can't pay out yet). Oblivious shares would still be much needed to make sure you don't get leeched by withholders, but in the end it could very well be possible to go in a minus too and still pay out full PPS values.

The big unknown part for me is how to deal with transaction fees in a PPS scenario (if you want to hand them out as pool operator too). Handing them out using PPLNS or similar systems would just sound like admitting defeat to me, but it might be the best thing to do in the end  (= VERY slowly switching from PPS to PPLNS over the years). For PPS I still would prefer something like RPPS with a floor: Paying out each round getwork_difficulty/global_difficulty per share to each share until there's no money left - starting from the most recent share.
This means some very old shares might never get paid (and you could/should include something that after 1 month or so shares that haven't been paid will never be paid and get deleted). There is some risk involved in mining in such a pool that some shares might not be paid, but in total it should be relatively safe to mine there (on/off as well as 24/7).

[sirky]

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.

So with 2 miners in the pool: miner A who submits 10 shares when difficulty was 10 and miner B who afterwards submits 1 share when the difficulty drops to 5 + hits a block, miner B gets 20% from the next block?

Assuming N = 1, yes. But this is fair, since PPS payouts would double as well, making it easier to earn BTC all over the network.

What I would also find interesting would be how to handle payout fluctuations (either right now already with transactions fees or more drastic in the future when the change to 25 BTC/block comes), especially in a PPS scenario.

Another thing I thought of is fractional reserving on SMPPS pools. If you don't do automatic payouts, or only at relatively high BTC values or intervals, you could temporarily go in a minus too without harming anyone (as you still have a lot of BTC from people that didn't pay out or can't pay out yet). Oblivious shares would still be much needed to make sure you don't get leeched by withholders, but in the end it could very well be possible to go in a minus too and still pay out full PPS values.

I would prefer that my pool operators take unneccessary risks that could bankrupt them. Basically they are taking a loan from the 'depositors' who haven't cashed out yet and are paying it out to people who have asked. If the pool ends up losing hashing, or something else, people won't get paid.

The big unknown part for me is how to deal with transaction fees in a PPS scenario (if you want to hand them out as pool operator too). Handing them out using PPLNS or similar systems would just sound like admitting defeat to me, but it might be the best thing to do in the end  (= VERY slowly switching from PPS to PPLNS over the years). For PPS I still would prefer something like RPPS with a floor: Paying out each round getwork_difficulty/global_difficulty per share to each share until there's no money left - starting from the most recent share.
This means some very old shares might never get paid (and you could/should include something that after 1 month or so shares that haven't been paid will never be paid and get deleted). There is some risk involved in mining in such a pool that some shares might not be paid, but in total it should be relatively safe to mine there (on/off as well as 24/7).

No one running PPS will want to hand out these fees, as they are taking tremendous risk already by running such a pool. And I would not mine at a pool where there was a chance that I would be underpaid when there are perfectly fair pools out there.

[Meni Rosenfeld]

No one running PPS will want to hand out these fees, as they are taking tremendous risk already by running such a pool. And I would not mine at a pool where there was a chance that I would be underpaid when there are perfectly fair pools out there.

On the contrary, PPS is the only kind of pool which can easily pay transaction fees. For every share submitted you just pay B/difficulty where B is the total block reward at the time. If the operator worries about his risks, he takes a pool fee.

For any other scoring method, I don't know of a way to guarantee the expected payout for every share is always exactly the solo average, when the block reward is unknown a priori. This is something for which a solution will have to be found as it becomes more relevant.

[sirky]

No one running PPS will want to hand out these fees, as they are taking tremendous risk already by running such a pool. And I would not mine at a pool where there was a chance that I would be underpaid when there are perfectly fair pools out there.

On the contrary, PPS is the only kind of pool which can easily pay transaction fees. For every share submitted you just pay B/difficulty where B is the total block reward at the time. If the operator worries about his risks, he takes a pool fee.

For any other scoring method, I don't know of a way to guarantee the expected payout for every share is always exactly the solo average, when the block reward is unknown a priori. This is something for which a solution will have to be found as it becomes more relevant.

What do you mean by total block reward at the time? Isn't that unknown until you solve a block?

I think I am confused as to what we are talking about.


As an aside, I want to thank you for trying to make mining better, even though there are still a preponderance of proportional pools

[Meni Rosenfeld]

What do you mean by total block reward at the time? Isn't that unknown until you solve a block?

When you calculate hashes of a header, you know what transactions are to be included in it, so you know what the reward of the block would be if the hash you find is valid (satisfies difficulty requirement). By extension, when you find a share, you know what the reward for it would have been if it was a valid block. So, if you're working on a header for which the coinbase+tx fees is B, if you mine solo your average payout is B/difficulty per share. This is also your average contribution if you mine for a pool. So in PPS, you're supposed to get B/difficulty for that share (minus fees).

As an aside, I want to thank you for trying to make mining better, even though there are still a preponderance of proportional pools

You're welcome. It's an uphill battle but you must never lose hope .

[sirky]

What do you mean by total block reward at the time? Isn't that unknown until you solve a block?

When you calculate hashes of a header, you know what transactions are to be included in it, so you know what the reward of the block would be if the hash you find is valid (satisfies difficulty requirement). By extension, when you find a share, you know what the reward for it would have been if it was a valid block. So, if you're working on a header for which the coinbase+tx fees is B, if you mine solo your average payout is B/difficulty per share. This is also your average contribution if you mine for a pool. So in PPS, you're supposed to get B/difficulty for that share (minus fees).

So essentially, you should get lower relative rewards just after the network finds a block, and higher rewards as the block gets older.

So basically, if you were intent on pool hopping, and had a really efficient system, you might mine a pool that pays out txfees right after the network finds a block, but if it has been a while (txfees are higher), you would solo mine instead?

[Meni Rosenfeld]

What do you mean by total block reward at the time? Isn't that unknown until you solve a block?

When you calculate hashes of a header, you know what transactions are to be included in it, so you know what the reward of the block would be if the hash you find is valid (satisfies difficulty requirement). By extension, when you find a share, you know what the reward for it would have been if it was a valid block. So, if you're working on a header for which the coinbase+tx fees is B, if you mine solo your average payout is B/difficulty per share. This is also your average contribution if you mine for a pool. So in PPS, you're supposed to get B/difficulty for that share (minus fees).

So essentially, you should get lower relative rewards just after the network finds a block, and higher rewards as the block gets older.

Yes, just as if you mined solo.

So basically, if you were intent on pool hopping, and had a really efficient system, you might mine a pool that pays out txfees right after the network finds a block, but if it has been a while (txfees are higher), you would solo mine instead?

This is a likely scenario, yes, but the details will depend on how the pool calculates payments.