"How to hop" has moved

[organofcorti]

Or you could use exp(x) ~ 1+x and take logs of both sides.

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://bitcointalk.org/index.php?topic=52403.msg625380#msg625380

[1713998911]

1713998911

[1713998911]

1713998911

[martychubbs]

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

[Meni Rosenfeld]

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

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.

[mu50stang]

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

[martychubbs]

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

well, not so fast...he switched to PPLNS...

[Meni Rosenfeld]

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

well, not so fast...he switched to PPLNS...

This is just inane. First he spams his pool everywhere saying he deliberately wants to be hopped. Then he switches to PPLNS?

[martychubbs]

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

well, not so fast...he switched to PPLNS...

This is just inane. First he spams his pool everywhere saying he deliberately wants to be hopped. Then he switches to PPLNS?

I was contributing 20% of their overall hash rate and it happened...  It was, in fact, very lame.

[organofcorti]

Bait and switch, mid round. Can't think of any other way to interpret it.

[martychubbs]

Has BTCmine or Slush changed their scoring?  Results have been down lately on BTCmine, or is it just me?

[organofcorti]

Has BTCmine or Slush changed their scoring?  Results have been down lately on BTCmine, or is it just me?

If they have, I'm not aware of it. Keep in mind though, if they haven't changed their 'c' value, at low hashrates your payouts will vary significantly, apart from the usual pool based variance.

[Clipse]

Im a bit late to the party but I just picked up on this thread and figured to respond.

This "suppose calculation" makes absolutely no sense. This assumes there is 1mh non-hopper for every 1mh hopper which is absurd to think that its so linear and even if there were 1 to 1 correlation and you expect hoppers to average out at 175% efficiency and non-hoppers to drop down to 75%, please tell me how you figured in your maths where the other magical 50% gain of the hopper would come from ?

Simply put, the gains expressed here does not add up and in the real hopping world does not at all materialise.

[deepceleron]

Im a bit late to the party but I just picked up on this thread and figured to respond.

This "suppose calculation" makes absolutely no sense. This assumes there is 1mh non-hopper for every 1mh hopper which is absurd to think that its so linear and even if there were 1 to 1 correlation and you expect hoppers to average out at 175% efficiency and non-hoppers to drop down to 75%, please tell me how you figured in your maths where the other magical 50% gain of the hopper would come from ?

Simply put, the gains expressed here does not add up and in the real hopping world does not at all materialise.

Raolo paper: http://bitcoin.atspace.com/poolcheating.pdf

The pool hopper, by simply hopping one pool (hopping off to PPS mining after 43% of difficulty shares) will earn 28% more. Note that this means the hopper spends more of his time PPS mining than mining on the proportional pool - the pool hopper earns his expected reward while backup mining, but earns significantly more than +28% per share while exploiting the pool, for a total earnings 28% higher. Leaving the pool even earlier (if you have many pools to hop) means the per-share reward of the miner in the exploited pool is even higher.

As a proof-of-concept, I submitted just a few shares to a pool at the very start of each round, quitting after 5% of difficulty. My shares on average were worth 4x more than expected.

The more hoppers there are, the less full-time miners will be able to submit shares into the profitable early window where a lucky block might be found. Enough hoppers on the pool, and full-time mining approaches the opposite of pool hopping, hardly submitting any shares before 43%, only able to submit after 43% of difficulty until the round ends.

If you need anecdotal evidence of full-time miner losses at a 2 hoppers per 1 fulltime miner proportional pool: https://bitcointalk.org/index.php?topic=10121.msg656033#msg656033 - and that is even with a minor anti-hop measure, delayed stats.

[organofcorti]

Hi Clipse, glad to have your input.

This "suppose calculation" makes absolutely no sense.

There is no 'suppose' at all - just a simple simulation repeated many times resulting in expected (or average) earnings. Actually, I did use a few supposes: 'suppose there's no lag', 'suppose your hopperware gets you there at the very start of a round, not after the round start has been announced', 'suppose you don't get stales', suppose your internet doesn't ever go down' etc. I left these out of the simulation on purpose.

This assumes there is 1mh non-hopper for every 1mh hopper

No, it doesn't. If you look at the x axis, you'll see clearly labelled "1x  2x  3x' etc. This is the total pool hashrate increase due to pool hoppers. So the x axis starts at 'no hopper increase' and goes up from there. I've seen pools go from 50Ghps to 250Ghps and back due to pool hoppers, so '5x' is not unreasonable. I included '20x' to show what would happen to a 10Ghps pool that was hopped by the same amount since I was asked that very question.

you expect hoppers to average out at 175% efficiency and non-hoppers to drop down to 75%,

What magical gain? Using 'bitHopper' I have had efficiencies of 150 to 250% per pool per round, averaging to around 160% long term for most pools (except deepbit which averaged to about 140%). I haven't hopped for a while but I can't see why it would be lower now.

please tell me how you figured in your maths where the other magical 50% gain of the hopper would come from ? Simply put, the gains expressed here does not add up and in the real hopping world does not at all materialise.

I'm not following. My own experiences show an average efficiency per pool per round approaching what's shown in the graph. What magical 50% are you talking about? Poolhoppers will *always* approach ~175% or thereabouts in terms of efficiency: (what they earned per prop pool per round) /(what no fee PPS would earn them per round). What full time miners will earn depends on how many hoppers there are.

The graph above the one you quote give results in terms of BTC:

Now if I haven't convinced you and you can read R code, I'll post the simulation - I'd be happy for you to do some code error checking.

[organofcorti]

And good to cross swords with you once more, deepceleron!

Raolo paper: http://bitcoin.atspace.com/poolcheating.pdf

Meni Rosenfeld's "Analysis of Bitcoin Pooled Mining Reward Systems" is more general has more detail and information. It should be considered a starting point when considering any payment system.

The pool hopper, by simply hopping one pool (hopping off to PPS mining after 43% of difficulty shares) will earn 28% more. Note that this means the hopper spends more of his time PPS mining than mining on the proportional pool - the pool hopper earns his expected reward while backup mining, but earns significantly more than +28% per share while exploiting the pool, for a total earnings 28% higher. Leaving the pool even earlier (if you have many pools to hop) means the per-share reward of the miner in the exploited pool is even higher.

In the charts I'm only considering results per prop pool per round and not including PPS fallback.

The more hoppers there are, the less full-time miners will be able to submit shares into the profitable early window where a lucky block might be found. Enough hoppers on the pool, and full-time mining approaches the opposite of pool hopping, hardly submitting any shares before 43%, only able to submit after 43% of difficulty until the round ends.

Nicely said.

[organofcorti]

The following is a response to simc, a full time miner at slush's pool:

https://bitcointalk.org/index.php?topic=1976.msg728345#msg728345

It started to get long (especially with chartage) so I decided to put it here instead. Look a few posts up from the one I linked to if you want context.

Thank you for the data, simc. As for the number of shares from the score, integrate the score formula and make shares the subject. Wolframalpha can help if you're not sure how to.

The first chart shows a clear peak in pool hashrate for rounds about 274000 shares total, after which there is a gradual decline in average hashrate. The trend is fairly clear even with this very limited dataset. This is interesting since that's about the current hop point, which can be calculated as follows:

Code:

Hop point =0.0164293+1.14254/(1.8747*D/(hashrate*c)+2.71828)

and making D=1300000, hashrate=1600 and c=300, we get an estimated hop point of 0.16*D which rises to 0.18*D at 1900Ghps. This is close to the 0.21*D that 274000 represents, so this gradual increase is probably due to hoppers - many will miss the start, and other proportional pools may be available instead, but the decline afterward and the ramp before are, to me at least, very likely accurate or at least close. The ramp and decline are also gradual because we are dealing with the average hashrate for the round, not the hashrate at the time.

The other two graphs show your earnings per round against pool hashrate and total round shares. There do seem to be some trends there, however.



ANOVA of the linear model:

Code:

lm(formula = BTC.reward ~ log(totalRoundShares))

with coefficients:

Code:

        (Intercept)  log(totalRoundShares)  
              -0.0022730            0.0008777

gives p<0.0001, so it seems possible that (for your data set) the your reward will increase with increasing round length:

Code:

simc's round reward = 0.0008777*log(totalRoundShares) -0.0022730

Similar analysis of

Code:

lm(formula = BTC.reward ~ hashrate)

and

Code:

lm(formula = BTC.reward ~ log(hashrate))

resulted in p>0.05 so with this limited dataset I'm not willing to accept either of these relationships as probable.

In summary, simc's data shows:
1. A probable hopper effect of about 36% increase in round average hashrate by about 0.21*D
2. A probable positive relationship between reward and round length, meaning that for the rounds under 3 600 000 shares on this particular day, total shorter rounds tend to reward less.
3. No relationship of significance between simc's reward and total pool hashrate. This is a bit odd since an increase in pool hashrate implies shorter rounds and less reward per round. Since slush uses a score method for payment and it's late here, I'm not going to work out the p value for that relationship with this data.

Keep in mind all this is based on minimal data, and I estimate I'd need a few weeks worth of a single miners data to have results worth making decisions on.

[cunicula]

Nice stuff. I like the quality of these posts a lot.

[Meni Rosenfeld]

The first chart shows a clear peak in pool hashrate for rounds about 274000 shares total, after which there is a gradual decline in average hashrate. The trend is fairly clear even with this very limited dataset. This is interesting since that's about the current hop point, which can be calculated as follows:

This peak makes no sense. Either hoppers are behaving in a very weird way, or the apparent climb to ~270000 shares is the result of sampling error.

[organofcorti]

The first chart shows a clear peak in pool hashrate for rounds about 274000 shares total, after which there is a gradual decline in average hashrate. The trend is fairly clear even with this very limited dataset. This is interesting since that's about the current hop point, which can be calculated as follows:

This peak makes no sense. Either hoppers are behaving in a very weird way, or the apparent climb to ~270000 shares is the result of sampling error.

There's going to be some lag for hoppers to join due to the nature of the hopper software but (going from distant memory) it usually wasn't more than about 5000 shares missed at a similar pool hashrate.

But I agree, the peak is probably an effect of having a tiny sample from a pool that has a score system that increases variance. As well, if hoppers miss the start of a few short rounds (because a prop pool has a more rewarding total round shares) in this dataset, then you'd see this sort of peak. I would think with a bit more data the hashrate would be less a peak and more a plateau.

What was interesting to me though was that the pool hashrate started to drop at the total round shares you would expected it to if the increase was due to hoppers.

[organofcorti]

So Goat finally confessed to running a pool hopping pool, like the "multipool" of old, or the bitHopper proxy. I'm interested to see the lack of blowback from prop pool miners

This sort of pool might explain explain the recent increase in pool hopping. For example look at the hashrate and worker spikes in the weekly hashrate of this popular proportional pool:




The first thing to note is that I'm assuming the hop increase coincides with the start of a round. The round starts reported by the pool look to be about when the spikes are on the graph, but I can't be sure they tally exactly. The have in the past, so I'm assuming the hashrate spikes are at the start of a round.

Next, notice that total pool hashrate increases by 2x to 7x (the greater increase yesterday). Use these charts to work out how much the full time miners are losing from this pool alone.

It's a bit disconcerting to realise that even big pools can be affected in this way. In the heyday of individual pool hopping, the expected hop boost was in the order of 200-300Ghps. From the (very small) dataset this pool provides it's around 500Ghps, and earlier today hit 1500Ghps. The 500 Ghps tallies well with slush's data (provided by simc).

This hashrate graph from July 2011 shows about 150Ghps hopper hashrate increase:



Finally, these sort of charts used to show a large increase in workers with the hashrate increase. Now, you'll notice a minimal worker increase. That means that either all hoppers have a much higher hashrate than full timeminers, or a number of pools are using pool hopping to augment their mining.

Take away message: being on a mid size proportional pool is not even semi-protection against poolhopping - not when hoppers are submitting a Thps or so. With's Goat's expose I expect more hopping pools to be created. It's really time to leave prop pools now.

[organofcorti]

Bitclockers.com are faking round lengths, and many miners - those who stay for only the early part of a round, for example - are being underpaid. Check out more detail here. More details about how and why they're faking their round length data in upcoming posts.

             

I expect a shitfight over this so comments are welcome, especially from backburn.