Pages

▼

Sunday 8 December 2013

December 8th 2013 weekly pool and network statistics




Other weekly pool and network statistics posts

Other "in memoriam" posts

Welcome, miners.

Changelog:
  • Nil
Usual pools missing from results:
  • 50BTC.com, Triplemining, Deepbit: No blocks solved this week.
  • BTCMine, Giga's pool: Both closed.
Errors:
  • Nil.
Pools with coinbase signature:
Recent coinbase messages:

Pool hopping:
  • Nil.

1. BTCGuild and GHash.IO 
GHash.IO overtook BTCGuild this week - they now have a quarter of a percent more of the network than BTCGuild.

Last week I wrote:
"GHash.IO keep increasing their share of the network, most likely due to CEX.IO trading. I'm not sure how I feel about this - it's an increase in the proportion controlled by a single entity, but in effect any pool has the same control of hashes. It should make no difference that (as far as I'm aware) CEX.IO maintains the hash sources locally rather than the sources being distributed. Is there a downside I'm not understanding?"
I received a couple of good responses on bitcointalk.org:

From eleuthria, BTCGuild pool op:
"Only extra worry from cex.io/ghash.io that is different from past concerns is accountability.  If a public pool *attempted* to do something nefarious that pool just committed suicide whether they succeed or fail at the gamble.  When a pool that has ~1 PH/s (based on estimates looking at their speed fluctuations during known pool issues for public vs private) privately owned, there is no accountability left.  Pair that with using a 0% fee for what was already the 2nd largest mining entity before the public was allowed in.  If they attempt something, there is basically no downside.  If the public hashrate leaves due to an attempt, they aren't actually losing anything (no fee) other than the mining time on their private farm."
From gmaxwell, bitcoin developer:
"The excuse giving for years of why consolidations of ten percent, twenty percent, or even more, in the hands of pool operators didn't effectively disprove the Bitcoin security model was that pool operators were more obligated than a typical miner to behave with the public interest at heart because the hashrate controlling miners could vote with their feet.

I've never been too fond of the argument: evidence (e.g. miners voting with their feet very slowly even when a pool is clearly robbing them) suggests otherwise... But that argument doesn't even exist for GHash.io/CEX.io: the miners are captive and cannot leave. Worse, there is a moral hazard because an unknown portion of the hardware is paid for by other people (at top dollar rates too) and so if some stunt they perform debases its value... so what? Heck, perhaps it drops the market value down to nothing an cex can buy their obligations back for a song. This means that CEX.io can probably profit from an attack even if that attack ultimately fails."
Thanks for explaining that, guys. I feel a little foolish for not having taken market forces into account.


2. "Unknown" at 10% of the network
I've developed my scripts to cast as wide a net as possible when identifying block owners, even so there are 137 blocks unaccounted for by the usual sources. I wonder if there are a bunch of new solominers? The network solved over 1300 blocks this week, so there are certainly new hash sources being added.


3. In memoriam
(Last "in memoriam" post)
I was once again busy all week on a project unrelated to mining and missed the planned closure of GigaVPS and Liquidbits' Mineb.tc pool (referred to as "Giga's pool" in the weekly stats). I'm sad to see the pool go, it was a good pool, stable and with great stats. I wish Giga VPS and LiquidBits the best in whatever project to which they next turn their attention. For those readers interested,  I posted an audit of the the pool's "luck" in August

It also looks like dbitcoin and company have finally moved the remaining hashes from BTCMine to BTCDig. I'm glad to see a famous old mine continuing under a new guise.

Bitclockers.com has been down for so long now that I'm also considering that pool closed.

So here's an update of the "In memoriam" chart of the percentage of hashrates of all the dead pools for which I have records, in order of the last week in which they solved a block.

As I wrote last time:
"Please take some time to think about the pool operators who ran these pools, loved them as if they were their own children, and did their part to help secure the network. Also, don't forget about the many other pools that didn't make it -  Arsbitcoin and Continuum pool (the first pool to use the Geometric method of reward distribution, the progenitor of DGM) come to mind, but there have been many others, especially those that were unable to change from a proportional reward method."




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



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


<weeklypoolstatistics>

at

No comments:

Post a Comment

Comments are switched off until the current spam storm ends.