0. Introduction
In the last three 'How to hop" posts (How to hop 10 , How to hop 11, and How to hop 12, I proved that Bitclockers.com are not providing real statistics to their miners and gave some insight as to how this could be done. Since starting this project I've received some feedback which has made me decide not to continue with the posts I had originally planned.
It was brought to my attention that although I found some data correlations, I could not prove that Bitclockers.com were actually transforming round lengths in a particular fashion. There is no doubt that their round lengths do not belong to a geometric distribution, but are they actually transforming the real round lengths to that of another distribution? We can't tell. If they are not observing block boundaries, for example, they could simply be making up random numbers from a particular distribution and publishing those.
For readers who would like to look into this further, I've found some more distributions that correlate well with the empirical cdf (using the Kolmogorov-Smirnov test) to a p-value > 0.05. Below is a list of all I found to date, with parameters optimised by fitdistr. If this doesn't interest you, scroll down to 1. Bitclockers.com makes everybody cry, not just pool hoppers.
Lognormal distribution (yes, there are parameters that work for a lognormal distribution - originally, I didn't find any)
> fitdistr(bitclData,'log-Normal') meanlog sdlog -0.0627 0.4085 ( 0.0242) ( 0.0171)
> ks.test(bitclData,'plnorm',-0.0627,0.4085)
One-sample Kolmogorov-Smirnov test
data: bitclDataD = 0.0303, p-value = 0.955alternative hypothesis: two-sided
Loglogistic distribution:
> fitdistr(bitclData, dllogis, list(shape = 1, rate = 0.1), lower = 0.001)
shape rate
4.3110 1.0653
(0.2114) (0.0255)
> ks.test(bitclData,pllogis, 4.3110 ,scale=1/1.0653)
One-sample Kolmogorov-Smirnov test
data: aa
D = 0.0389, p-value = 0.7785
alternative hypothesis: two-sided
Gamma distribution:
> fitdistr(bitclData, dgamma, list(shape = 1, rate = 0.1), lower = 0.001)
shape rate
6.080 5.949
(0.495) (0.505)
> ks.test(bitclData,pgamma,6.080,5.949 )
One-sample Kolmogorov-Smirnov test
data: aa
D = 0.04, p-value = 0.7507
alternative hypothesis: two-sided
Weibull distribution:
> fitdistr(bitclData, dweibull, list(shape = 1, scale = 0.1), lower = 0.001)
shape scale
2.3804 1.1539
(0.0982) (0.0304)
> ks.test(bitclData,pweibull,2.3804,scale=1.1539 )
One-sample Kolmogorov-Smirnov test
data: aa
D = 0.0758, p-value = 0.07495
alternative hypothesis: two-sided
1. Bitclockers.com makes everybody cry, not just pool hoppers.
A second concern that made me decide not to continue posting my results on the 'How to hop' blog was that some people thought that the posts were for strategic miners only. So this post is devoted to explaining why no miners - fulltime or strategic - should mine at Bitclockers.com. Rather than further investigate exactly how Bitclockers are transforming round lengths, I'm going to look at only the empirical data and what it tells us about how they are treating all their miners.
The effect of their fake round lengths on miners earnings can be considered two ways:
- When block boundaries are observed, and solved blocks reported correctly, and
- When block boundaries are ignored and block solve times are false.
2. "All these boundaries .... are set by Bitclockers.com. But you don't have to look at boundaries when you are looking at .... the character of Bitclockers.com.
(Apologies to Hakeem Olajuwon )
When block boundaries are observed we can prove that Bitclockers.com are underpaying all their miners by 21%, just using the available empirical data.
The requirement that block solve times are reported accurately means there must be a transform function of some sort being used or Bitclockers.com would
- Increase variance for themselves and hence pool operator risk, and
- Make that hashrate per round impossible to fake.
Firstly, we need to generate the geometrically distributed data. We can do this by using the empirical cumulative distribution function:
ecdf = n/max(n) where 'n' is the nth datapoint in a set of data ordered by sizeand then using the quantile function for a geometric distribution.
The data I'm using is Bitclockers rounds 180 to round 505 (How to hop 10 explains why)
The bitclockers.com roundlength/D and quantile transform are here if you want to try this for yourself.
Data comparison:
The ecdf for the quantile generated rounds are very different from the ecdf of the Bitclockers .com rounds:
Now we can compare the expected share values for a fulltime miner for the geometric and Bitclockers.com round lengths. If the amount of shares a miner contributes to any round is S, the total round length is R, the bitcoin reward is B and current difficulty is D, then:
miner reward = S/R*B/DHowever, if R is varied, the reward will be changed - more shares mean a smaller reward for a miner, fewer shares means a smaller reward. If we compare round lengths of the geometric and and Bitclockers.com rounds by equating the ecdfs, then the mean percentage change in reward is:
mean % change in reward = mean((S/R2*B/D)/(S/R1*B/D))*100 = mean(R1/R2)*100So average ratio of bitclocker.com share value to geometrically distributed share ration is:
where R1 = total number of shares in a geometrically distributed round
R2 = total number of shares in a Bitclockers.com reported round.
mean(R1/R2)*100 = 79%This means that if Bitclockers.com are reporting block solve times accurately, they are underpaying their miners by about 21%. Since they have claimed they actually are reporting round lengths correctly, the only conclusion we can draw is that fulltime miners at Bitclockers.com are receiving only 79% of what they should be paid.
3. Who the hell knows what's going on anyway?
What other issues can arise if you can't trust a pools' published statistics? Any you can imagine, really. I'm not including pools that delay statistics here - although it has been shown that delaying real time stats provides no real benefits in reducing the expected profits of strategic miners, pools can reasonably delay stats as long as they are accurate.
If you don't know anything about the actual rounds you have submitted shares to, you cannot know if you are being adequately compensated (unless you're being paid PPS and you keep track of your own submitted shares).
The only way you can tell if you are getting close to what you should be paid is to keep track of all shares you submit, the difficulty they were submitted at, and your remuneration, and only over many rounds - by which point you may already have been underpaid for that many rounds.
So here's my first rule in choosing a mining pool:
organofcorti's first rule of Bitcoin mining : Do not mine at a pool that publishes false statistics.
A corollary of this is:
Do not mine at Bitclockers.com until they disclose their actual records.
I hope to continue the Neighbourhood Pool Watch series. If you think a pool you use is up to some funny business, let me know at the Neighbourhood Pool Watch bitcointalk.org thread, or comment here.
Thanks to the following bitcointalk.org forum members: MobiusL for proof-reading this and giving me some great ideas, Meni Rosenfeld for corrections and suggestions, deepceleron for recommendations on content presentation, and to hoppersden.info admin 'myself' for not minding me posting something that isn't about pool hopping.
Donations help give me the time to investigate pools and write these posts. If you enjoy or find them helpful, please consider a small bitcoin donation:
12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
Cool, you are actually using R to do these analysis. I am Stats student too. Your posts are very helpful
ReplyDeleteIndeed I am. I mostly use ggplot2 for plots now since it's so flexible. Are you mining or just generally interested in bitcoin?
Delete