Weekly pool and network statistics

[organofcorti]

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.

[organofcorti]

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.

[windpath]

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

[DevonMiner]

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

+1 this is 'required reading' for miners.

[organofcorti]

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

+1 this is 'required reading' for miners.

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.

[organofcorti]

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.

[organofcorti]

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.

[organofcorti]

October 19th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts


Welcome, miners.

Changelog:

    Added: "Poolz 4 you", new generation address for Bitfury, and "Bitfinex pool".


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. Desire for transparency increasing?
Over the last two weeks, "Poolz 4 you" (a relatively new private mining pool) emailed me to tell me their generation address, and Bitfury also emailed me to tell me their new generation address . This is without any encouragement from me.

I hope this means that more block solvers will come forward and that we can reduce the "Unknowns" to less than five percent of the network.

1. Bitfinex pool
After looking at this page I realised I could find the generation addresses associated with these blocks and I have included these generation addresses as "Bitfinex pool". I understand that Bitfinex probably only owns a small portion of the pool, but until someone tells me what the pool is actually called,  "Bitfinex pool" will have to do.


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]

October 26th 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. Block propagation latency and sand size.
I don't have anything interesting to write about pools or the network this week. For the last couple of weeks I've been spending all my free time investigating block propagation times provided by coinometrics.com using their network monitoring tools.

I've found that block propagation latency (time since a block was first reported by a peer to a monitor until reported by some other arbitrary peer) is distributed in much the same way as the size of grains of sand, which is fascinating. It implies that block propagation latency distribution is a mixture of many differently distributed (heterogeneous) normal random variables.

The tricky part has been describing the relationship between block propagation latency and block size. There is a clear relationship between the block latency distribution and block size, but there are four parameters that describe the block latency probability distribution, and three of them change as block size changes - attempted to describe the relationship is what has taken so much of my time for the last two weeks.

I think I'm almost done now and I hope to post something soon so I can get out of this rabbit hole and start answering all your emails.



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]

November 2nd 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. Eleuthria calls it a day.
Yesterday, BTC Guild's operator Eleuthria announced that he would be leaving BTC Guild hopefully selling the operation, otherwise closing it. Eleuthria has been a vocal miner advocate and has spent a great deal of time helping new miners understand what they've gotten themselves into.

The community will be much less interesting - and fun - without him. El, we hope you stick around, even if you're not running a mine any 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.

[tzortz]

Organofcorti, you just rock!

[organofcorti]

Organofcorti, you just rock!

Well, thanks! And you've just reminded me that I didn't copy this weeks stats to the forum. Sorry!

[organofcorti]

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

0. I've been busy, sorry!

I've been looking at the cyclic nature of bitcoin transaction rates lately which was fun but left no time for much else. I will note that Eligius continued to lose a large amount of network share this week.

I've also been busy fixing some scripts which failed too gracefully when pools changed URLs or HTML table formats.


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]

This should help miners get a better idea of the hashrates at for pools at which they might want to mine. I'll be updating this weekly here, and also in the thread so there's a history. If you'd like anything else, let me know.

If your pool isn't here and you'd like it to be, PM me with a link to a block history with round lengths and either solve times to the nearest second or a timestamp.


December 7th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts

Welcome, miners.


Changelog:

    Nil.

Errors:

    Discus Fish's stats page has now become too hard to parse reliably, so pools stats cannot be reported until a more reliable API is made available. Or even just proper HTML tags. Is a HTML table to much to expect? Sheesh.

Notifications:

    Nil.

0. No more Discus Fish pool stats for a while

I wrested with the changes to the Discus Fish pool stats page. Unfortunately, I haven't been able to find a reliable way to parse it, that won't fall over if they decide to change the layout of their page again. An API or a HTML table would be nice.

1. Network continues to contract.

Only 995 blocks solved this week. Another week like this and difficulty will drop again.


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]

1. Network continues to contract.

Only 995 blocks solved this week. Another week like this and difficulty will drop again.

Fine by me Thanks for the continued updates!

[organofcorti]

1. Network continues to contract.

Only 995 blocks solved this week. Another week like this and difficulty will drop again.

Fine by me Thanks for the continued updates!

Np. Thanks for providing p2pool hashrate data

[Sine(X)]

http://organofcorti.blogspot.ru/2014/12/december-14th-2014-bitcoin-mining-pool.html

Hi Organofcorti, will we see in a future your traditional table with Hashrate contributor statistics sourced from the blockchain?

[organofcorti]

http://organofcorti.blogspot.ru/2014/12/december-14th-2014-bitcoin-mining-pool.html

Hi Organofcorti, will we see in a future your traditional table with Hashrate contributor statistics sourced from the blockchain?

Yes, that's coming back soon. I'm just splitting the post into two posts - one of pool data, one of blockchain data.

[Sine(X)]

http://organofcorti.blogspot.ru/2014/12/december-14th-2014-bitcoin-mining-pool.html

Hi Organofcorti, will we see in a future your traditional table with Hashrate contributor statistics sourced from the blockchain?

Yes, that's coming back soon. I'm just splitting the post into two posts - one of pool data, one of blockchain data.

Thank you!
What happened with AntPool? They couldn't sell S4 and began mining for self?

[organofcorti]

http://organofcorti.blogspot.ru/2014/12/december-14th-2014-bitcoin-mining-pool.html

Hi Organofcorti, will we see in a future your traditional table with Hashrate contributor statistics sourced from the blockchain?

Yes, that's coming back soon. I'm just splitting the post into two posts - one of pool data, one of blockchain data.

Thank you!
What happened with AntPool? They couldn't sell S4 and began mining for self?

They've been mining since the start of the year, and it's been open pool for a while now:

https://www.bitmaintech.com/getBitMainNews.htm