Pages

▼

Monday, 13 January 2014

January 12th 2014 Weekly Pool and Network Statistics


Other weekly pool and network statistics posts


Welcome, miners.

Changelog:
  • "Luck" for BTCGuild not included, and I will not be including it again until I can find a measurement in which I have more confidence. This is nothing to do with my confidence in BTC Guild, just the difficulty in calculating a luck score that is comparable to those of other pools, since BTC Guild does not report shares per round.
Usual pools missing from results:
  • Deepbit, GIVE-ME-COINS.com, 175btc.com, BTCDig, Ozcoin, Itzod: No blocks solved this week.
  • 50BTC.com - API no longer working. I'll need to contact them to get this fixed.
Errors:
  • Nil.
Pools with coinbase signature:
Recent coinbase messages:

Pool hopping:
  • Nil.
1. I had a wonderful break, thank you for all your Christmas / New Year well-wishing.
As well as a nice break in the country-side, I've been working hard on a way to get real time charts going. The big hurdle was to come up with an automated way of assigning blocks to pools. I've now done this based on coinbase signatures, known generation addresses and blocks claimed by pools. In the short term this allows me a great deal of flexibility and ease when investigating block ownership; in the medium term I'll be able to base weekly data on blockchain results and pool website results separately; and in the long term it will be the engine on which real time charts can be produced. I've still got lots of work to do, but it's coming along (and it's why this post is being published a week late).

As an example of the sorts of things I can do, have a look at this:

http://bitbin.it/3iIbl6tA

It's a .csv table (easy to import into spreadsheeting software) and provides the attribution for each block, and whether or not the block creator was identifiable by either coinbase signature or generation address, or whether the pool claimed the block on their website, and what proof they used that the block was theirs (tx hash or block hash). Where available, the number of difficulty 1 equivalent shares / network difficulty (the standard "luck" calculation) is given in the final column - greater than 1.0 is poor "luck", less than 1.0 is good "luck".


2. Donation address has changed.
My previous donation address was a personal address I used for everything. The new address:

1QC2KE4GZ4SZ8AnpwVT483D2E97SLHTGCG

is only going to be used for blog donations so I can keep track of them better.



3. GHash.io
I'm not going to write much about this. I think much of the panic of the past week is due to poor interpretation of the 24 hour Blockchain.info pie charts, which are affected by variance. The weekly average is at about 32% of the network, and the rate of increase is less than it has been. It's important to encourage GHash.io to reduce its network percentage but there's no need for the sorts of witch hunts we've been seeing - the worst since those protesting against DeepBit when that pool was king.



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, per 144 rounds for the network, and per hour for BTCGuild. 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 the use of their network statistics.

organofcorti.blogspot.com is a reader supported blog:

1QC2KE4GZ4SZ8AnpwVT483D2E97SLHTGCG

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 ten errors:



Please refer to the most recent blog post for current rates or rule changes.

I'm terrible at proofreading, so some of these posts may be worth quite a bit to the keen reader.
Exceptions:
  • Errors in text repeated across multiple posts: I will only pay for the most recent errors rather every single occurrence.
  • Errors in chart texts: Since I can't fix the chart texts (since I don't keep the data that generated them) I can't pay for them. Still, they would be nice to know about!
I write in British English.


<weeklypoolstatistics>
at

No comments:

Post a Comment

Comments are switched off until the current spam storm ends.