Bitcoin Forum

Has anyone done any tests to prove that pool hopping actually works? i know there's a paper published a while ago with mathematical proof that it works, but is there any tests confirming this?

edit:
link to pool hopping topic: https://forum.bitcoin.org/index.php?topic=3165.0

Can someone point me to that thread/article about pool hopping. I'm interested in reading about it and maybe adding to the newbies guide thanks :)

https://forum.bitcoin.org/index.php?topic=3165.0

Pools these days are designed to punish pool hopping, so it can't be done profitably.  This topic is only useful for people starting new pools--not sure it makes sense to have it in a newbies guide.

The largest pool (deepbit) is not designed to punish pool hopping. The only safeguard that it has against pool hopping is delaying statistics. But that only increases the difficulty of pool hopping, it does not prevent or punish.

Ahh, but then who would you hop to?

Any of the other smaller new pools that have no safeguards in place?

Or solo, or even Deepbit PPS.

It only matters that the pool you are hopping from doesn't implement score-based distribution. You can jump to one that does, like slush's. In fact, this helps you a bit because you'll get close to your EV for your hashrate quickly even if you come in late in a round.

Also it's easier to do this if the pool you're hopping from is small, so you can jump off after a 2 hour round or somesuch.

I was planning on implementing a proof of concept, but then I got bored. :P

so is there a consensus on whether it really works or not? It would be nice if someone could publish results showing whether it works or not.

Yes, it really works.

No, nobody has owned up to cheating everybody else out of money.

You can probably detect it statistically from the distribution of block times for the pool.  If there is pool hopping then there should be a longer tail.  In the extreme case (which obviously doesn't happen) once a block takes too long everyone hops out and the block never finishes (infinite block time).  I don't know for sure there is enough data to make a strong statistical inference on this, but I would guess there is.

I would bet every BTC I own that there is pool hopping happening on at a fairly large scale, and people have automated it.  And I agree that the way things are structured now the pools don't have a huge incentive to do anything about it. The best thing to do is avoid pools without good defenses. 

BitcoinPool was getting hit really hard with jumpers on long rounds a while back. They were seeing their hashrate get cut in half during long rounds.

Notice that this sucks for the pool even though some of these people aren't even doing it in order to game the system.  They just feel like the pool isn't paying out very well so they want to try something else.  People are going to hop from a pool with the unexploitable score system if the round is really long, but at least in that case it won't hurt the people who don't jump.

It works to improve your miner's efficiency. It's not cheating: as with all improvements to efficiency, those who don't do it end up with less. Unlike other efficiency improvements, it doesn't help the network. The end result when everyone uses it could be problematic.

I tend to agree as long as the pool doesn't have a rule against it.

Yeah, fair enough. Rules are rules, after all.

You can do more than just detect it. When Slush was planning on changing to score-based as a result of the paper, the comparison between share and score based pooling specifically showed three people who were pool-hopping. And this was a while ago.

Well, nobody *publicly* claimed that he's cheating others. But I'm sure that somebody implemented it, because free money are free money :).

I wanted to implement it (and openly demonstrated) because of never ending discussion with some people (who don't understant that it really works), but then lost a motivation. It's their problem that they didn't catch it (actually they later introduced some anti-hoping strategy, too; you know who :).

That's what I meant. "Owned up to" is an American idiom meaning "publicly admitted".

Oh, then excuse my ignorance :)

So if i wanted to pool hop, what kind of pool should i hop to? pay per share? proportional? score-based? I'm really interested in "improving" my efficiency as a miner :P

Score based ppols claim that they are more or less immune to pool hopping, you would look for share based pols probably.

A possible implementation would be a pool of pools, which moves around different pools depending on their solved blocks (conveniently announced in realtime by the pool via long polling).

One of the most difficult variables to get is the current hash rate of the pool, you would have to operate with older data + estimates. As new pools are currently popping up and miners join and leave, this number might not be too accurate (check out http://eligius.st/~artefact2/ for example, how much the hash rate fluctuates) thus screwing your calculations on how long to stay in each round.

In the end pool hopping is NOT cheating! You do all the work you have to do etc.
To NOT pool hop however harms your income by up to 28%.

As I don't have a server at my hands and I guess a dedicated pool-hopping pool might be popular for miners, but not pool operators (as they would get slammed with a lot of GH/s at the start of a round and then suddenly the miners move on to the next pool) I probably won't implement something like this in the public and would advise other to do the same.

You always mine at the proportional pool which has the least shares in the current round. Once all such pools have >43.5% difficulty, you move to a score-based pool like Continuum.

Arguing on whether to call it "cheating" or "not cheating" is a red herring.
The facts are:
If one person does it, his payout is greater than his contribution to the pool (or to the Bitcoin network at large), and for others it's less. In this sense he does not do "all the work he has to do".
If everyone does it, all proportional pools freeze and people will mine in score-based / solo anyway.
So why add unfruitful complication by having proportional pools exists in the first place?

Small score based pools get completely unattractive to be joined by anyone, if they haven't very recently found a block.


Score based pools are only working very well for 24/7 miners, if you don't mine all the time, you will loose income when using a score based pool to the 24/7 miners.
If you want to open a new pool, you better make it proportional and after some "critical mass" has been reached, switch to score based to ensure a steady and more fair income if you wish.

I personally wouldn't join a score based small pool where blocks are only found every 3-4 days, as the risk of "buying in" with (depending on my hashrate vs. pool hashrate) quite some BTC in the beginning is too high for me.

One reason is that people like simple ("fair") pricing schemes even they aren't economically efficient.  This is an empirical result that applies to Homo Sapiens as opposed to Homo Economicus.

Put two pools side by side, one with each payout method and I'm sure a significant number of people will strongly prefer proportional even if they aren't going to pool hop and understand that they will make less as a result.  Think of it as a fee.

This is not true. If you mine intermittently on score based pool you only increase your variance but the average income will be proportional to your contributed shares. You will quickly lose score if you stop mining but you quickly gain if you start. If you mine from the start of the round to the half time of the round, you'll get close to zero. But if you join at half time of the round, you'll get almost full payout while contributing only half of the shares. In long term, it'll all average out.

This is not taking into account difficulty changes. If you're unlucky and miss payouts currently, there might (with increasing difficulty) be no way to make up for that loss via luck.

If a mining pool grows slower than the network, the payout will be less and less. Also there is the risk of people leaving the pool (see slush...) before you have made up for bad luck.


On the other hand, you might be lucky too, join late in an early round and then continue in a growing pool that keeps up with the global hashrate.

In the end ppl. mine in pools to reduce variance as far as possible - introducing variance is often not so cool. Otherwise no sane person would be mining with PPS on deepbit (or any other pool that charges fees).

And if you are lucky, you will be ahead. It all averages out.

By the way, difficulty changes are completely irrelevant if you mine regularly (it does not have to be constantly). I really don't know why people care about difficulty changes at all. The only thing that matters is what is your hashrate ratio relative to the current global hashrate. This is all continuous. If the current difficulty correspond to, say 3TH/s hashrate but the network is at 4TH/s, you will get the same number of coins per month as if the difficulty was corresponding to 4TH/s and hashrate equal to 4TH/s because in the former case the round will be shorter. 

Over many people, not over a single miner!

In my opinion, there should be as little "luck" needed in pooled mining as possible.

There is already some variance that comes from pools not having 100% of the mining power of the network, but every further introduction of "luck" (or call it variance) introduces also "bad luck" for others.

Score based mining is imo only useful for pools that have ~5%+ of the network hashrate. This means that on average every ~3 hours a block will be solved, so people jumping in don't get screwed over too much due to being late on a profitable round.

If you have a small pool however where you can expect finished blocks only every few days or so, it might happen that an honest on-off miner might loose out significantly.

Maybe it might be useful to do some calculations which pool is recommendable based on your mining habits ("2 hours/day means you'll need to join a score based pool with at least x% of the network hash rate to minimize initial variance")?

No. Over a single miner. His expected payout is equal to his contribution. So if he keeps his intermittent mining over a long period of time, his total reward will be close to his total contribution.

Can you show your calculation why this is so?

I think you're confused about how score-based works. If you join at a time which, in retrospect, is late in the round, you will get more reward. Of course, you don't know beforehand when the round will end, so whenever you join your expectation is the same.
In fact, it is true for proportional pools that if you join late in a round you'll get screwed.

Again, it might happens that he has bad luck, but his expectation is equal to his contribution.

This will depend on greatly on the miner's risk averseness. Because in most cases variance is less important than expectation, and because the variance of score-based is not that high, the best recommendation is to always use score-based.

It seems hard to make that argument in this context.  If people wanted to maximize expectation, they would just solo-mine and avoid pool fees, pool downtime, stale shares, etc.  In most cases the variance is extremely "large" but in absolute terms the amount of money involved for a hobby miner is small enough that it doesn't really matter.   

I will grant that many hobby-scale miners don't understand this and don't act that way in practice.


True.  But still you are ignoring mental accounting costs.  People like equal shares because they are simple and easy to understand.  If you are hoping for pool participants to understand game theoretic indifference, you're going to be disappointed.  The constant push back (even if mathematically incorrect) over score-based pools being "unfair" should be ample illustration of this.

Look, I'll confess (anonymously), I pool hop and it works.

Pool hopping is not cheating - it is optimizing. It is the responsibility of pool operators to implement algorithms that are fair. I'd think of all people, cypherpunks like bitcoin miners would be the first ones to recognize this fact. If you place all your trust into math, don't suddenly complain about fairness if your math turns out to not be good enough.

Hopping away from a single pool (at 43% of mean round time) earns 30% more. Hopping between a couple pools (I have 4 currently automated) earns me 70% more. If you'd automate a dozen pools, you could earn more than 100% extra.

Slush's pool is not secure because he messed up his algorithm. I earn 20% more on his pool. Deepbit pool is not secure, because they got a large market share. If no other pool solved the block (which I know automatically), it was most likely deepbit, even if their statistics are delayed by an hour.

Pool hopping is not too common. I've analyzed the statistics of the pools I use, and less than 5% of users pool hop, so "unsofisticated" pool miners only loose 2-5% of income. After publishing this post, I expect hopping to become more common.

What I want to happen is for pool miners to implement mathematically-fair payment algorithms. This is the solution best for the community in the end, but not manually enforcing no-hopping rules or withholding information. There is a complicated score-based algorithm published somewhere on this forum (not slush's algorithm) that seems secure, though I didn't check it in too much detail. There is a much simpler fair algorithm though, which I want you to confirm: pay for all shares submitted in the last 1 hour of a round. If a block is found sooner than 1 hour into a round, then rollover the extra time and pay for the unpaid shares of the previous round, or the previous round before that (if the previous round was shorter than an hour as well), and so on. This way, each share has equal expected utility regardless of when it is submitted - early on or late in a round. Late shares in long rounds are subsidized by early shares in short rounds. You can use any time interval shorter than the mean round time. I'd recommend 1/4 of the mean time, e.g. 1 hour for a 130GHash/s pool.

@anon4758 - this is some very useful info, thanks for sharing!

I generally agree, I mentioned elsewhere that I don't have a beef with hoppers, rather with operators of proportional pools.

In the theoretical limit of infinitely many proportional pools and perfect hopping, I think you get log(difficulty) times normal, which currently is X13, or 1200% extra.

I know, slush's has several flaws which is why I devised my method (http://forum.bitcoin.org/index.php?topic=4787.0) which I named the "geometric method".
Surely you don't get a lot of volume on slush with this profit?

You're probably referring to the geometric method. But hey, it's not complicated at all. Most of the post is just analysis of its various features.

Even if this works (which I'll try to look at at some point) it seems much more complicated.


The huge variance of solo mining is under the scope of the "other cases". But once you cut down, say, 99% of the variance with a score pool, there's not much point in decreasing it further.

Right, but if they want to go for "simple and understood", why not PPS? It has the least variance, it's simplest, and it has higher expectation than worst-case presence of hoppers.

I don't know how popular PPS is.  It seems like it must have a pretty significant appeal if anyone uses it given the fees that are charged for it, and the fact that people still post saying, "I'm using PPS on such-and-such pool, how can I make more monies?"

If it weren't for the block withholding attacks, PPS might be more popular (and less expensive).

Also, given how people start freaking out every time the PPS rate "drops" because the difficulty goes up, PPS is not necessarily as "simple" as proportional.  "We work together to solve blocks and divide them up according to effort" is about as easy to understand (or so people think!) as it gets.

You have to realize that any argument that follows that script is lost, right?

Especially when you are responding to someone who actually demonstrated way above average understanding of pooled mining payout methods.  Think about how it looks from the perspective of miners who don't understand these things half as well as "anon4758," and you will understand why people like proportional.

Can you be more specific? Looks like you found (or you think that you found) some mistake in score implementation, but currently I don't know about any.

@Meni Rosenfeld

Thank you, yours was the algorithm I was referring to! That is the single most insightful and precise mathematical analysis on these forums, and I did not mean to bash it. I guess I am merely dissatisfied with score-based methods in general, because they make it less clear intuitively how much each share is worth. There is also the problem with large exponential numbers that need to be rescaled for long rounds (or stored as logarithms). Ultimately though, any fair method is better than naive method.

@slush
The decay constant of 300 seconds means that the shares of the past 5 minutes are worth 2.7 times as much as all the previous shares combined, so you are not burdened with others' old shares when mining in a long round. But there is a high variance (you aren't getting anything unless you happen to mine in the last 5 minutes of a round) and you still have the deadweight of the last 5 minutes' worth of shares, such that after about 1/2 mean round time, you are mining at only 90% efficiency (efficiency doesn't keep going down below 90% though, unlike with standard shares). Up to 15% mean time, efficiency is greater than 100%, and it is greater than 200% in the first couple minutes, so I get 20% extra on average (across entire round time) by hopping. Using shorter decay constant would decrease the gain, but would increase the variance even more.

Perhaps I should mention that I had suggested a protocol change (http://forum.bitcoin.org/index.php?topic=6577.0) that would make this attack impossible?

Point taken, but I'm not sure participants necessarily have to know the details of the scoring method, any more than they need to know what hashing is or how the block chain works. I think also with some charts and graphs we can make it easier to understand.


@slush - The geometric method has two advantages:
1. Score fee - Using this, the pool is at a steady state where the past is always the same. In your pool you do not use a score fee, so very early in the round shares submitted compete with less existing shares, increasing payout. After a while it converges to a steady state. Shortening the time constant speeds up convergence and thus improves hopping-resilience, but adds variance to miners. By the way, the time constant should be proportional to the average time of finding blocks to maintain a specific tradeoff.
2. Share-base decay - Your pool uses time-based decay, which creates several quirks and attack vectors. For example, if the hashrate of the pool fluctuates and is currently more than average, the expected time to round completion (and hence, the expected depreciation of shares submitted now) decreases and it's more profitable to join.
PS. You promised a while back that you would look at my suggested method.

@anon4758 - Can you share with us, do you also post on this forum regularly under a different identity? (Obviously I don't expect you to say what that identity is.)

@Meni Rosenfeld
I mostly lurk. So
is an accurate description.

I just wonder how you realized your pool hopping method (manual might be interesting for a short time, but is not really feasible).

Also how to decide in reality to which pool to jump - imagine mining still in the 43% margin of pool 1 but then pool 2 finds a share. Should you then jump to pool 2 or mine until 43% on pool 1 and risk not having a pool to immediately jump to?

So in the end: Is it smarter to hop off as early as possible or as late as possible? Could/should it be weighted somewhere in between?

I bet you get also tons of PMs now! :D

In the simplest model, you always want to mine for the pool with the least shares in the current round.
So if your current pool has 30% and some other pool has 0% or 10%, you hop.
The next step is to take into account the time wasted reconnecting to a new pool. If the difference is very small it is generally better to stay.
It will probably be beneficial to have several miners pointed at different pools with similar age.
Thus goes the theory, anon will have to discuss how he implemented this.

That's right, you jump to the shares-based pool with the presently lowest round_time/mean_round_time fraction, or score-based pool if none are below 43% fraction. The switching takes only a second and is not a problem. I use a script to query the pools periodically/whenever bitcoind reports a new block and redirect the miners as necessary. This also simultaneously solves the unplanned pool downtime issue. Interestingly, bitcoind always reports new blocks at the same time as pools pushing new longpoll work, or no more than 10 seconds apart. Since the daemon and the miners use entirely different connections, that means transactions/block solutions are being propagated across the entire bitcoin network within 10 seconds or less on average.

isn't it better to stay with a pool until 43%, rather than switching to the lowest % pool? the graph in Raulo's paper shows that leaving before 43% carries a steep penalty.

Actually you should stay at least ~20% and max. ~60% of the expected round time in a proportional pool. Hopping off below ~20% is not a very smart decision, above 60 or 70% it gets more and more useless. 43% still is the optimum, but if you jump off at 40 it might be a better thing to do than to risk mining until 70%.

In practice you would probably have to rank pools according to their hash rate and if a pool finds a block, evaluate if it makes more sense to stay in the current pool or to hop on to the next candidate.

Raulo discusses the case of one proportional pool, when the choice is to switch from it to solo/score-based.

You all need to remember there isn't a magical tooth fairy that comes and gives you monies when you do the act of switching pools. It's all a matter of finding the expected payout right now for every pool and going with the one for which it is highest. For proportional pools the payout is determined strictly as a decreasing function of the current round age. For >43.5% it becomes less than solo/score.

Not really - the pool that has just found a block is always the best, though it might be better to switch back to a slower pool at some later time. There is no penalty. The utility of each submitted share is independent of any other share (unless you are a dominant contributor to the pool).

For difficulty d and pool hashrate R, the probability that the round will end in exactly time t is:
$ p(t) = \frac{R}{2^{32}d} e^{\frac{-tR}{2^{32}d}} $
If we express time in units of mean lifetime $ Tm = \frac{2^{32}d}{R} = 1 $, this simplifies to:
$ p(t) = e^{-t} $
The expected reward for a single hash submitted T time into a round is the integral over all possible total round times of this probability divided by the total number of pool hashes in the round:
$ E(T) = \int_T^\infty \frac{e^{-(t-T)}}{Rt} dt = \frac{e^T}{R} \int_T^\infty \frac{e^{-t}}{t} dt = -\frac{e^T}{R} Ei(-T) $
Your solo expected reward is always 1/(d*2^32), so your pool/solo reward ratio, or efficiency, is (using mean lifetime units, where d*2^32/R = 1):
$ r(T) = -e^T Ei(-T) $
http://www.wolframalpha.com/input/?i=+-e^T+Ei%28-T%29+%3D+1 (http://www.wolframalpha.com/input/?i=+-e^T+Ei%28-T%29+%3D+1)
The efficiency drops below 100% at exactly 0.434818... mean lifetimes into a round. Efficiency is pretty high early on though. When mining solo, you earn $ \int_0^{0.4348} e^{-T} dT = 35.26\% $ of all your rewards during the 0 to 43.58% mean lifetime round interval, but in a pool you earn $ \int_0^{0.4348} -Ei(-T) dT = 63.41\% $ of your total rewards in that interval - a 79.83% bonus. Across all time, your average reward is highest if you hop at 43% point:
$ \int_0^{0.4348} -Ei(-T) dT + \int_{0.4348}^\infty e^{-T} dT = 1.2814 $ - a 28% bonus. Multi-pool hopping works even better, since you always pick the pool with the highest current expected reward, which is the pool with the smallest round time/mean round time ratio. As I said, I only rotate between four pools, and not always is there a pool with round time below 43%, so I average about 70% extra efficiency over entire time, but the bonus can be pushed above 100% using many more pools.

It is somewhat of a philosophical question of whether 1% here and there really makes a difference, and whether you should actually care whether it is 43% or 43.5% or whatever, but this is what the math says. Again, since hopping only takes a second, you take no time penalty from doing so anytime you wish.

For Slush: the score-based method, as implemented, is better, but not perfect. If a share at time t into a round gets a score $ s = u + e^{t/v} $ where v, the decay constant, is 300 seconds and u is 1 (it doesn't make much difference actually), the total score of a round of length t is:
$ s(t) = \int_0^t R (u+e^{t/v}) dt = R (ut + v(e^{t/v} - 1)) $
And the expected reward ratio for a share submitted T time into a round is (using the reduction d*2^32/R =1 ):
$ r(T) = \int_T^\infty \frac {e^{-(t-T)}(u + e^{T/v})} {ut + v(e^{t/v}-1)} dt $
I don't have a plot of this curve unfortunately, only some numerical approximations. For 542GHash/s, Tm is 3446 seconds, so decay constant v is 0.0871Tm. and assuming u=1:
r(0.01)=261.40% (http://www.wolframalpha.com/input/?i=integral+%28e^%28-%28t-0.01%29%29%281+%2B+e^%280.01%2F0.0871%29%29%29+%2F+%28t+%2B+0.0871%28e^%28t%2F0.0871%29-1%29%29+dt+from+0.01+to+infinity)
r(0.10)=109.87% (http://www.wolframalpha.com/input/?i=integral+%28e^%28-%28t-0.1%29%29%281+%2B+e^%280.1%2F0.0871%29%29%29+%2F+%28t+%2B+0.0871%28e^%28t%2F0.0871%29-1%29%29+dt+from+0.1+to+infinity)
r(0.14)=99.25% (http://www.wolframalpha.com/input/?i=integral+%28e^%28-%28t-.14%29%29%281+%2B+e^%28.14%2F0.0871%29%29%29+%2F+%28t+%2B+0.0871%28e^%28t%2F0.0871%29-1%29%29+dt+from+.14+to+infinity)
r(0.43)=91.15% (http://www.wolframalpha.com/input/?i=integral+%28e^%28-%28t-0.43%29%29%281+%2B+e^%280.43%2F0.0871%29%29%29+%2F+%28t+%2B+0.0871%28e^%28t%2F0.0871%29-1%29%29+dt+from+0.43+to+infinity)
r(1.00)=91.98% (http://www.wolframalpha.com/input/?i=integral+%28e^%28-%28t-1%29%29%281+%2B+e^%281%2F0.0871%29%29%29+%2F+%28t+%2B+0.0871%28e^%28t%2F0.0871%29-1%29%29+dt+from+1+to+infinity)
r(10.00)=91.99% (http://www.wolframalpha.com/input/?i=integral+%28e^%28-%28t-10%29%29%281+%2B+e^%2810%2F0.0871%29%29%29+%2F+%28t+%2B+0.0871%28e^%28t%2F0.0871%29-1%29%29+dt+from+10+to+infinity)
The important point to see here is that the expected reward ratio is not 100%, as claimed, but rather drops below 100% at 14% round mean lifetime, and hovers around 92% from there on. Averaged over all time, I can make 10%-20% extra by only mining in slush's pool in the first 14% of a round.

Again, I recommend pool operators to familiarize themselves with the math that makes pool-hopping efficient, and implement an algorithm, like Meni Rosenfeld's geometric score, that is provably neutral. I also request people to review my constant-time proposal, since I believe it would be easier to implement/understand than exponential scores (linked lists instead of logarithm math).

I haven't checked all your math but although slush's method is hopping prone and it can be proved, by no means you can get 10-20% more out of it. You must have forgotten how rare are the short rounds and for long rounds, you'll get virtually zero by staying during 14% of the round. We have done simulations with Slush and it resulted in about 2-3% gain at that time.



It may be easier to understand but was much easier to implement by slush because he does not have to keep all the shares in memory, only the score. Moreover,
your proposal is nothing more than an elaborate pay par share method which may be good for pool users but is very risky for the pool operators.

Ah, thanks for the insights! I was already wondering why early hopping sould be bad at all, as early shares should be the most valuable anyways (as for example in a case where a block gets solved after just 10 shares by 10000 miners, the 10 lucky share submitters would get FAR more than expected).

OK. Now I get it what you mean by 10-20% more. This is 10-20% more out of slush's pool. If you mined solo for the rest of your hashrate, it would be 6% of your total hashrate. When slush implemented the pool, there were no other pools and the hopping reward was somewhat smaller. With multiple pools, it might be worth the fuss. 

I've just did a Monte-Carlo simulation for decay constant 0.0871 and hopping cut-off 0.14 and you get
reward equal to 19.4% of your total hashrate out of the pool, while one should have gotten only 13.2%. So it is 6% of your hashrate extra (assuming you mined solo or pay par share pool the rest of the time) but more than 40% more out of the shares submitted to the pool. Pool owner can reduce it by decreasing decay constant while increasing variance but it's hard to reduce it completely without increasing the variance excessively.



This geometric score requires either huge fees or introduce a payoff variance for the pool operators which may be unacceptable for them.

It can't be right. First of all, hopping reward is completely independent of difficulty.  1GH/s hopper @ difficulty 100000 gets the same reward as 2GH/s hopper @ difficulty 200000. Secondly, even with infinite number of pools, there is a finite number of blocks. With 6 blocks/hours you can only make 6 hops an hour and some of the hops are impossible to do (you cannot hop to solo miners). My guess based on the intuition I gained working on this problem is that in the limit of infinite number of proportional pools, all global hashrate contributed by the pools you can hop into, and optimal hopping, you can probably get about 100-150% more. I'm yet to derive it or program a simulator. This number is reduced if some hashrate is from solo mining and if the pool operators introduce countermeasures. I doubt that anon4758 can get further beyond his 70% by more than a few percent because he probably hops among almost all the hashrate available for hopping.

The model you've analyzed in the paper is continuous and does not take into account share granularity. If p=1/difficulty and you submit to a proportional pool the very first share in a round, you'll note that your expected payout is $\sum_{i=1}^{\infty}p(1-p)^{i-1}\frac1i \approx -\log p$.

However, you are correct that I have not taken into account that you will also need infinitely many blocks for this. So what we can say is: With perfect hopping, you can get X13, but not continuously - rather, you run your miner only when a proportional pool has a new round, which will give you the measly volume of 1 share per block found by a proportional pool. This result is of course of no practical significance, but generally analyzing intermittent mining may be important if electricity is a large portion of the cost.

With a correct choice of parameters, the variance can be acceptable for both the operator and the participants.
At current difficulty, with c = 0.00015 and f = 0.02-c, you get 2% average fee and a variance reduction of X133 for both operator and participants, compared to having the same payout mining solo. This isn't bad.
If you want to give up a little hopping-resistance to gain a little variance-reduction, you can decrease the operator's score for a given r. slush basically reduces it to 0 and thus has only a little resistance, but you can find a better balance.
But the decay based on shares rather than time is a pure advantage which should be adopted even if score fee is eschewed.
I don't know where you got the part about huge fees.

You are right. I finally found an integrator that works, and between 0% and 14% round time, I get 19.80% of my total reward in slush's pool, compared to 13.06% of total reward while mining solo - a 52% premium, but only 6.7% over all time. Of course, if the network hashing power were divided equally among 6 score-based pools, then instead of only 14% of the time, I could mine at a premium 84% of the time (or however much it adds up to), for a 40% (or however much) total premium. However, since the majority of the network hashing power is currently in share-based pools, that is not even necessary.

That is all correct. Sometimes I forget that the real world is discrete. The utility of the very first share in a round is not infinite but very much finite (x13 seems reasonable), since shares are not infinitely divisible and integrable. Also I agree that the maximum theoretical efficiency of multi-pool hopping is limited by the fact that on average no more than 6 blocks can be found per hour.

Keeping a stack of several million of the latest shares is not particularly memory-intensive. Even less-so if the oldest shares are offloaded to disk, before sometime later all record of them is finally deleted (very old shares are exponentially-unlikely to be needed for payout). Also, it is not pay-per-share and carries no risk for the operator, since all payouts come from each solved block and not out-of-pocket.

I think this indeed works. Your payout for a submitted share only depends on the future and not the past, so you can't hop. And it has a significant variance advantage over the geometric method. However:
1. You need to base the window on number of shares, not time. Time-based methods are a mess and open to hashrate fluctuation attacks.
2. You'll need to decide what to do with a short round when the pool starts, and there are no previous rounds to draw on. You could let the operator take the leftover, or distribute it between the shares (thus creating an expectation bonus early in the life of the pool).
3. You'll need to figure out how to make the payout invariant to changes in difficulty (should be doable).
4. You'll need to handle the case of changing the window length and fees. With other methods, each round is self-contained so you can change parameters between rounds. But here, a contingent future change may affect the current expectation.

Yes, pool hopping works.  And it is lots of fun if done to pools where the owners don't believe it works.  I still see that people are successfully hopping on that certain unnamed pool.

I was going to write a simulation of the score based system, but I see that you guys have that well under control.  It simply amazes me that people are so clueless when it comes to (what seems to me) simple math.

All right, taking Meni Rosenfeld's considerations into account, how is this for a formal proposal for a constant-share pool:

1. When the round ends, the pool will use the block reward (minus fee) to pay equally for all of the latest "difficulty/2" shares
The mean number of shares in a round is always equal to the difficulty, regardless of pool size, since each share is a solution of difficulty 1, and each share has 1/d probability of solving the block. In comparison to share-based pools, on average, you will be paid for exactly half of the shares you submit to the pool (twice as much, of course), and the reward will be constant if your hashing power as a fraction of the pool's total hashing power is constant.

2. If there are less than d/2 shares in the round, the pool with use the rollover reward to pay for the latest unpaid shares in the previous round(s)
The rollover eliminates the risk of pool hopping, since there is never an advantage or disadvantage to mine very early or very late in a round.

3. The pool will cache the last 10d shares, in case there is a very lucky streak of very short rounds
There needs to be a cache of sufficient size for the rollover to be effective. With a cache of size 10d and payout slices of size d/2, there is a (very roughly) 1/2^20 (one in a million) chance that the cache will soon be exhausted.

4. If there are lucky blocks at the very start of the pool's lifetime, the pool will hold on to the rollover to distribute to the miners in the unlikely/inevitable event that the pool is shut down permanently
This is a mostly trivial point and you have to trust the pool operator to carry through with this promise, but this terminal fund simultaneously resolves two problems:
a) The end-of-life problem: if a pool is shut down, the round never ends and the miners who contributed to it are left holding an empty bag. But with the terminal fund, the miners can continue to mine with security, even if there is uncertainty of whether the pool is about to close.
b) The initial pool problem - what to do with the rollover at the beginning of a pool's lifetime. The fund is a clever way to short circuit the end of the pool's lifetime to its beginning, tying up all loose ends. The other two alternatives are to distribute the bonus to the miners - the early adopter advantage - or for the operator to keep it.

5. When difficulty changes, the reward interval follows; the rollovers will occur as normal, except that older shares have a higher weight equal to "new difficulty/old difficulty"
The reward interval is fixed to difficulty/2 to maintain constant variance, regardless of pool or network size. This necessitates using correct transitions during difficulty changes. I believe the above is the correct way to transition. Shares after difficulty change are worth proportionally less than shares before change, because they are instantaneously less likely to solve the block. People complain why PPS dropped so much so quickly - it all has to be tied directly into the difficulty. This method also accurately handles difficulty decreases.

Finally, here (http://pastebin.com/yg3QTB2W) is my reference implementation of the constant-share pool, written in perl. The first part is the actual algorithm demonstrating the details of the rollover and the difficulty changes. The second part is a simulation of a typical pool that uses constant-share payments. Run the program to see the pool operate. Notice the memory usage: the stack takes up about ~100 bytes per share, or 400MB for a full cache at current 400k difficulty - manageable even in the implementation's current state. Of course, perl is memory-inefficient, and in a production implementation, the stack should only take up 4 bytes per share (a single integer user id), be stored in a database, and be periodically saved to disk. As difficulty increases, the stack would grow, but as pools decide to increase work difficulties higher than 1 to relieve pool load, fewer shares will need to be cached for payout calculations.

Hi @anon4758!

I independently came up with something similar in an Eligius discussion, called it Pay-Per-Last-N-Shares (PPLNS), and documented it on the Eligius wiki..

http://eligius.st/wiki/index.php/Pay-Per-Last-N-Shares

Notably I don't think it changes the math if..

1. the 'lookback' is any consistent multiple of the difficulty

2. shares get paid multiple times in the event of quick hits, rather than searching back for the last still-unpaid shares

In both cases, the expected return for the marginal next-contributed share remains the same. Having a larger lookback can lessen some miners' unease with the idea recent shares get paid nothing. Paying shares within the lookback multiply puts a hard cap on the amount of sharedata to cache to calculate payouts.

I hadn't considered difficulty transitions but your adjustment factor may be the right thing.

The startup issue seems so small I would simply suggest that until N shares are contributed, the pool can be proportional.. an extra bonus for founding miners if a quick hit is made.

Similarly the shutdown issue.. a surprise shutdown doesn't benefit anyone disproportionately.. all participants pro-rata experience loss of expected return from shares never collected.