Pages

Sunday, 27 October 2013

October 27th 2013 weekly pool and network statistics




Other weekly pool and network statistics posts


Welcome, miners.

Changelog:
  • Polmine added to the weekly statistics. A big thank you to Polmine for creating a special API for yours truly, and another big thank you to bitcointalk forum member pajak666 for making the request, and then making sure I didn't forget to add it to the weekly stats.
  • Updated some of the charts to Thps. Yet to update the table, poolhopping chart and  user hashrate density chart.
  • GHash.IO is back in the charts. Thanks for getting the glitch sorted for me, Alex. The stats just weren't the same without GHash.IO.
Usual pools missing from results:
  • None
Errors:
  • Nil
Pools with coinbase signature:
Recent coinbase messages:

Pool hopping:
  • Nil.

1. Network solves 1508 blocks this week.
Another extreme block solve rate, leading to another ~ 50% increase in difficulty. I think most miners are going to have trouble making enough to pay for electricity soon. On the upside, there will be very few CPU and GPU miners left, and once most pools adopt a minimum share submission difficulty, there will be fewer still.

2. The large get larger.
It seems that miners want the reduction in variance that a large pool brings - the top five pools all saw an increase in their share of the network, where as the lower five saw a reduction in their share of the network. I hazard a guess many of these are 50BTC refugees (see section 5, below) used to the low variance a large pool brings, and they probably feel safer at a large well established pool.

I would like to point out here that spreading your hashrate among various pools not only helps keep the network less centralised, but also reduces your variance significantly over using just one pool. Send a few shares to a smaller pool and help the network.

3. Eligius takes 3rd (behind Ghash.IO and BTCGuild).
Eligius continues its meteoric rise in hashrate. Anyone know why? It's a recent change and extreme. Good luck to wizkid!

4. Eclipse and Polmine have similar ups and downs.
(see figure 4) Eclipse's hashrate continues to bounce, and Polmine's is quite similar. I've double checked my scripts, so I have no idea why this would be. Big hashrates being added and removed every second block? Errors in the data? I have no idea. But it is very unusual.

5. 50BTC is really down.
The news that 50BTC.com was hacked and many coins stolen hit the community hard. This was quite a large pool (although no longer) and many miners have been affected. Although they seem to be attempting to work their way through the mess, 50BTC.com spokespeople have been slow to reassure their English speaking miners. Many have been upset that they haven't been able to withdraw BTC, and many have changed pools. FWIW, I think 50.BTC have planned to be here for the long haul -  but after this last hack they may not be able to recover.

Good luck 50.BTC - we hope you can recover and prosper.



Organofcorti lives!

As usual, please post comments if there's anything you don't understand, with which you disagree, or just think is wrong.

The charts

Table: Table of all pools with public data and their various statistics averaged for the last seven days - for smaller pools the average may be more or less than seven days, depending on number of blocks solved for the week. Network hashrate and that of some pools are estimates, the upper and lower 95% confidence interval bounds are included.
Figure 1: Pie chart of the percentage of network blocks hashrate by pool. "Unknown" combines those pools for which I can't scrape statistics, solominers and private pools. The percentage of network hashrate will only be approximate since the exact network hashrate is unknown.
Figure 2: Chart of network hashrate, hashrate of the largest mining pool, combined hashrates of the three largest mining pools, and a line representing 50% of the network hashrate. Handy if you're worried about 51% attacks. The upper and lower 95% confidence interval bounds for the network hashrate are in between the shaded areas.
Figure 3: Chart of chronology of pool hashrates, averaged per week.
Figure 4: Chart of average hashrates per pool per round for the week, and per 144 rounds for the network. The upper and lower 95% confidence interval bounds for the network hashrate are in between the shaded areas.
Figure 5: Chart of chronology of negative binomial CDF probability of shares submitted and blocks produced for the week.
Figure 6: Chart of chronology of round length divided by difficulty, averaged per week.
Figure 7: Chart of hashrate vs round length for hoppable pools (the larger the hashrate increase at the start of a round, the larger the loss to strategic miners).
Figure 8: Chart of pool user hashrate distribution. Note that for some pools this average is over twenty four hours, some pools are averaged over an hour or more and some for only fifteen minutes, so expect some variance in the results.


















Thanks to blockexplorer.com for use of their network statistics.

organofcorti.blogspot.com is a reader supported blog:

12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r

Find a typo or spelling error? Email me with the details at organofcorti@organofcorti.org and if you're the first to email me I'll pay you per error:
 

I'm terrible at proofreading, so some of these posts may be worth quite a bit to the keen reader.


<weeklypoolstatistics>


No comments:

Post a Comment

Comments are switched off until the current spam storm ends.