Deepbit hopping

[P4man]

Recently there have been various 105-115+% PPS schemes propping up.
The most sensible explanation I could see was pool hopping large proportional pools like deepbit.

Deepbit delays its stats by an hour, but I didnt think that would be enough to prevent pool hopping, since deepbit is so large, you might assume every new block that is found, is found by deepbit, and you'd be right 1 times out of 3. Good enough to extract a profit from the non hopping proportional miners.

So, I decided to have a look at deepbit stats, to see if I could find evidence of this theory. I collected the stats for last 5 days and plotted the estimated hashrate against block duration. And sure enough, there is a nice correlation:

edit: this graph is incorrect, see below.


X axis shows minutes it took to find the block, Y axis is estimated hashrate (shares / minutes).
Average is 24.7 minutes.

I discarted sub 2 minute blocks, but even so data for the shortest blocks are not to be trusted, since deepbit only gives a granularity of 1 minute. Moreover, I do not know how the lenght is rounded, so if 1m59s becomes 1 or 2 minutes. This could also skew the graph, but I dont think enough explain the correlation.


edit:
Deepbit rounds 1m59 seconds to 1 minute in the stats, so on average I would have to add 30 seconds to each block. Then we get this graph



X axis shows the minutes it took deepbit to mine the block (average is ~25).
Y axis show estimated speed (shares / time).

Correlation is much less strong, but its still there. Looks like almost 10% hoppers.

Tycho, can you shed some light on this? Or if you can, provide data thats more accurate than 1 minute?

[1714908059]

1714908059

[1714908059]

1714908059

[1714908059]

1714908059

[1714908059]

1714908059

[1714908059]

1714908059

[DeepBit]

I don't think that those 115% schemes gain their profit from hopping deepbit because it would be really obvious for me.
I noticed a couple of times when some user bought a "contract" from GPUMAX and tried to use it for hopping deepbit, but I prevented it.

As for your graph, yes, there is some correlation on it, but I think it's a bit off because randomness should also cause the speed to be lower sometimes for the lucky blocks. Also you should show full range from 0 speed for axis Y :)
EDIT: new graph is better.
Usually they are hopping with some delays, so shortest blocks are not affected after long enough ones.
I know that there are some hoppers and I know that stats delaying is not safe enough to prevent it, but their effect on innocent miners is not so noticeable because they just don't have enough hashing power for this.
I'm working on automatic countermeasures and I have ready detection routines that are undergoing testing at this moment.
Some users already noticed that: https://bitcointalk.org/index.php?topic=3889.msg718043#msg718043
I'm collecting results to ensure that no false positives will ever happen, then automatic punishing can be enabled to protect my users.

Additionally, hop-proof payment method may be implemented later.

[P4man]

I don't think that those 115% schemes gain their profit from hopping deepbit because it would be really obvious for me.
I noticed a couple of times when some user bought a "contract" from GPUMAX and tried to use it for hopping deepbit, but I prevented it.

If no one is hopping deepbit, the above graph would look different.

As for your graph, yes, there is some correlation, but you should show full range from 0 speed for axis Y

Why? Zero would mean a block thats never been found.
Someone better in statistics than me can do the proper math, but it looks to me like ~10% of your hashrate is successful hopping.

Also can you please tell me how the duration in the stats is rounded?

[DeepBit]

I don't think that those 115% schemes gain their profit from hopping deepbit because it would be really obvious for me.
I noticed a couple of times when some user bought a "contract" from GPUMAX and tried to use it for hopping deepbit, but I prevented it.

If no one is hopping deepbit, the above graph would look different.

As I said, there are hoppers and I'm working on this.

As for your graph, yes, there is some correlation, but you should show full range from 0 speed for axis Y

Why? Zero would mean a block thats never been found.

I was talking about the axis range.

Also can you please tell me how the duration in the stats is rounded?

Why don't you just use the first column with timestamps ? It's 1-second accuracy there.

[P4man]

Why don't you just use the first column with timestamps ? It's 1-second accuracy there.

Because Im an idiot
Regardless, from that column its clear you indeed round down, so 59s becomes zero minutes. That means the second chart is correct. Still enough of a correlation to prove your pool is being hopped in a significant manner.

[DeepBit]

Regardless, from that column its clear you indeed round down, so 59s becomes zero minutes. That means the second chart is correct.

Can you post a graph with those data points averaged for each minute ? I mean, with a line instead of dots.
For example, with a Y-range from 0 to 70 000.

[P4man]

Not sure what you mean, but I justed added a 40 point average (and cropped the extremes):

removed incorrect graph.

edit: I see what you mean now. Im no ace at charting in OO, Ill try, but the the above gives a good idea already
Increasing the Y range just adds blank space though

[DeepBit]

Not sure what you mean, but I justed add a 40 point average (and cropped the extremes)

Your Y-axis scale is from 40 000 to 85 000. I asked for 0 to 70 000, to take a look at global scale.

EDIT: BTW, why so many red dots at the zero-time point ?

[P4man]

Like I said, it just adds blank space. Zero means zero hashrate.  It would make more sense to chart the deviations from the average hashrate, then the x axis is at 51K, but the chart will look identical.

[P4man]

EDIT: BTW, why so many red dots at the zero-time point ?

Because Im not adding them together. Each dot is an average for the next/previous 40 datapoints, and there are many of those with sub 1 and sub 2 minutes. The difference in #shares gives different datapoints, even for the same duration (x axis).It looks weird, but its correct. It would look better if I grouped the data per x minute interval, and showed only 1 point with an average hashrate for that interval, but Ill have to do that later.

[Remember remember the 5th of November]

Considering blockchain.info tells me WHICH pool found a block, it is fairly easily(with a 2 minute gap) to find out if deepbit mined a block. Sure it requires additional info, but it could be worth it!

[P4man]

Couldnt find a way to do it with a formula so I manually grouped shorter durations and averaged them. I didnt do that for all durations, so you get some weirdness, but it looks better now:

edit: made a mistake with decimal 30s.. This is one is correct:



Interesting dip on the left side. I originally had a mistake in the spreadsheet adding only 0.4 decimal minutes average to the block length, rather than 0.5 to compensate for the incorrect rounding. Makes a big difference for blocks which take <1 minute obviously. The dip actually makes complete sense, it takes a while for hoppers to notice the new block on the chain and switch to your pool. I think the difference between 0-1 minutes and 0-2 is clearly how many (quick) hoppers you have.

There is no question you are being hopped. Its not massive, but its there.

[DeathAndTaxes]

Linear regression would smooth the trend line out.

If you post the raw data (x,y) in a code block for the scatter plot I will draw one.

My guess about the dip on the left is due to the delayed stats hoppers are using some mechanism to try and confirm blocks before hopping in.   For example if you monitored the top 5 non Deepbit sites and they didn't report a block even delayed or obfuscated the chance it was deepbit increases.  On an unknown block there is a roughly 35% chance it is Deepbit's.  If the top 10 pools don't report it (and you wait 30 seconds or so for blockchain propogation) then the chance it is deepbt's increases to about 70%.  Roughly 50% of the time someone will report a block which guarantees that it isn't Deepbit. That means you are hopping with ~ 85% confidence.

[PatrickHarnett]

Missing the definitions of the different axes, I assume Y = average hash speed and X = block duration.

The point about graphing the Y axis from zero would better show how much (or little) decline there is.  For instance, is deepbit losing 5% or more from hoppers, or less.  It is hard to tell given the way it is presented.

Interesting piece of analysis.

[P4man]

Missing the definitions of the different axes, I assume Y = average hash speed and X = block duration.

Yeah, its in the text.

The point about graphing the Y axis from zero would better show how much (or little) decline there is.  For instance, is deepbit losing 5% or more from hoppers, or less.  It is hard to tell given the way it is presented.

Speed never drops to zero. As i said over and over, its just blank space at the bottom. Or top, why not add a lot at the top?
The chart is fairly clear I think, from the sampled data there seems to be about 10% hopping.

Anyway for those who want to play with the data and make their own charts (incl from zero), here is the spreadsheet
http://www.mediafire.com/?ebamgh0fmkrrl45

Its in ODS format (open office). Charts are on the second sheet.

[PatrickHarnett]

ok, if you take the max at 55,000 and a decline to 50,000, then you get 10%.  I wonder if the noise in the chart over-states it.  Might only be from 53k to 51k.  Either way, it's useful to have a snapshot of data.

[P4man]

ok, if you take the max at 55,000 and a decline to 50,000, then you get 10%.  I wonder if the noise in the chart over-states it.  Might only be from 53k to 51k.  Either way, it's useful to have a snapshot of data.

The data covers just over 100 blocks that where shorter than 10 minutes. Im sure someone will soon calculate 95% probabilities, but I dont think noise is likely to explain it. It could be over- or understating it though, thats for sure.

My main point is they are being hopped, Im fairly confident the data proves that. Even if its just 5%, I wonder if that couldnt match the hashrate of those 115% PPS fake pools. Add to that they all seem to suffer from high stales, and Im getting quite certain thats whats going on. They are probably not just hopping deepbit, but deepbit are obviously the biggest one, and perhaps  the easiest to show it for.

[PatrickHarnett]

ok, if you take the max at 55,000 and a decline to 50,000, then you get 10%.  I wonder if the noise in the chart over-states it.  Might only be from 53k to 51k.  Either way, it's useful to have a snapshot of data.

The data covers just over 100 blocks that where shorter than 10 minutes. Im sure someone will soon calculate 95% probabilities, but I dont think noise is likely to explain it. It could be over- or understating it though, thats for sure.

My main point is they are being hopped, Im fairly confident the data proves that. Even if its just 5%, I wonder if that couldnt match the hashrate of those 115% PPS fake pools. Add to that they all seem to suffer from high stales, and Im getting quite certain thats whats going on. They are probably not just hopping deepbit, but deepbit are obviously the biggest one, and perhaps  the easiest to show it for.

Now that's an interesting observation/comment.  Months go when I was arguing with Meni about hopping I was putting forward proposition that smaller pools might be more vulnerable, and larger pools would be more stable.  Therefore I would expect the smaller pools to show more pronounced changes and trends.

[DeepBit]

I wonder if that couldnt match the hashrate of those 115% PPS fake pools. Add to that they all seem to suffer from high stales, and Im getting quite certain thats whats going on. They are probably not just hopping deepbit, but deepbit are obviously the biggest one, and perhaps  the easiest to show it for.

I don't think that it's related to 115% pools because I'm monitoring all the hoppers (in the process of developing automatic detection) and there were no any changes in their volume when those projects appeared. Also, I did some tests and they didn't reported any problems during this time.

[P4man]

I don't think that it's related to 115% pools because I'm monitoring all the hoppers (in the process of developing automatic detection) and there were no any changes in their volume when those projects appeared.

Well, maybe I misunderstood you, but if some miners moved from deepbit PPS to these 115% proxy pools that are hopping deepbit and others, you wouldnt expect to see a big difference in hashrate. Youd might lose some hashrate on the longer blocks, potentially win some at the beginning of blocks or on short blocks from miners that didnt mine at deepbit before. Not very conclusive IMO.

If you are saying these proxy pools registered at deepbit and you are monitoring their behavior.. then that begs the question why on earth they would pay 115% to redirect the hashrate to a pool that pays out 97%, if its not for hopping?