Topic: "How to hop" has moved - page 3. (Read 16256 times)

Come check out http://www.tntmining.com, we are a 0% proportional pool which means we are pool hop friendly. 

No. The distribution of round length is memoryless, so having a high share count does not make it any more likely that a block will be found. The result is that a properly implemented PPLNS pool is hopping-proof - the expected payout per share is always the same no matter when it is submitted.

Are PPLNS pools hoppable by selecting the backup pool with the highest pool share count?

That's it - tickles a vague memory from somewhere. Cheers for that.

Some hopper news: looks like I predicted the end of proportional pools too soon:

https://bitcointalksearch.org/topic/m.625380

From the Taylor series of ln(1+x) You know that for x~0 you have ln(1+x)=x+O(x^2). So for large D you have 1/D ~ 0 and so ln(1-1/D) ~ -1/D and ln(U)/ln(1-1/D) ~ ln(U)/(-1/D) = -D*ln(U).

If you don't know the Taylor series of ln you can simply use the fact that the derivative of ln at 1 is 1. Or you could use exp(x) ~ 1+x and take logs of both sides.

I just realised that hardly any of the blog readers so far have accessed the extra charts for the post or the scripts I linked to, so I encourage everyone who might want to try their hand at simulating pooled mining earning to check them out:

'How to hop 9' album on imgur.com
Poisson random number generator
Mining simulator pseudo-code
Mining simulator

Also, if you want to generate geomterically distributed random numbers you approximate it (and compound the inaccuracies, but oh well) back-asswards using a Poisson distributed RNG:


This is inaccurate (since the number generated ending the round could be > 1, and any inaccuracies in the Poisson RNG will be compounded), very inefficient and I guess not very interesting. But it is how I generated geometrically distributed random numbers for my first simulator and before I knew better! I'd better thank Meni for that, too.

Thanks Meni - I'd forgotten to include the '1+' so you just saved blog readers who might want to simulate very large numbers of rounds from NAN-ville 

Also, the simplified version was great. I know I've seen that approximation somewhere, but how do you derive the I should probably know this!

Round length follows a geometric distribution starting at 1. So to generate a sample accurately, you should use 1+round(ln(U)/(ln(1-1/D))) (assuming "round" rounds down). For an approximation that works well for large D you can simply use round(-D*ln(U)).

Want to try your hand at simulating pooled bitcoin mining? How to hop 9: Simulating miner earnings

I explain how to generate random variables and provide a step by step example of what to do with them. Feel free to ask any questions you might have.

Good.  The simple form of the theorem that is suggested by the two conditions I gave is easy to prove but it would be nice to say something more along the lines of "If X is a hop-proof pool then there must exist a function f and ...".  This shouldn't be tough (kind of fun really) but as I said a while back I've not done any of the maths for pooled mining and instead am enjoying just going with rough intuition (which frequently leads to my making false assertions but that's fine).  Good luck with this, not that you'll need it.


If you've been following my posts you'll know I'm a fan of "off-topic".


Congrats!  It's a shame you don't get higher status than "Hero Member".

Yeah, that's what I call "the hopping immunity theorem". I'll add a proof in AoBpmrs as soon as I determine the most general conditions under which I am able to prove it.

A bit off-topic isn't it?

I used to be an algorithm researcher in a small internet startup. I recently moved to a 20%-time position there so I can focus on Bitcoil.


This, by the way, is my 1000th post.

My apologies, I had to dash while I was composing this post and didn't have time to read it.  By "interpolate" I didn't mean to suggest any particular mathematical way of calculating payouts but rather just meant to suggest that by varying one of the parameters you would obtain a continuum of reward systems from PPLNS to Geom.  I admit this was a poor choice of word but couldn't think of anything better at the time.  Spectrum is a good word for this.

As for the "decay" part I was being particularly dense when I wrote this and I'm sorry for any confusion caused (I'll edit my earlier post if I can).  I somehow managed to get the idea in my head that it would be possible to have a non-hoppable reward system where for each block the full reward is paid out according to the shares submitted in that round.  I was talking about the "decay" in value such a share submitted to such a pool must experience before the end of the round (and thought it would exist and be some kind of exponential decay).  Of course, the only reward system that satisfies these two properties is PPLNS with N=1.  I was flatly wrong, "That's not really it" was just kindness .

After a quick read of your initial post about the Geometric method I see what you are saying about Prop and PPS.

May I ask what you do for a living Meni?

That's not what it does. It's on a spectrum that has exponential-PPLNS on one end and Geom on the other, but it doesn't just pay out a convex combination of the respective rewards.

That's not really it. You can use any decay function (and linear decay gives the best variance/maturity tradeoff). But you must maintain a steady state with some combination of round crossing and correctly tuned variable fee. Suppose you take the geometric method, in which the operator's score is specified as 1/(r-1). If you choose to make the score any less, you incentivize mining in young rounds; if you make it any higher, you incentivize mining in old rounds; only with this exact score the profitability is always the same.

There's nothing wrong with the decay in proportional. It's equivalent to exponential decay with r=1. If you do this with infinite score fee and correspondingly infinite negative fixed fee, you get PPS which is hopping-proof. The problem is that people try to use it with 0 score fee.

Yes.  The goal of many of the reward systems is to ensure that each submitted share has the same expected value.  PPLNS does this (unless carelessly implemented), PPS does this (this too can be implemented in a way that is technically hoppable thanks to the transaction fee reward), and Geom does this.  As far as I understand it, DGM simply interpolates between PPLNS and Geom is a spectrum of different non-hoppable reward systems ranging from PPLNS to Geom and, consequently, takes an additional parameter.  If a reward system has this property and pays all rewards out in a timely manner then it simply cannot be hopped (for the time issue, compare DGM to SMPPS).

The interesting aspect is that, for a fixed difficulty and hashrate, the number of blocks generated in a certain period is very well modelled by the Poisson distribution (equivalently, the time until the next block is found is very well modelled by the exponential distribution).  Consequently there is a natural "decay", not built into Bitcoin by design, but simply a mathematical phenomenon.  If you just design a reward system with shares decaying in value at some random rate you prescribe then most likely the pool will be hoppable.  The decay must exactly match that required by the mathematics.  This is why the proportional reward system is hoppable; the decay is not the same as that required by the mathematics.  Nonsense

PPLNS isn't the only hopping-proof method. As you can see in section "general unit-based framework" of AoBpmrs, a hopping-proof method can either cross rounds, include a variable fee, or both, and have either exponential, step, or any other decay. Exponential decay is far from poorly-informed - it is the only decay that allows encoding the score with a single value.

The problems with slush's method aren't that it's exponential - it's that it's temporal, and that it has neither round crossing nor variable fee.

PPLNS systems, as long as they cross rounds (which all do, there is no concept of pool rounds when distributing payments) are all fair payout methods that do not positively or negatively affect the part-time miner. Since the work you submit now determines your percentage of reward on future blocks until the work expires, you don't know when blocks will be found, and past block finding doesn't affect future payments, all contributed shares have equal expected value.

I think it may be possible to game 'decaying' value pools or get a different average reward than you deserve when part-time mining, which is non-ideal. Lets say you have three different accounts on one pool, and switch between accounts every hour. It would seem that under an exponentially decaying reward or other custom poorly-informed formula (don't know if any pools do this) your expected reward may be different than constantly mining one account. Just thinking that 'pulsing' your hashrate (intermittent mining), may get you more or less expected reward than constant mining, depending on the decay rate, when we want every submitted share to have the same expected return.

Upon reflection, it seems like the second paragraph's concern is also unfounded. As long as each share's value is independently evaluated, it shouldn't make a difference. If a pool has some other policy, like "if you leave for three hours your reward is cut in half", this would "connect" the value of shares you submit now to future shares you submit.

Well, thanks for that, paraipan! Your donation is much appreciated.

What I got from the simulation was (if you're a fulltime 1Ghps miner with 5% downtime) not to allow a few worse payouts than expected change your mind about mining at Slush's pool since this is offset by more regular and less noticeable better than proportional payments. The hoppable score system is something that should make you change your mind though.

Since you were kind enough to donate I rewrote the the simulation to allow for a changing hashrate and changing downtimes. I'll post a contour plot and a 3D perspective graph of the results when it's done. It will take a few days, I expect.

While I'm working on this simulator, any other requests? Keep in mind this simulator only includes variables which are important for the payout system. It doesn't include frequency of getwork requests, mining software variables, etc - just frequency of share submission, frequency of downtime, and the payout.

awesome work organof, just managed to pull a few great conclusions based on your data, hope others will too. I'm pretty sure i will be making better mining decisions from now on.
Sent you a tip, not much but expect more in the future because i will be closely watching your work.

So, here are the first few results. Look first, description after.












Before I start, the mean payout for the intermittent  Slush miner was 0.0074% more than for the intermittent prop pool miner, and the mean payout for the non-intermittent Slush miner was actually 0.01164% less than for the non-intermittent prop miner. I think we can ignore these values given the variance involved.

The first two charts show the amount earned by an intermittent miner at a proportional pool (green) and the exact same share submissions at a Slush scored pool. The first chart shows results for one hundred rounds, the second chart are results for twelve hundred rounds. You can see clearly that the results in both cases are centred near the expected 0.0475 btc. However the scored payout shows a lot more variance.

The third chart shows the proportional payout minus the Slush payout for non intermittent miners. It has a fair amount of variance but doesn't seem skewed to either above or below expected, meaning that median and mean are similar, and we don't have a large amount of small increases one way and a few very large ones the other way to 'balance' it.

The fourth chart shows the proportional payout minus the Slush payout for non intermittent miners. There is skew in the data, with lots of small negative differences (where the Slush scored pool pays better than proportional) and a few very large positive differences (where the slush scored pool pays significantly worse). I think the density plot below that illustrates this point well.

Statistics:

Non-intermittent, Prop payout per round minus Slush payout per round
median: -0.0000470
mean:    0.0000058
sd:         0.0036246

Intermittent, Prop payout per round minus Slush payout per round
median: -0.0006029
mean:    -0.0000035
sd:         0.0061706

Summary:

In the long run and with the parameters previously mentioned, being an intermittent miner on a Slush scored pool is not significantly different from being an intermittent miner on a proportional pool. In the short term, a comparison between the non-intermittent and intermittent groups shows significantly increased variance for the prop minus Slush intermittent group as compared to the non-intermittent group, with some slight skew - which may not be significant given the variance in the data.

Edit: Fixed an error in mean intermittent prop minus Slush payout. Value should be -0.0000035 not 0.0000035.

Thanks, much appreciated!

My curse is that I know what's important and what's not. What we've done here is a nice exercise but it's not important, because A) the effect is tiny and B) This only happens in temporal methods like slush's pool. I don't like it when slush's pool is subject to false criticism but I never recommended using his method, it has several problems and it's known that this is one of them. This simply cannot happen in hopping-proof methods where the average reward really is equal to the total worth of work submitted regardless of pattern. (Though I'm not talking about things like stale shares, invalid blocks, pool downtime etc. which have nothing to do with the reward system.) The geometric method is what slush's method would have looked like if it was done properly.