Topic: "How to hop" has moved - page 4. (Read 16281 times)

thank you both for working on this, @meni hope you appreciate the small donation a sent you for your time, in Europe that buys you a latte . I hope in the future you will try figuring out more things related to score type of payouts under real world production environments.

@organof, until now this seems to be an interesting project to graph and thanks again for starting the "ball rolling".
We only had theoretical figures on every payout system, so this small experiment should make us an idea on the subject and free us from the burden of testing it in a real mining rig for the time being.
I know that miners have to take into account 3 main parameters when choosing their mining profile: self mining efficiency (under miner control), Internet and power connectivity (not always under control), pool variance (pool speed and popularity are two factors that go hand in hand to affect it). Those would be the main variables that depend on lots of sub-parameters on their own. I supposed that any change in one of the three affects payouts some way and preliminary results you and meni posted seem to go that direction too.
Hope you show us some nice comparing graphs soon and help us get more educated in the process  

Well, seeing as my results before the edit were completely nonsensical, maybe they shouldn't be trusted too much . In my defense I did disclaim I hadn't taken the time to verify this properly.

Yeah, I doubt you'll be able to simulate properly such small differences. Also maybe there's a difference between slush and PPLNM, and maybe there are additional discrepancies in the scenarios we've looked at.

Thank you kindly for that, Meni - very quick. I hope that the analysis makes it into AoBpmrs, although I can't see it becoming a problem unless someone develops that exahash farm   Or hopping tiny PPLNS-H pool comes into vogue. So there's one answer for you, paraipan!

If my following excuses about the errors I had in my last simulator attempt are not interesting for you, please go to the Results so far: paragraph.

So I had some errors in my last attempt at a simulation (which showed that 0.7% increase in efficiency for non-intermittent fulltime miners). For the intermittent miner, that increase was more like 1%. I think I've fixed these particular errors:

1. I was trying to make the simulator as efficient as possible and I was using some old techniques to do this. One of them was to assume all miners submitted shares evenly each time period (say every second). I changed this to a different and much less efficient method using Poisson random variables to determine when and how many of each share would be received by the pool and the error disappeared. I really don't know why.

2. Because of the original naive method of simulating Slush's pool I used a simple method of creating 'random' periods of downtime which happened to slightly favour the latter parts of a round. This made the miner a hopper, and made the increase in efficiency about 1%, which is clearly wrong. In my new method I treat the rounds as a very long string of share submissions and overlay random periods of downtime for the fulltime miner under investigation.

Variables: For the non-intermittent fulltime miner I've used 1Ghps hash generation rate with a 1000Ghps pool, making a hashrate ratio of 0.001. For the intermittent miner downtime is 0.05% with a string of as many downtimes as there are rounds. The downtimes also appear at times based on a uniform random variable because I simply don't have enough information to decide on a different probability distribution. The downtimes are exactly D*0.05 long, giving an efective hashrate of 0.95Ghps for the intermittent miner when averaged over many rounds - but this can vary significantly by round, especially on shorter rounds - no downtime on some short rounds and completely preventing submission during other short rounds. Longer rounds are affected by this variability less.

Results so far: I'm finding that for an intermittent miner the Slush scored payouts are an average of about 99.9% of the proportional pool payout, although I have a thousand or so rounds to run in total with only 400 completed so that figure may change. It is significantly worse than Meni's estimate for an intermittent miner in a PPLNS-H pool. I don't know if this reflects irl results, but it isn't a large enough difference to make a significant difference to the charts.

Possible modifications: I still have a few tricks up my sleeve if necessary - I'd like to model the downtime onsets as a Poisson random variable with an estimated arrival time of once per round (I could be quite wrong with this oversimplification, but ignoring external factors I guess that the probability of downtime per unit time is constant - very wrong if external factors like brownouts due to excessive power usage at certain times of day are to blame for the downtimes). Unfortunately generating and managing long strings of numbers slows things down significantly so I wont be doing this unless I have to. I could also model the length of downtimes as a uniform random variable which creates downtimes of 0 - 10%, but again I don't know whether this models the irl downtimes.

I'll post the charts when I have the thousand rounds worth of data completed and the charts prettified.

Requests Anyone want to see something specific from the data? Make your requests in a form I can generate charts from, eg 'Comparison of payout for Slush intermittent miner compared to prop pool intermittent miner as a function of round length' or 'contour plot of intermittent payout/proportional payout as a function of change in miner hashrate  and round length'. etc. If like the latter example your request requires new data, be patient - this is a slow beast.

Thanks again Meni for your rapid analysis of the intermittent miner on a PPLNS-H pool - interesting as always, plus having someone else's (trusted) results makes working out if and where there might be errors in a simulation much easier.

Edit: I just realised that the variance over as few as a thousand rounds would probably mask the tiny reductions in payout as described by Meni.

Ok, I've got some results, though I haven't spent enough time on this to be sure they're correct. Doing this for slush's method is complicated, so I've done this for PPLNM (the temporal version of PPLNS). Wlog assume that the window is 1 time unit. We have a miner with hashrate H2 mining intermittently for a pool which, besides him, has a constant hashrate H1. Once in a while he starts mining for some time and then disconnects. We will denote H = H2/H1. His efficiency in the first time unit he joins is
 (H (2 + 3 H) - 2 (1 + H) Log[1 + H])/(2 H^2)
And his efficiency in the last time unit before he disconnects is
 1/2 + 1/H + Log[1/(1 + H)]/H^2
So his average efficiency in these two time units is
 (Log[1/(1 + H)] + (1 + H) (2 H - Log[1 + H]))/(2 H^2)
This is always less than 1 so he earns less than normal. It achieves a minimum of 94.8064% at H=3.47669. As H->Infinity the efficiency approaches 1. For H~0 the efficiency is (1-H/12). This is only for the 2 time units spent in the beginning and end of each connected session; the rest of the time the efficiency is 1.

slush's method is a little different but I'm no longer confident it could create a positive effect.

I'd like to remind everyone that this happens only in temporal pools. Hopping-proof methods like unit-PPLNS and DGM are immune to the effect. slush's method is temporal which is one of its two problems, but since it's so big you likely won't see the effect - if you're mining at 1GH/s you'll only have 0.008% (1 part in 12000) reduction in the worst case (with the reasonable assumption that the numbers for slush and PPLNM are similar).

Edit: Fixed a critical error.

nice to hear that, take your time though

@Meni Rosenfeld, awesome, some interesting results should come i'm sure

I wouldn't be surprised if it's a real result caused by self-hashrate-hopping. As you recall, in temporal pools it is an advantage to mine when the hashrate is higher. When you disconnect from the pool its hashrate is reduced, so conversely, you mine when the hashrate is higher.

I haven't quantified this effect, and AFAIK it could just as easily have the opposite effect by expediting decay of share submitted before disconnecting. I'll try to look into it.

I've completed the simulation, and it works well until I try to compare Slush to proportional - for some reason Slush comes out ahead in payouts by 0.7% consistently. Once I either find the source of the error or find out why it's not an error I'll post the results.

Ok, I get it now.

Maybe not so ok, then 

The first chart shows how the round payout for the hoppers as a group and the fulltime miners as a group changes before and after the hoopers leave, as a function of the hashrate increase due to hoppers adding hashrate to a pool. So it shows the portion of the round reward that leaves the pool with the pool hoppers (over and above what they would have been paid with a fair payout system), on average.

The second chart shows the (expected pool hopper payout)/(fair payout) compared with (expected fulltime miner payout)/(fair payout), again as a  function of the hashrate increase due to hoppers.
 

yeah it's true bout my nick haha, thanks for considering my proposal organof
adding missing data:

- slush score would be a good example and easy for all to understand, yes
- the problems will cut share submission and work requests completely.

The graph should contain reference score just like you simulated before and it's equivalent containing real world parameter, miner pool connection, that adds to pool variance as a whole. You take the reference point, can be 1-5 minutes every hour, 1 hour every day or 1 day every month, because it depends on the time frame you choose to sample.

Thanks again for providing this kind of resources to the community, i'm sure some donations will come your way soon and be able to do even more stuff.

To be honest I don't understand what the first two charts are saying.

Hey paraipan,

You handle's getting shorter, I see. I guess it must be more efficient that way?  No? Not even a chuckle? Sigh.

Anyway your proposal sounds like a good project. I'll need to know a bit more:

• Which type of score payout? I'm assuming Slush's?
• How much does the intermittent connection affect share submission? How long would there be no share submission as a proportion of round length, and what would the reduction in average hashrate be?

Yes, I didn't think simulate out potential losses if a hopping efficiency function isn't used, and hopperware creators and maintainers are only going to introduce significant changes if there's a good enough reason or enough people ask for them.

I think I'll have to write and run a simulation now that there are fewer proportional pools and the chance of hopping to a hoppable scored with a lower expected share value (and therefore reduced efficiency) is greater.

BTW, thanks for your help on hopper v fulltimer potential earnings question. I think the charts turned out ok.

lol organofcorti, pretty explanatory yeah, nice graphs man

Care to make a graph which compares standard prop with score type payouts and simulates intermittent disconnects from the pool ?

Can't seem to find a worthwhile explanation or graph around interwebs. If you have the ability so simulate score payouts over a 200 or more, rounds, normal and intermittent connection, to make a good average would be great.

Here's a little something to help you commemorate/celebrate the approaching end of the proportional payout system while I find time to finish my next blog post.

In first two charts you'll find everything you need to figure out how much you gained/lost while you hopped/mined. The second two are an illustration of PPLNS payout systems, the first with N=1 and the second with N=3.

The dependence on other pools is done only via difficulty retargeting, which happens once every two weeks. In between difficulty adjustments, each pool really is its own completely independent Poisson process.

You mean it doesn't now? How... uninspired.

One way to test if a list of empirical values were generated from a specific distribution is by comparing moments. If you take each round length and divide it by the difficulty at the time, you'll get values supposed to be distributed exponentially with mean 1. So the average nth power of the values should be n!. But you need quite a lot of observations to be accurate, more so for the higher moments - with 100 samples, even the second moment will be a bit off.

Thanks for your interest, catfish. I am absolutely certain that pool hopping works. I was even before I understood the probability behind it, by using mining simulations. How to hop 5 gives some examples of this sort, and How to hop 6 derives the expected value for a share. Having studied probability yourself I encourage you to read through these posts which I hope will help explain why the expected value of a share varies.

When I discuss pools in this reply I am only referring to pools with a standard proportional payout although some information is standard for all pools.

But bitcoin mining *is* like coin tossing, even in one pool. You make the statement that bitcoin mining probabilities do not follow a geometric distribution but I'd like to know why you think that. Maybe you're confusing shares with hashes? Each share  is a hash of difficulty 1, and so has a probability of 1/D of solving a block. A series of events each which have the same probability of ending a trial is a standard bernoulli trial.
A pool with a hashrate of ten times another pool will solve blocks ten times more quickly, on average, because it is accumulating shares ten times more quickly. The variance you mention is related to the time taken to solve a block, not to the number of shares taken to solve it. Over a large enough series of rounds, the share variance at a small pool is the same as at a large pool, only  it takes more time for the mean and variance to settle.
Why is frequent hopping helpful? No, just the time based variance[/quote], which is also affected by pool-hoppers moving, then simplified models become less accurate.

I've seen far too much of this in quantitative finance - a model that works very well with the nice little line 'assume that P (or whatever) is invariant' fails big-style when P turns out *not* to be invariant, but volatile as hell. Isn't that JUST as relevant here?

It seems to me that the entire pool-hopping 'strategy' relies on exploiting variance in small-to-medium sized pools. The largest pools must be getting towards the law of large numbers by now, surely?[/quote] To quote Starlightbreaker - "hop all the pools!". In fact because the time based variance of small pools is so large, they are not preferable. The larger the pool, the more constant the hopping profit. Even if this sort of variance was useful to a pool hopper, one round's variance is not reliant on previous rounds so that a maximum in average variance doesn't predict variance in the next round
Great questions, catfish! It took me a lot of reading to get up to speed. The best place to start is Analysis of bitcoin pooled mining reward systems. Another thing you could do is collect a hundred or so block lengths (deepbit publishes theirs) and do some calculations for yourself. At the minimum you could generate a histogram to show you that the block lengths are distributed according to a geometric probability distribution. If you can prove that to yourself, everything else should follow.

Hey Marty,

The hop point for coinotron is about 0.73*D, but you don't know if they're using c=6 or not and if you stayed until 0.73*D you'd lose efficiency. The other downside is that until around 0.38*D you wouldn't want to be there if you had a prop pool. Until hopper software can incorporate hopping efficiency function (discussed in How to hop 4, I'd just treat it like a proportional pool if you really want to hop it.

Your best bet though is to compare your shares submitted per round to your reward. You can work backward to find out if your reward is consistent with a normal proportional pool or not. If they aren't using C=6, then there's nothing to worry about at all. If they are, you can use a penalty of 0.6.

Good luck!

I'm afraid I've not had time to read everything you said carefully (I have to dash) but the assumption you gave here could be the cause.  I hope I've not missed the point.

The probability of any one hash (share if you like) generating a Bitcoin block is essentially fixed.  (It is changed once every 2016 blocks - approximately 2 weeks).  If you select a 10 day period shortly after a difficulty change then the various hopping strategies outlined here apply.  If you are careful you can probably profit even more when difficulty changes (and yes, some of the strategies given here may have to be tweaked to accomodate a change).  I haven't been keeping up with this thread so it's possible there are some posts on what to do at difficulty changes.

I'm giving "mine" w/penalty a try, have a suggestion on the optimal penalty?  Also, thanks for the cp...had my way with it! Ohh!