6.1 Bitlc.net - Pool hopping and unfulfilled promise.

0. Introduction

Pool:  Bitlc.net
Bitcointalk.org forum thread: https://bitcointalk.org/index.php?topic=10121.msg145350#msg145350
Pool op: Jim Nelin
Publicly identifiable pool operator: Yes.
Legally incorporated company: Yes
Payout method: Standard proportional reward
Hoppable? Yes.
Fee:  No fee
Block confirmations for payout:  0, payout is immediate.
Orphaned blocks: paid
Transaction fees: Paid to miners.
Current pool hashrate:  50 to 500 Ghps
Availability of public statistics: very good

• All rounds since the start of the pool are available via json API.
• Data includes txid , round shares, start and finish times for each round, number of valid share submitted, number of valid and invalid shares submitted.
• Block announcements delayed by up to two hours to reduce profitability of strategic mining ("pool hopping").
• Worker stats available via json API.

Accuracy of public statistics: Good. There were only three blocks with suspect data: block height 136037, 136049, and 136060. Data for these blocks contains either too many shares per round or round duration too short, indicating an unlikely 1 to 4 Thps average pool hashrate for these rounds.

Are public statistics likely to be reflecting actual data? Yes
Public perception of pool and pool op: Average to poor. Many miners have made complaints relating to the lack of ETA for a pool hopper proof reward system.

Should I mine here right now? No.

Should I mine here once a fair  payout method change is instituted? Uncertain.

1.  Starting with promise.
Forum member Jine (Jim Nelin)  announced Bitlc.net (at that time, Bitcoins.lc). He identified himself publicly on his website and on the Bitlc.net forum thread, and legally incorporated Bitlc.net - one of the few pools to do so.

From the start, the website had a very fast, attractive and user friendly interface compared to many pools at the time, and quickly gained hashrate. Within a month and a half the Bitlc.net had gained 5% of the network hashrate, and a month and a half later this had dropped to 2% of the network hashrate. Currently, Bitlc.net's base hashrate (when the pool isn't being used by pool hoppers) is about 0.5% of the network hashrate.

Why did a pool many useful applications for miners (including an online wallet service) and a website with a very good user interface fail so terribly? I believe the answer is twofold. 

Firstly, the pool doesn't take fees, and actually pays orphaned blocks, and provides a zero confirmation payout. The business plan was to provide value added services to miners for which they would want to pay, however few of these projects have eventuated. One, a bitcoin exchange, has been in the planning stages since the pools inception. A lack of income for the pool operator means difficulty in finding time to manage the pool and although Jine responds a quickly to miner complaints, it could be argued that some of these problems could have been solved by being able to spend more time monitoring the pool.

The second reason I believe the pool is failing is that the reward method is still a standard proportional reward method. Fulltime miner lose a significant proportion of income to pool hoppers, so why would anyone aware of this mine there? Even delaying the announcment of new blocks by a random delay of up to two hours does not prevent pool hoppers from benefiting at the expense of fulltime miners.

2. A potted history of Bitlc.net.
The following timeline of events is taken from the Bitlc.net forum thread. Plots of hashrate and percentage of network hashrate follow for reference.

• 27th May, 2011 Announcement: Jine announces Bitcoins.lc
• 28th May, 2011 Announcement: First DDoS attack against Bitcoins.lc. Jine hypothesises the attack is from another pool operator.
• 29th May, 2011 The first time I read a suggestion to use a peer to peer pool to combat DDoS.
• 29th May, 2011 Announcement: First block solved.
• 29th May, 2011 Announcement: Second block solved. 
• 29th May, 2011 Announcement: Second DDoS attack.
• 6th June, 2011 First possible indicator of pool hopping.
• 6th June, 2011 Announcement: Bounty of 0.1 btc per new 1 Ghps added to pool offered in order to increase pool hashrate.
• 7th June, 2011 Hashrate jumps from 30Ghps to 50 Ghps.
• 9th June, 2011 Announcement: Jine claims a high stale rate will result in no loss of earnings to miners.
• 10th June, 2011 Announcement: Jine offers a 10 btc bounty to solve high percentage of stale shares problem.
• 11th June, 2011 Invalid share problem solved.
• 12th June, 2011 First request from a miner for a fair reward method.
• 14th June 2011 Announcement: Pool hashrate at 180 Ghps; no waiting for confirmation for payment (ie all orphans paid).
• 14th June, 2011 Bug causes miners to be paid for same block twice, Bitlc.net allows miners keep coins obtained in error.
• 23rd June, 2011 Announcement: Pool hashrate reaches 500 Ghps.
• 25th June, 2011 Announcement: Jine offers bounties to solve problems caused by increase in pool hashrate.
• 7th July, 2011 First mention of a proxy pool causing problems for Bitlc.net - possibly Multiclone?
• 9th July, 2011 Announcement: Company and name registered; development on the exchange platform started.
• 11th July, 2011 Banning IPs to reduce negative effects of pool proxies starting to affect miners.
• 11th July, 2011 First mention of banning multiclone and not paying out earnings.
• 15th July, 2011 Mention of pool hashrates fluctuations (first indication of pool hopping?).
• 16th July, 2011 Appeal to pool hopper proxies support LP and to reduce getworks.
• 17th July, 2011 More problems caused by pool hopping proxies. (Pool hashrate starts to crash at this point)
• 20th July, 2011 Randomising statistics sent to requests without a user agent. First attempt at protecting pool from pool hoppers in general.
• 28th July, 2011 Port 80 and 8080 available for mining, patch applied leading to improved stale share rates.
• 24th July, 2011 Jine admits that new block announcements are delayed for up to one hour. No reason given. Pool hashrate recovers to 500 Ghps.
• 2nd August, 2011 More problems due to IP bans.
• 8th August, 2011 Jine admits that new block announcement is delayed for up to 2 hours "avoid huge amounts of pool hoppers".
• August to September, 2011 Little activity on thread and few announcements from Jine. Pool hashrate drops to 300 Ghps.
• 20th September, 2011 Another attack on pool. Also Jine explains that website updates have not been completed due to the necessity of making a living (when running a pool without a fee).
• 23rd October, 2011 Another botnet attack.
• 1st November, 2011 Very few posts by Jine in thread for past 1.5 months, pool hashrate at 200Ghps. Pool hopping adds 100Ghps.
• 20th December, 2011 Bitcointalk.org forum member deepceleron claims Jine doesn't believe pool hoppers hurt full-time miners.
• 12th January, 2012  Jine last active on bitcointalk.org forum Nov 15th 2011.
• 17th January, 2012 Announcement: New site finally launched, major upgrades.
• 31st January, 2012 Eleuthria, BTC Guild pool operator indicates that Bitlc.net could possibly being pool-hopped by ABC proxy pool.
• 2nd February, 2012 Massive spike in pool hopping hashrate starts.
• 8th February, 2012 First post confirming plans to change to PPLNS/DGM.
• 12th February, 2012 Bitlc.net now supporting P2SH with help of eleuthria of BTCGuild.
• 16th February, 2012 Massive spike in pool hopping hashrate ends and "hollyhunter" (aka ABC proxy pool) complains of not beng able to access funds.
• 18th February, 2012 Jine addresses "hollyhunter" aka ABCPool.
• 18th February, 2012 Jine explains that recent downtimes are caused by ABC proxy pool.
• 2nd March, 2012  Announcement: "We will not add a fee nor stay with proportional".
• 27th March: Jine still plans change of payout method, but has no ETA for the changeover.
• 25th June: Jine apologises for downtime and software crash.
• 25th August, 2012 Base pool hashrate is at 80 Ghps, additional hashrate from pool hoppers is 300 Ghps.

Note that the pool's percentage of the network hashrate is in an almost continual decline since August 2011. The changes in the pool hashrate hide this somewhat, but hashrate as a percentage of network hashrate is a reasonable gauge of a pool's popularity. Bitlc.net's popularity started to wane permanently within two and a half months of starting.

I have a few opinions about that:

• Inability to deal with pool hopping proxies. Proxies such as Multiclone and ABC Pool put the pool under a load that it could not manage. However, rather than changing to a fair reward method, Jine attempted almost any other fix to reduce the problem - banning IPs and accounts, delaying withdrawal of earned coins, delaying statistics by a random amount (first up to one hour, then up to two hours), making the pool statistics vary randomly for some users, beefing up the pool to attempt to deal with the massive onslaught of hashes the start of a round brought. 
• Jine's attempts to reduce the negative effects of pool hoppers on the pool have not prevented pool hoppers from using the pool, and did not prevent the negative effects of pool hoppers on fulltime miners. From the forum thread, it seems many pool users left the pool once they realised pool hopping would affect their earnings and Jine was delaying the changeover to a fair reward method.
• Inability to devote sufficient time to the pool and complete promised tasks and updates on time or at all.

I think it would not take much to make Bitlc.net a well used pool once again. JIne would need to:

• Change to a fair reward method.
• Monetise Bitlc.net so he could afford to spend more time completing promised upgrades and applications. Whether the monetisation would be as Jine initially intended with miners paying for value added services (much like Bitminter's "perk" system) or a flat fee, without earning from the pool it would be impossible for Jine to spend the amount of time that running a pool demands.
• Bitlc.net must cost Jine significant money - he pays at 0 confirmations (and hence pays orphaned blocks)  and pays transaction fees to miners. If he can outlay this sort of cash and keep the pool running for more than a year, then he is well positioned to change Bitlc.net low fee PPS pool, making the changeover to a fair reward method simple.

2. Do Bitlc.net's round lengths appear geometrically distributed?
Are Bitlc.net's published round statistics accurate and reliable? Data used for the following analyses are here. Each row contains the blockheight, the unixtime the block was solved, how many valid shares were submitted before the round was solved, the duration of the round and the bitcoin mining difficulty (D) at which the round solved.

Readers should be aware from previous posts that number of shares required to solve a round is a geometrically distributed variable with respect to D. This makes analysing (shares per round) / D   a useful method to provide evidence that a pool is accurately reporting it's data and paying it's miners fairly.

First a visual inspection. Below are plots showing a comparison of Bitlc.net's (shares per round) / D with simulated data:

• Chronological ordering of total round shares as a fraction of D.
• Boxplots of total round shares as a fraction of D, grouped by difficulty period.

This simple visual inspection of Bitlc.net's published shares per round data does not show any significant variation from simulated data.

3. Theoretical comparisons i: Quantiles and empirical cumulative distribution function.

As discussed in previous posts, the cumulative distribution function (CDF) of Bitcoin pooled mining round lengths describes the probability that a round will be solved after a given number of shares have been contributed. For example, a large probability means that most rounds will be solved when a large number of shares are submitted. Since shorter rounds are more common, we expect the CDF to rise rapidly, and then level out and approach 1 at larger round lengths.

The comparison plot below on the left is a QQ plot  (quantile-quantile) to compare the quantiles from Bitlc.net's distribution of (shares per round) / D and what that distribution should be theoretically.

Quantiles are points taken at regular intervals from the cumulative distribution function (CDF). The empirical quantiles are from Bitlc.net (shares per round) / D  data, and the theoretical quantiles are calculated using the number of rounds in the dataset, so that there are the same number of theoretical as empirical data with the same cumulative probabilities. The empirical quantiles are then plotted as a function of theoretical quantiles, and the relationship here should be y = x. 

The comparison plot below on the right shows the difference between the theoretical CDF for geometrically distributed variables and the empirical CDF (eCDF) for Bitlc.net round lengths. The ecdf is is defined as:

ecdf = n/max(n) where 'n' is the nth datapoint in a set of data ordered by size

The QQ plot shows that the (shares per round) / D data does not vary significantly from those expected from a geometric distribution and the QQ line is very close to the expected y=x. The eCDF and theoretical CDF are very similar indicating the probability distribution for Bitlc.net's (shares per round) / D data is similar to that of a geometrically distributed variable.



4. Theoretical comparisons ii: The Kolmogorov-Smirnov test.

We can assess the comparison between the eCDF and the theoretical CDF more rigorously using the Kolmogorov-Smirnov test. In this case:

If:
H0 = Bitlc.net's  round lengths belong to a geometric distribution,
HA = Bitlc.net's  round lengths do not belong to a geometric distribution,
Then:

p value = 0.9995428

This means we cannot reject H0 as a hypothesis, and provides evidence that Bitlc.net's round lengths are distributed geometrically.

5. Theoretical comparisons iii: Moments.

Mean, median, variance, skewness and kurtosis are statistical parameters that we have previously used to analyse the distribution to which a pool's round length random variable belongs. The theoretical geometric distribution statistics and experimental parameters are shown in the table below.

The upper and lower bound for the mean, median, and standard deviation are the 95% confidence intervals for the sample statistics. For the skewness and kurtosis the lower and upper bounds are the bias-corrected and accelerated 95% confidence intervals as per D. Wright & J. Herrington.

The 95% confidence intervals for mean, median and standard deviation do not exclude the theoretical population mean, median, and standard deviation parameters of a geometric distribution where mean = D. Kurtosis and skewness are quite close to the expected values, and support the conclusion that the rounds are indeed geometrically distributed.

From the foregoing four sections,  we can conclude the historical round data from Bitlc.net is likely to have been accurate and honest.

6. Pool hopping and fulltime miner earnings loss
Having concluded that the available data is indeed accurate, we can use the data to determine what the expected payment per share is for fulltime miners at Bitlc.net. 

Firstly, is Bitlc.net being mined strategically? If so, we would expect shorter rounds to have a higher average hashrate, and longer rounds to have a lower average hashrate. The plot below is of the pool's chronological hashrate with short and long round coloured in terms of their CDF.

After the start of August 2011 (when thread posts reveal proxy pool hopping started) the separation in hashrate for the long (red) rounds and the short (blue) rounds becomes increasingly marked - short rounds have a much higher average hashrate than longer rounds. This is as we would expect if the pool was used by pool hoppers.

To estimate the amount of fulltime miner share value lost as a result of pool hoppers. In post 4.2: Slush's score method and miner earnings I derived a function for determining the maximum possible loss of expected share value for fulltime miners to pool hoppers at a  pool with a proportional reward method:

Maximum loss of share value for fulltime miners =  

 (1 - (1 - exp(-x) + f(x)))/(1 - (1 - exp(-x) * (x + 1) + x * exp(-x))) 

where x = shares already submitted to pool in round as a fraction of difficulty, and 

    f(x) = the expected earnings from shares submitted to rounds longer than the "hop point"

For a standard proportional pool, f(x) is:

f(x) = exp(x) * E1(x) * exp(-x) * x
= E1(x) * x 

where E1(x) is the exponential integral E(n=1)

In order to determine the actual change in expected share value for fulltime miners, the ratio of the of the hashrate of those miners who submit shares only to the "hop point" to those who mine fulltime, so that the equation above becomes:

Maximum loss of share value for fulltime miners =  

 (1 - y*(1 - exp(-x) + f(x)))/(1 - y*(1 - exp(-x) * (x + 1) + x * exp(-x))) 

where x = shares already submitted to pool in round as a fraction of difficulty, 

      y = (pool hopper hashrate - fulltime miner hashrate) / (average hashrate up to "hop point"), and 

    f(x) = the expected earnings from shares submitted to rounds longer than the "hop point"

After substituting and simplifying, the earnings for fulltime miners in terms of the expected earnings for a share is:

(exp(x) * (x * y * E1(x) + y - 1) - y) / (exp(x) * (y - 1) - y) . . . 1.

So the following variables need to be determined: y, the ratio of pool hopper hashrate to fulltime miner hashrate, and x, the point at which pool hoppers tend to leave the pool (in terms of shares already submitted to pool in round as a fraction of difficulty). To help determine a typical change in hashrate with respect to round length for Bit.lc, below are plots of (shares per round) / D  and average hashrate for the round from August 2011 onward which have been separated into groups of fifty rounds.

In each plot, the hashrate for longer rounds is always lower than the hashrate for shorter rounds. As the hashrate contributed by pool hoppers increases, the decrease in hashrate becomes more pronounced. Fulltime miners have been increasingly losing earnings at this pool since August last year.

The last one hundred rounds at Bitlc.net have had comparable average hashrates per round. The plot below combines the last 100 rounds.

The spread of hashrate below 0.435*D is most likely due to pool hoppers leaving Bitlc to mine at pools where the expected value of  share is higher, or inaccurate estimations of when rounds have started. This makes it very difficult to model a function to determine the actual (rather than average) pool hashrate. However, an estimation of the pre and post "hop point" hashrates can be made by taking the median hashrate before 0.435 and after 2 * D. This method results in an estimated pool hopper hashrate of 288.15 Ghps and fulltime miner hashrate of 86.45 Ghps.

Assuming pool hoppers stop submitting shares at 0.435*D on average,  expression 1. results in 0.703. This means that fulltime miners at Bitlc.net earn only 70.3% of expected earnings - a 29.7% loss in earnings. 

While many miner advocates are concerned about loss of earnings for Deepbit.net's fulltime miners, that percentage loss is minimal compared to the loss of earnings experienced by fulltime miners at Bitlc.net.

7. Conclusions

• Bitlc.net began with a good service and great ideas. Unfortunately the pool has stagnated with few recent updates and an unfair reward method.
• Bitlc.net could be a much more successful pool if the reward method was changed and if monetised in such a way that Jine was able to spend more time on the pool or delegate someone to manage it.
• Fulltime miners at Bitlc.net currently lose approximately 30% of their expected earnings to pool hoppers. By comparison, at Deepbit.net the current percentage loss of earnings for fulltime proportionally rewarded miners to pool hoppers is 1.9%.
• Mining at a 5% fee PPS pool would earning the fulltime miners at Bitlc.net 35% more than they earn at Bitlc.net currently.

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