Search content
Sort by
Showing 20 of 154 results by bb
Quote
Can anyone hint me on why I am submitting shares to btlc, but not deepbit and polmine (all with mine_deepbit)?
that is what a lot of the discussion above is about. C00w is working on new methods to hop unhoppable pools. It works great for some, no so great for others. The debate above is about improving the methods. Obviously this is difficult as these pools were set up to not be hoppable. Most likely you have a worse connection to deepbit than you do for bclc. If you become concerned it is harming your rewards, then just disable the mine_deepbit pools, until the guys get the bugs worked out on the method.
Oh. I thought deepbit was working for everyone already. Especially with the IRC.
My simulator uses randomly generated round shares that are generated with simple algorithm mimics block finding procedure. (poisson process) To get statistically meaningful result, I used high quallity Mersenne Twister as a base pseudo-random generator.
pseudo code:
table of generated 120k round shares : http://cl.ly/8wg3
pseudo code:
Code:
var sparseness = RAND_MAX / BTC_DIFFICULTY;
var roundShare = 0
while (true)
{
++roundShare;
if (MTrand() < sparseness) break;
}
return roundShare;
var roundShare = 0
while (true)
{
++roundShare;
if (MTrand() < sparseness) break;
}
return roundShare;
table of generated 120k round shares : http://cl.ly/8wg3
I plotted your sample:
and a sample I produced:
Please excuse the missing labels. x-axis is number of shares (in percentage of difficulty), y-axis is number of occurances (summing over windows of 10000 shares).
The results differ slightly, most significantly at around 0.
You can't use anything that will provide a uniform random distribution. It has to be at least a binomially distributed random, and at best a time-distributed fractional poisson distribution.
I'm using the built in poisson distribution randomiser built into R with some jiggery pokery to make it a poisson time-distributed random(really share based) instead of the standard poisson distribution http://stat.ethz.ch/R-manual/R-patched/library/stats/html/Poisson.html. Ryouiki has a bespoke poisson randomiser built on mersenne twister as a random seeder.
I'm using the built in poisson distribution randomiser built into R with some jiggery pokery to make it a poisson time-distributed random(really share based) instead of the standard poisson distribution http://stat.ethz.ch/R-manual/R-patched/library/stats/html/Poisson.html. Ryouiki has a bespoke poisson randomiser built on mersenne twister as a random seeder.
The described method does not result in uniformly distributed pool shares.
Also in case you missed it, Meni replied to you here.
The motivation of your post - the fact that fallback is not necessary with many proportional pools - is not new. I've said this already here (Table B.1) and before that.
The reason it's unnecessary because when there are many pools, you never get to 43.5% - there will virtually always be a pool with less than that. So you don't need any of the "random threshold selection from the range [0.5, 1.5]" nonsense.
The reason it's unnecessary because when there are many pools, you never get to 43.5% - there will virtually always be a pool with less than that. So you don't need any of the "random threshold selection from the range [0.5, 1.5]" nonsense.
I had only seen organofcorti's simulation and had not seen your (unfinished) paper before. I knew there was a mathematical derivation. I am just better at programming than at probability theory.
In my simulation too, there is little to no time spent at the backup pool when hopping multiple pools. For six pools however I found that there is still some time spent at pools being at > 0.43 (see this post).
I assume you are giving each pool a table of random block find times (randomly generate a high-precision round percentile 0% to 100%, turn that percentile into number of individual hashes required using correct math, turn that into times using hashrate), and then are simulating the switching and share percentages earned.
No. I am using Meni's formula.
This should just shift pools (and speeds) around a bit, but doesn't change the outcome.
I assume you are giving each pool a table of random block find times (randomly generate a high-precision round percentile 0% to 100%, turn that percentile into number of individual hashes required using correct math, turn that into times using hashrate), and then are simulating the switching and share percentages earned.
No. I am using Meni's formula.
For more interesting real-world factors to model, analysis could be biased with a 'pool hop-in' time delay (like jumping 5 minutes after block find), and a 'wrong pool hop error rate' that reflects what people are seeing with early block-detection methods, when they get incorrect blockfinding because they aren't getting info from the pool that actually found a block, and jump to a false-positive.
I am guessing all these simply reduce efficiency.
In your simulations can you say how much time the hopper would spend at the PPS pool (or how much time there was spent with no pool being less than 43%)? If the amount of time spent at PPS is a tiny percentage (because of all the available prop pools) then the efficiency would seem to be high but not because you hop away from a pool, but because you are always hopping TO a pool that has low shares.
I ran a simulation at threshold 1.5 using the "real world" parameters.
From a total of 2750 BTC earned, only 0.03 BTC (essentially 0) came from the fair pool. This is basically just the consequence of the probability for all six pools beeing at 1.5 * difficulty being very low.
I ran the simulation again, recording how much time was spent at pools below/above a 0.43 treshold.
below 0.43: ~ 92%
above 0.43: ~ 8%
at fair pool: < 0.1%
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:
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.
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.
102. If your miners go down for a day the next block difficulty will be lower.
