Hop off thresholds revisited

A while ago @organofcorti claimed that our beloved hop off threshold of 43% does not make too much sense when hopping multiple pools.

Unsure about this claim (like so many others) I implemented (a very crude) pool hopping simulator myself and ran some simulations, the results of which I would like to share with you.

All these simulations run one miner at approximately 1 GH/s for about 1 year on what is now called the OldDefaultScheduler, meaning that the miner always jumps to the pool with the least shares. Also, there is a threshold variable (eg. t = 0.43). If there are no pools with less than t * difficulty shares, the miner hops to a fair pool.

The simulation does not use slicing. The pool speeds stay constant.

The standard case: one proportional pool

At first I ran the simulation with one proportional and one fair pool. This is the case @Raulo discussed in his original paper.

The simulated pool was running at about 500 GH/s.

The result shows the expected peak at about 0.43:

Two hoppable pools

Next I added another proportional pool.

The simulated pools were running at about 210 GH/s and 165 GH/s.

You can still see a peak somewhere around 0.40:

Real world simulation

Finally, I ran the simulation with six pools that were hopped at the time I started writing the simulation:

polmine, ~ 210 GH/s
MtRed, ~ 165 GH/s
triple, ~ 110 GH/s
ozco, ~ 55 GH/s
rfc, ~ 5 GH/s
btcmonkey, ~ 2.5 GH/s

In the result the peak is gone and between 0.40 up to at least 1.8 there is no visible drop in efficiency!

Conclusion

The results of my simulations agree with the findings of @organofcorti (and others). When using multiple pools for hopping (which is presently the common case), there is no need for a hop off threshold of 0.43. However, regarding efficiency, there does not seem to be any benefit in using a higher threshold either.

Choosing thresholds randomly when pool hopping makes it impossible for pool operators to identify you as a hopper for hopping off at 0.43. I therefore suggest implementing a random threshold selection from the range [0.5, 1.5] when there are multiple pools being hopped.