Weekly pool and network statistics

[windpath]

Errors:

    P2Pool user and block statistics still unavailable, although p2pool.info is back up.

Chances are I have stored any p2pool data you might be looking for since June 11th, let me know what data you need and I'll do my best to provide it...

http://minefast.coincadence.com/p2pool-stats.php

[1713430459]

1713430459

[1713430459]

1713430459

[organofcorti]

Errors:

    P2Pool user and block statistics still unavailable, although p2pool.info is back up.

Chances are I have stored any p2pool data you might be looking for since June 11th, let me know what data you need and I'll do my best to provide it...

http://minefast.coincadence.com/p2pool-stats.php

Thanks! The pool data isn't available because I haven't had time to change scripts to the new API yet, but I do need a 'hashrate per user' API that p2pool.info doesn't yet have - any chance you're keeping that data and that you can provide me an API for it?

[organofcorti]

We are now offering public lucky data at http://www.f2pool.com/bitcoin-blocks and http://www.f2pool.com/litecoin-blocks , these pages are updated manually, usually on a daily basis or so.

Sweet! Thanks for that.

1. I assume "shares" is total submitted shares and "difficulty" is <sum of share difficulty / network difficulty > ?
2. Any chance of historical data?

[macbook-air]

We are now offering public lucky data at http://www.f2pool.com/bitcoin-blocks and http://www.f2pool.com/litecoin-blocks , these pages are updated manually, usually on a daily basis or so.

Sweet! Thanks for that.

1. I assume "shares" is total submitted shares and "difficulty" is <sum of share difficulty / network difficulty > ?
2. Any chance of historical data?

The first difficulty is simply (bdiff1target ÷ blockhash). Shares is the total submitted bdiff1 shares since, last block found, and, last valid (non-orphaned) block found. Lucky could be worked out from (average network difficulty since last block found ÷ shares).

[organofcorti]

We are now offering public lucky data at http://www.f2pool.com/bitcoin-blocks and http://www.f2pool.com/litecoin-blocks , these pages are updated manually, usually on a daily basis or so.

Sweet! Thanks for that.

1. I assume "shares" is total submitted shares and "difficulty" is <sum of share difficulty / network difficulty > ?
2. Any chance of historical data?

The first difficulty is simply (bdiff1target ÷ blockhash). Shares is the total submitted bdiff1 shares since, last block found, and, last valid (non-orphaned) block found. Lucky could be worked out from (average network difficulty since last block found ÷ shares).

Ah, understood. Thank you.

[organofcorti]

July 20th 2014 Weekly Hashrate Contributor and Network Statistics

Other weekly pool and network statistics posts

Welcome, miners.


Changelog:

    Nil.

Errors:

    P2Pool user statistics are now available from minefast.coincadence.com  - thanks guys!
    I'll fix the p2pool block statistics this week, should be ready for next week.

Notifications:

    Nil.

0. GHash.IO hit 39.99% this week?

Despite a weekly average of ~ 30% of the network, mid-week GHash.IO claimed to have hit 40% and was asking miners to leave. I think this really underlines a problem - how should the percentage of the network be calculated? Over a number of network blocks, or hours/days?



Explanation of the tables and charts.

Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are from either coinbase signatures, known generation addresses or claimed by a particular pool block history. Includes non-Pool hashrate contributors. Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table.

"Unknown" is not an entity, but simply the group of blocks to which I cannot give attribution using the methods given above.





Table 2: Pool reported block history statistics.  This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round.

    A much more accurate estimate of the hashrate, confidence intervals are unnecessary.
    Orphan races lost, and percentage of  solved blocks that were not added to the blockchain.
    "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty,  or (equivalently) accepted shares / expected shares.
    CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks.
    Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one billion Difficulty 1 shares (or one thousand difficulty megashares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block.

Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck calculations cannot be calculated but orphaned blocks can. Pools such as "Discus Fish" that don't have a public pool interface cannot be included.





Figure 3: Percentage of blocks solved each week for the current top ten contributors.

Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data.



You can view all previous charts at http://organofcorti.blogspot.com.au/search/label/weeklypoolstatistics and other posts and fun things at http://organofcorti.blogspot.com. Follow me on Twitter @oocBlog for notification of new posts as soon as I publish.

[windpath]

Errors:

    P2Pool user and block statistics still unavailable, although p2pool.info is back up.

Chances are I have stored any p2pool data you might be looking for since June 11th, let me know what data you need and I'll do my best to provide it...

http://minefast.coincadence.com/p2pool-stats.php

Thanks! The pool data isn't available because I haven't had time to change scripts to the new API yet, but I do need a 'hashrate per user' API that p2pool.info doesn't yet have - any chance you're keeping that data and that you can provide me an API for it?

I'm actually not yet storing miner estimated hash rates, and keep in mind they are very rough estimates, there is an explanation as to how we calculate it in a link on the active miners tab. I'm happy to put together a json API for you, let me know what miner data you would like included, I think what is in the "active miners" tab on the global stats page should do the trick?

Also, since p2pool.info came back online much of the data seems to be incorrect (# of miners is the most glaring example), this week I'm going to tipple check all my numbers and formulas to ensure accuracy on Coin Cadence.

[organofcorti]

July 27th 2014 Weekly Hashrate Contributor and Network Statistics

Welcome, miners.

Changelog:

    Cointerra added.
    bcpool.io added.


Errors:

    "I'll fix the p2pool block statistics this week, should be ready for next week" - well, that didn't happen. I blame Cryptocon, and especially Jonathan Levin's excellent talk on the "dark economy" of bitcoin.
    Discus Fish pool stats are available, not yet added.


Notifications:

    Nil.


0. The network hashrate drops - again.
The average weekly network hashrate has dropped for the second time in four weeks. A drop in the weekly network hashrate has not happened very often since the start of 2013, but combined with the slow deceleration in the network hashrate, we may be seeing the start of a plateau. It may only be a short term plateau until some ASIC manufacturer gets a shipment of ASICs out the door, but the stable price combined with probably only incremental improvements in price and efficiency, the network hashrate may actually be headed for a long term hashrate stability.

1. Two new hashing entities added.
Timo Hanke kindly contacted me this week to tell me which generation address belongs to Cointerra, and I've added bcpool.io from their coinbase signature.

This leaves 1AcAj9p6zJn4xLXdvmdiuPCtY7YkBPTAJo and 14yfxkcpHnju97pecpM7fjuTkVdtbkcfE6 as the main interesting generation addresses at over 9% of the network. I would like to find some time to try and track them, but if someone gets there first, please let me know.

Thank you also to Amith and Tamás for their emails and help.


Explanation of the tables and charts.

Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are from either coinbase signatures, known generation addresses or claimed by a particular pool block history. Includes non-Pool hashrate contributors. Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table.

"Unknown" is not an entity, but simply the group of blocks to which I cannot give attribution using the methods given above.





Table 2: Pool reported block history statistics.  This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round.

    A much more accurate estimate of the hashrate, confidence intervals are unnecessary.
    Orphan races lost, and percentage of  solved blocks that were not added to the blockchain.
    "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty,  or (equivalently) accepted shares / expected shares.
    CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks.
    Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one billion Difficulty 1 shares (or one thousand difficulty megashares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block.

Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck calculations cannot be calculated but orphaned blocks can. Pools such as "Discus Fish" that don't have a public pool interface cannot be included.





Figure 3: Percentage of blocks solved each week for the current top ten contributors.

Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data.



You can view all previous charts at http://organofcorti.blogspot.com.au/search/label/weeklypoolstatistics and other posts and fun things at http://organofcorti.blogspot.com. Follow me on Twitter @oocBlog for notification of new posts as soon as I publish.

[organofcorti]

We are now offering public lucky data at http://www.f2pool.com/bitcoin-blocks and http://www.f2pool.com/litecoin-blocks , these pages are updated manually, usually on a daily basis or so.

Sweet! Thanks for that.

1. I assume "shares" is total submitted shares and "difficulty" is <sum of share difficulty / network difficulty > ?
2. Any chance of historical data?

The first difficulty is simply (bdiff1target ÷ blockhash). Shares is the total submitted bdiff1 shares since, last block found, and, last valid (non-orphaned) block found. Lucky could be worked out from (average network difficulty since last block found ÷ shares).

macbook-air, the data isn't in any format I recognise, definitely not an HTML table. I could work around the lack of formatting, but that can cause errors in results from time to time.

Is it possible to have the data in a HTML table, or as a simple .csv?

[organofcorti]

August 3rd 2014 Weekly Hashrate Contributor and Network Statistics
Welcome, miners.


Changelog:

    Bitfury added.
    Discus Fish (aka F2Pool) 'luck' statistics added - thanks fellas!
    The folk from GHash.IO kindly gave me access to the complete log of their block and share data, so plots for this pool have a longer history now.
    Bitcoin Affiliate Network added and listed as "BAN". I think they previously signed  as bcpool.io.

Errors:

    Nil

Notifications:

    It turns out that p2pool.info is no longer offering shares per round statistics, so no p2pool 'luck' statistics until that changes.

0. Bitfury added.

After last week I decided to spend some time reducing the unattributed blocks, the "unknowns". After reading this CoinDesk post I feel confident I have a few addresses which can be attributable to Bitfury. This brings the 'unknowns" down to ~6%, and as long as Bitfury and GHash.IO aren't being controlled by the same entity, we can all rest a little more .



Explanation of the tables and charts.

Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are from either coinbase signatures, known generation addresses or claimed by a particular pool block history. Includes non-Pool hashrate contributors. Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table.

"Unknown" is not an entity, but simply the group of blocks to which I cannot give attribution using the methods given above.







Table 2: Pool reported block history statistics.  This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round.

    A much more accurate estimate of the hashrate, confidence intervals are unnecessary.
    Orphan races lost, and percentage of  solved blocks that were not added to the blockchain.
    "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty,  or (equivalently) accepted shares / expected shares.
    CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks.
    Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one billion Difficulty 1 shares (or one thousand difficulty megashares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block.

Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck calculations cannot be calculated but orphaned blocks can. Pools such as "Discus Fish" that don't have a public pool interface cannot be included.





Figure 3: Percentage of blocks solved each week for the current top ten contributors.

Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data.



You can view all previous charts at http://organofcorti.blogspot.com.au/search/label/weeklypoolstatistics and other posts and fun things at http://organofcorti.blogspot.com. Follow me on Twitter @oocBlog for notification of new posts as soon as I publish.

[organofcorti]

August 10th 2014 Weekly Hashrate Contributor and Network Statistics


Welcome, miners.

Changelog:

    * Ghash.IO hashrate per user added.


Errors:

    * BitMinter.com's orphaned block rate was previously incorrectly calculated. This has now been fixed.


Notifications:

    Nil.


0. Ghash.IO and transparency
Lately I have been receiving a wealth of new data from GHash.IO, which I understand they plan to make public. Included in this data is the "hashrate per miner" data which is so important for helping GHash.IO prove the hashrate of their public pool, as well as help researchers understand the health of the network better.

Unfortunately I'm totally under the weather at the moment (that's two flus in three months, for those counting) So I'm not going to start posting anything cool and new tonight, but I'll be able to produce some more interesting weekly charts soon.


1. BitMinter.com orphaned blocks
Previously I had been including "stale" blocks (blocks that are solved after different block at the same blockheight has been accepted by the majority of the network) with orphaned blocks (blocks which arrive before a different block at the same blockheight has been accepted by the majority of the network, but lose an 'orphan race' later). This problem has now been fixed and the density chart now correct.

2. Polmine.pl and hashrate per user.
A month or so ago Polmine.pl changed the "hashrate per user" list to read Ghps instead of Mhps. I realised that today, and fixed the data.

Explanation of the tables and charts.

Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are from either coinbase signatures, known generation addresses or claimed by a particular pool block history. Includes non-Pool hashrate contributors. Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table.

"Unknown" is not an entity, but simply the group of blocks to which I cannot give attribution using the methods given above.





Table 2: Pool reported block history statistics.  This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round.

    A much more accurate estimate of the hashrate, confidence intervals are unnecessary.
    Orphan races lost, and percentage of  solved blocks that were not added to the blockchain.
    "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty,  or (equivalently) accepted shares / expected shares.
    CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks.
    Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one billion Difficulty 1 shares (or one thousand difficulty megashares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block.

Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck calculations cannot be calculated but orphaned blocks can. Pools such as "Discus Fish" that don't have a public pool interface cannot be included.





Figure 3: Percentage of blocks solved each week for the current top ten contributors.

Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data.



You can view all previous charts at http://organofcorti.blogspot.com.au/search/label/weeklypoolstatistics and other posts and fun things at http://organofcorti.blogspot.com. Follow me on Twitter @oocBlog for notification of new posts as soon as I publish.

[eleuthria]

1. BitMinter.com orphaned blocks
Previously I had been including "stale" blocks (blocks that are solved after different block at the same blockheight has been accepted by the majority of the network) with orphaned blocks (blocks which arrive before a different block at the same blockheight has been accepted by the majority of the network, but lose an 'orphan race' later). This problem has now been fixed and the density chart now correct.

Why should those be separated?  AFAIK, BitMinter it the only one that even attempts to differentiate between the two, but they both mean the same thing:  The pool wasted work on a block that was not accepted (thus orphaned) by the network.

[DrHaribo]

Why should those be separated?  AFAIK, BitMinter it the only one that even attempts to differentiate between the two, but they both mean the same thing:  The pool wasted work on a block that was not accepted (thus orphaned) by the network.

I have the impression that most pools just throw away stale work.

If you get a block solution for the old block height after a block change, do you list that as an orphaned block?

[organofcorti]

August 17th 2014 Weekly Hashrate Contributor and Network Statistics


Welcome, miners.


Changelog:

    Made figure 3 a bit prettier and more smooth.

Errors:

    Nil.

Notifications:

    Nil.

0. New charts

With the new GHash.IO data I'll be adding a couple of new plots. This means I'll need to remove a few plots to make room. Leave a comment to let me know which plots you don't think we want or need - preferences would be to remove figures 2 and 4.


Explanation of the tables and charts.

Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are from either coinbase signatures, known generation addresses or claimed by a particular pool block history. Includes non-Pool hashrate contributors. Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table.

"Unknown" is not an entity, but simply the group of blocks to which I cannot give attribution using the methods given above.





Table 2: Pool reported block history statistics.  This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round.

    A much more accurate estimate of the hashrate, confidence intervals are unnecessary.
    Orphan races lost, and percentage of  solved blocks that were not added to the blockchain.
    "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty,  or (equivalently) accepted shares / expected shares.
    CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks.
    Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one billion Difficulty 1 shares (or one thousand difficulty megashares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block.

Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck calculations cannot be calculated but orphaned blocks can. Pools such as "Discus Fish" that don't have a public pool interface cannot be included.





Figure 3: Percentage of blocks solved each week for the current top ten contributors.

Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data.



You can view all previous charts at http://organofcorti.blogspot.com.au/search/label/weeklypoolstatistics and other posts and fun things at http://organofcorti.blogspot.com. Follow me on Twitter @oocBlog for notification of new posts as soon as I publish.

[windpath]

Why not include p2pool estimated hash rate? We have seen a huge jump in the past month, consistently over 2PH/s now.

Also we have had some awesome luck lately, 9 blocks in the last 48 hours (about 4 expected)....

[organofcorti]

Why not include p2pool estimated hash rate? We have seen a huge jump in the past month, consistently over 2PH/s now.

Also we have had some awesome luck lately, 9 blocks in the last 48 hours (about 4 expected)....

The less accurate hashrate estimate is in the top one chart. I can't do more (luck or hashrate) until I have a reliable API for diff-1 equivalent shares per round, which p2pool.info no longer includes.

[organofcorti]

August 24th 2014 Weekly Hashrate Contributor and Network Statistics

Welcome, miners.


Changelog:

    Added monthly and weekly changes in number of solved blocks to the first table. Thanks for the suggestion, Ryan.

Errors:

    Based on the generation address, I'm getting new "IceDrill" blocks, but there's now also  'hashmine.io" in their tx coinbase. Anyone know what's going on here? Are the IceDrill guys using their old setup to run a pool?

Notifications:

    Nil.

0. Charts for removal

Based on feedback, I'll be removing chart 4, and replacing it with a couple of others that I hope I'll get to introduce this week.



Explanation of the tables and charts.

Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are from either coinbase signatures, known generation addresses or claimed by a particular pool block history. Includes non-Pool hashrate contributors. Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table.

"Unknown" is not an entity, but simply the group of blocks to which I cannot give attribution using the methods given above.





Table 2: Pool reported block history statistics.  This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round.

    A much more accurate estimate of the hashrate, confidence intervals are unnecessary.
    Orphan races lost, and percentage of  solved blocks that were not added to the blockchain.
    "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty,  or (equivalently) accepted shares / expected shares.
    CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks.
    Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one billion Difficulty 1 shares (or one thousand difficulty megashares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block.

Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck calculations cannot be calculated but orphaned blocks can. Pools such as "Discus Fish" that don't have a public pool interface cannot be included.





Figure 3: Percentage of blocks solved each week for the current top ten contributors.

Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data.



You can view all previous charts at http://organofcorti.blogspot.com.au/search/label/weeklypoolstatistics and other posts and fun things at http://organofcorti.blogspot.com. Follow me on Twitter @oocBlog for notification of new posts as soon as I publish.

[organofcorti]

August 31st 2014 Weekly Hashrate Contributor and Network Statistics



Welcome, miners.

Changelog:

    Nil.


Errors:

    Looks like the Discus Fish data hasn't been updated since 25th August. I've mentioned this on their btctalk thread.
    Need to update IceDrill blocks to Hashmine.IO.


Notifications:

    Nil.


0. Discus Fish now number one pool
This week Discus Fish overtook GHash.IO as the top block solving bitcoin mining pool. GHash.IO recently became more transparent, allowing access to much of their data - and now Discus Fish needs to step up and provide the same level of transaparency and also a plan to prevent themselves from accidentally fiftyone-percenting the network.

1. New player
So how did GHash.IO lose the number one spot so suddently? Ghash.IO lost 10 Phps on the 23rd August, and on the same day 1Nd99aNgYWpKkqcqSMgWtdtVDadewAS5F7 starts mining, at about 10Phps. It'll be interesting to see where those coins end up.

2. Since chart 4 was so handy this week, probably wont remove it after all.


Explanation of the tables and charts.

Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are from either coinbase signatures, known generation addresses or claimed by a particular pool block history. Includes non-Pool hashrate contributors. Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table.

"Unknown" is not an entity, but simply the group of blocks to which I cannot give attribution using the methods given above.





Table 2: Pool reported block history statistics.  This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round.

    A much more accurate estimate of the hashrate, confidence intervals are unnecessary.
    Orphan races lost, and percentage of  solved blocks that were not added to the blockchain.
    "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty,  or (equivalently) accepted shares / expected shares.
    CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks.
    Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one billion Difficulty 1 shares (or one thousand difficulty megashares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block.

Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck calculations cannot be calculated but orphaned blocks can. Pools such as "Discus Fish" that don't have a public pool interface cannot be included.





Figure 3: Percentage of blocks solved each week for the current top ten contributors.

Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data.

[organofcorti]

September 7th 2014 Weekly Hashrate Contributor and Network Statistics



Welcome, miners.

Changelog:

    Hashmine.io added.
    Bitfury addresses updated.


Errors:

    Apparently Discus Fish update their data once per week, in the mid week. Until they update more regularly, their data in the second table , and for figure 4, 5 and 7 will only be based on that subset.


Notifications:

    Nil.


0. New player == old player.
It seems that the address I was uncertain about last week belongs to Bitfury. This bring their proportion of the network up to 12%. This might seem high for a private enterprise, however previously KNC Miner had a maximum network percentage of 13.5% and ASICMiner 21.4%.

1. Discus Fish and GHash.io battle royale.
GHash.io and Discus Fish now have similar proportions of the network, which is the sort of stability I like. If three pools could be in the top position, I'd be happier still.



Explanation of the tables and charts.

Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are from either coinbase signatures, known generation addresses or claimed by a particular pool block history. Includes non-Pool hashrate contributors. Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table.

"Unknown" is not an entity, but simply the group of blocks to which I cannot give attribution using the methods given above.





Table 2: Pool reported block history statistics.  This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round.

    A much more accurate estimate of the hashrate, confidence intervals are unnecessary.
    Orphan races lost, and percentage of  solved blocks that were not added to the blockchain.
    "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty,  or (equivalently) accepted shares / expected shares.
    CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks.
    Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one billion Difficulty 1 shares (or one thousand difficulty megashares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block.

Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck calculations cannot be calculated but orphaned blocks can. Pools such as "Discus Fish" that don't have a public pool interface cannot be included.




Figure 3: Percentage of blocks solved each week for the current top ten contributors.

Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data.

[organofcorti]

September 14th 2014 Weekly Hashrate Contributor and Network Statistics

Welcome, miners.


Changelog:

    Nil

Errors:

    Discus Fish still seem to update their data irregularly. Until they update more regularly, their data in the second table , and for figure 4, 5 and 7 will only be based on that subset.

Notifications:

    Apologies for being late - I had some kind of cloud backup malfunction which also wiped my data - I'm very glad I also had local backup.

0. Another new / old player?

1GcF7j3YH8Qs8hvNEe7zbrQZftMU6sRLfu has been solving a lot of blocks lately. Blocktrail.com  thinks that's a Bitfury address, and I'll have to contact them to find out how that attribution is determined. If true it would take Bitfury up to 15% percent of the network.

1. Discus Fish and GHash.io battle royale part 2.

Still no clear winner, although GHash.io has had a reducing proportion of the network for a the last month.


Explanation of the tables and charts.

Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are from either coinbase signatures, known generation addresses or claimed by a particular pool block history. Includes non-Pool hashrate contributors. Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table.

"Unknown" is not an entity, but simply the group of blocks to which I cannot give attribution using the methods given above.





Table 2: Pool reported block history statistics.  This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round.

    A much more accurate estimate of the hashrate, confidence intervals are unnecessary.
    Orphan races lost, and percentage of  solved blocks that were not added to the blockchain.
    "Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty,  or (equivalently) accepted shares / expected shares.
    CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks.
    Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one billion Difficulty 1 shares (or one thousand difficulty megashares, etc), since it doesn't take into account the reward method or fees charged. Rather, it should be considered as a "luck" index that also incorporates the number of orphaned blocks and the current reward per block.

Since BTC Guild doesn't report shares per block but does report transaction hashes for all blocks, luck calculations cannot be calculated but orphaned blocks can. Pools such as "Discus Fish" that don't have a public pool interface cannot be included.




Figure 3: Percentage of blocks solved each week for the current top ten contributors.

Data is calculated from the number of blocks each contributor added to the blockchain during the week. The points are the actual data; the lines are exponentiated smoothing splines of the log of the data.



You can view all previous charts at http://organofcorti.blogspot.com.au/search/label/weeklypoolstatistics and other posts and fun things at http://organofcorti.blogspot.com. Follow me on Twitter @oocBlog for notification of new posts as soon as I publish.