Topic: Pool Hopping: The SIMPLE Solution! (Read 7877 times)

Yes, just as if you mined solo.

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

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?

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

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

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

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.

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.


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.


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.

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

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

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.

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

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.

*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

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

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.

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.

You're welcome .

Thanks Meni Rosenfeld!

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.


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?

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 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?

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.

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

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.



 

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.