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

c) underclocking hoppers and miners' earnings from time to time

It's a geometric to loglogistic transform:
round length -> geometric cdf -> loglogistic quantile function -> loglogistic 'round length'
More details will be posted on hoppersden as I finish the charts.

Their system is like a score system, but on the round length itself. It would be quite clever, except they didn't tell anyone, and there have been far better options for months - There were far better options at the time.
It took a while for me to figure out what was going on, and I knew there was a problem as early as September or October last year. I was waiting for more round to increase the data set and then got side  tracked.


Because (assuming they have no ethical qualms about doing it) they get the best of both worlds - on one hand hoppers get lower profits, fulltime miners lose less to hoppers, and on the other people who 'love proportional pools' can mine there thinking they're getting the full proportional experience, and the hopper boost stays to help finish rounds.

Bitclockers.com are:
a) faking round lengths
b) faking round starts and not owning up to blocks

Which leads me to think they must be happy there are no bitcoin police or there would be a lot of angry miners they'd have to pay extra to.

Quite possibly a rabid one.

In other words, they have a reward system which is some sort of interpolation between proportional and PPS (perhaps with weighting affected by their estimate of hopping level in each round), but instead of being open about it, they fake stats.

I find it troubling that such egregious falsification has gone unnoticed for so long. If they had added 2% fake shares to every round to collect a hidden fee, would it be spotted quickly? Perhaps the "stats hunters" pay more attention to the distribution's expectation than its variance?

And finally, WHY? Their system either greatly increases their own risk, or required some nontrivial control mechanism. Why can't they use a hopping-proof method that just works, probably has similar long-term characteristics, and allows them to be honest about what they are doing? Were they bitten by a hopping-proof method as a child?

Yes, I thought you might find it useful.

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.

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.

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.

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.

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

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

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

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:


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:
with coefficients:
gives p<0.0001, so it seems possible that (for your data set) the your reward will increase with increasing round length:

Similar analysis of
and
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.

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


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.
In the charts I'm only considering results per prop pool per round and not including PPS fallback.
Nicely said.

Hi Clipse, glad to have your input.
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.


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.

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://bitcointalksearch.org/topic/m.656033 - and that is even with a minor anti-hop measure, delayed stats.

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.

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.

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

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

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

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

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