Topic: Weekly pool and network statistics - page 7. (Read 91451 times)

October 16th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts

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:

    Slush dataset fixed (due to recent update) and GHash.IO hashrate plot fixed.

0. No time to chat this week

I had some family time this week, so sorry about the post being so late.

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.

October 6th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts

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:

    Nil.

0. Smallest number of weekly blocks since the first ASIC started mining
This week only 1013 blocks were solved, only more than the 1008 per week that the system tries to attain. The last time the network solved less than this was the week of 27th January 2013. This could be due to the recent crash in the BTCUSD price, but this slow down has been occurring  all year so perhaps the price crash has only accelerated that process.

1. Discus Fish and GHash.io battle royale part 5:
Discus Fish wins this round.

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.

Glad you all find it useful. The posts should also be less tardy now that I've moved everything off to a newer and more reliable computer.

+1 this is 'required reading' for miners.

Thanks for continuing to update this post, great source of data...

September 28th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts


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:
Nil.

0. Private mining companies now account for 36% of the network.
I noticed that of the top seven places this week, one was for the unknowns, three for pools and three for known private companies. In all this accounts for 36% of the network. Pools are generally open about the blocks they've solved, and I would like to see companies like Megabigpower to follow the lead of Cointerra and sign all their blocks, not just some of them. Providing a list of solved blocks would be a nice step, too.

It's not a perfect system and people who care about the network's health will need to be vigilant and check that none of the "unknowns" can be attributable to a known mining company/pool, but as mining continues to centralise reducing the proportion of unknown blocks will become even more important to the network's health. Ideally, I would like to see it remain between 2% and 4% - enough for solominers to keep an anonymous piece of the action but not enough to allow any large known company to fifty-one percent the network (that's right, "fifty-one percent" is a verb now, just waiting for it to get into the Oxford English Dictionary"), or to significantly improve their "selfish mining" capacity.


1. Discus Fish and GHash.io battle royale part 4.
... and GHash.io gets the crown back.

2. Network contracted this week
The network hashrate is lower than it was last week and is actually the lowest (1078 blocks this week) it hash been since late July (1038 weekly blocks). Will we see a reduction in the network mining difficulty? The short answer is "no". The somewhat longer answer is "there will be no significant continued reduction in the network mining difficulty in the short term, even if the price halves" (I accept no responsibility for financial loss due to use of this information).

3. Got the new machine set up
I can hear it in the background, purring away quietly, not that screaming death rattle that the macbook used to have when I asked it to do anything more than just sit there and look pretty. Hopefully the money I spent on new machine will be money well spent.

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.

September 21st 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts



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:

    Nil.


0. Who is 1GcF7j3YH8Qs8hvNEe7zbrQZftMU6sRLfu?
Last week, I'd hoped that Blocktrail.com had determined attribution for the generation address
1GcF7j3YH8Qs8hvNEe7zbrQZftMU6sRLfu, but unfortunately after another look they decided that it probably wasn't who they thought it was/ Good try guys, better luck next time.

1. Discus Fish and GHash.io battle royale part3.
I'm giving the crown to Discus Fish for now.


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.

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.

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.

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.

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.

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.

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)....

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.

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?

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.

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.

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.

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?

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.