Weekly pool and network statistics

[Angela8488]

Thank you for your great work, the form that you provide is really very useful.

[organofcorti]

May 18th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts


Welcome, miners.


Changelog:

    Nil.

Errors:

    Nil.

Notifications:

    Nil.


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.

[Peter882]

organofcorti, any special reason why you no longer post the reports here on bitcointalk?

Anyway, thanks for the reports on your blog.

[organofcorti]

organofcorti, any special reason why you no longer post the reports here on bitcointalk?

Anyway, thanks for the reports on your blog.

Um, I keep forgetting? Although I could have sworn I cross posted the last one. Weird. I'll do it now.

EDIT: I've been posting them to the front page , but in the rest of the thread! Silly me.

[organofcorti]

June 1st 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts


Other weekly pool and network statistics posts

Welcome, miners.


Changelog:

    Nil.

Errors:

    P2Pool hashrate per user statistics are unavailable this week (and were unavailable last week too).

Notifications:

    Nil.

0. Network increase continues to slow.

The network solved only 1079 blocks this week, the lowest since January 27th 2013 - that's right, the lowest number of blocks solved in one week since the start of the Bitcoin ASIC era (although April 13th 2014 and May 5th 2013 come close). It is possible that the long await ASIC plateau approaches?

1. GHash.IO continues to grow.

GHash.IO had some problems with the miner's side of the pool for the last couple of days which saw some of their capacity moved to backup pools. However, this only accounted for a small portion of their overall hashrate, and they continue to grow. In fact, GHash.IO grew by more than 18% in just the last week, whereas the network only grew by just over 6%.

So GHash.IO: please allow me access to your miner hashrate data. It would put my mind at ease - and everyone else's - that you're not solving the majority of these blocks using your own devices.



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]

June 8th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts

Welcome, miners.


Changelog:

    Nil.

Errors:

    No P2Pool statistics available, the p2pool.info API doesn't seem to be working. I aim to detect p2pool's blocks without help from the site, but not tonight.
    The "Unknown" proportion will be about a percent too high until I can get this fixed.
    Even if I can get an alternative method to assign blocks to p2pool, I won't be able to report on the pool's luck until p2pool's API is working again.
    As usual, Polmine's data is anomalous. I guess that means it's not anomalous? We'll it's usual for Polmine, but extremely unusual compared to what one would expect. I still don't entirely trust their data.

Notifications:

    Nil.

0. GHash.IO continues to grow ... and grow.

I did mention this last week, but this week there have been a few kerfuffles about GHash.IO. The weekly average is 37%, so unless they do something to reduce their rate of increase, I think they'll hit 40% within two weeks.


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]

June 15th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts

Other weekly pool and network statistics posts

Welcome, miners.


Changelog:

    P2Pool block statistics have been fixed.

Errors:

    P2Pool user statistics still unavailable.

Notifications:

    Apologies for the delay - I broke my local blockchain database and had to rebuild it over the weekend.

0. So, how about that GHash.IO, huh?

After passing 40 Phps on the 7th of June, everyone expected them to pass the 50% of the network mark this week. I think they came very close on the 13th, but they seemed to lose some miners and by Sunday they were back under 40 Thps, and an average of 40% of the network for the week. Given  that the drop in the bitcoin - USD exchange rate seems to be at least partially attributable to GHash.IO coming close to fiftypercenting the network, I'll be watching this closely. Everyone knows that if anyone takes 51% of the network, the world as we know it will come to an end. Forty

1. So, how about that GHash.IO, huh, part 2.

So, how about those 19 GHash..O orphaned blocks in one week, huh More interesting though is the five orphans in a row that occurred toward the end of the week. Why so many orphans, and why so many in a row? It might be coincidence, but then they also managed one eight block-in-a-row run, a seven block-in-a-row run, a couple of five and six block-in-a-row runs and ten four block block-in-a-row runs. A run of orphans and lots of runs of solved blocks? That's starting to raise some red flags for me at least.



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.

[DrG]

I too have noticed those orphan rates shoot up at GHash.IO along with the block runs.  Something is rotten in Denmark.

[GaryL]

Great work, can be seen very carefully, thank you for your work.

[blacksmithtm]

This is great work. The orphans of GHash.IO could be explained by the DDoS attack they were experiencing.

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


June 22nd 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts

Welcome, miners.


Changelog:

    Nil.

Errors:

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

Notifications:

    Nil.

0. What's this spike in unknown?

There was a little bit of a spike in unknowns this week (up to 14%). 1AcAj9p6zJn4xLXdvmdiuPCtY7YkBPTAJo was originally on GHash.IO, but then last Sunday (15th June) it moved off GHash.IO and started solomining. This reduced  GHash.IO's hashrate significantly, and by itself reduced GHash.IO's weekly average percentage of the network by almost 5%. Interestingly, it's also associated with a number of other unknown generation addresses.

There's still no proof that this address is not in some way associted with GHash.IO. Bitcointalk forumite gigavps thought that the address may belong "to bitfury or one of their backers".

If the address is still associated with GHash.IO in some way, then the change in GHash.IO's percentage of the network is cosmetic. Even if this address is in no way associated with them, GHash.IO still has more than 33% of the network, which is 8% more than I'm comfortable with.

1. Blockchain.info upgrades their block attribution method.

The pool hashrate distribution chart at blockchain.info has been upgraded, with help from the public. Good job, fellows! Hopefully you'll keep up the good work (or at least the public will keep up the good work for you).




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.

[zvs]

0. What's this spike in unknown?

There was a little bit of a spike in unknowns this week (up to 14%). 1AcAj9p6zJn4xLXdvmdiuPCtY7YkBPTAJo was originally on GHash.IO, but then last Sunday (15th June) it moved off GHash.IO and started solomining. This reduced  GHash.IO's hashrate significantly, and by itself reduced GHash.IO's weekly average percentage of the network by almost 5%. Interestingly, it's also associated with a number of other unknown generation addresses.

There's still no proof that this address is not in some way associted with GHash.IO. Bitcointalk forumite gigavps thought that the address may belong "to bitfury or one of their backers".

If the address is still associated with GHash.IO in some way, then the change in GHash.IO's percentage of the network is cosmetic. Even if this address is in no way associated with them, GHash.IO still has more than 33% of the network, which is 8% more than I'm comfortable with.

No doubt in my mind that ghash.io has been obfuscating some of their blocks for quite some time.

CEX.io is like Blue Bell ice cream... you know, where they sell all they can and they eat the rest.  It's not rocket science to 'hide' blocks that you mine yourself.  Given how much money they're making, I'm sure they've figured it out themselves or hired someone to do it for them.

[organofcorti]

June 29th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts

Welcome, miners.


Changelog:

    Nil.

Errors:

    P2Pool block statistics are now available but haven't yet been included in the weekly statisstics.
    P2Pool user statistics are still unavailable.

Notifications:

    Nil.

0. Unknowns still high

The "spike" in unknowns last was appears to have been less a "spike" and more a "ramp".  Total unknowns are now at almost 20 Phps, far too large to remain unaccounted for. If I have some time (a rare commodity lately) I'll try to follow some of them and see where they lead.

1. BTC Guild down to 7.3% of the network

Even though GHash.IO is still around 35%, a large portion of the network is in relatively few hands and now with BTC Guild losing almost 6% of the network blocks to other hashers the health of the network is not significantly better than last 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]

July 6th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts

Welcome, miners.


Changelog:

    Nil.

Errors:

    P2Pool block statistics are now available but haven't yet been included in the weekly statisstics.
    P2Pool user statistics are still unavailable.

Notifications:

    Nil.

0. Unknowns still high

The "spike" in unknowns last was appears to have been less a "spike" and more a "ramp".  Total unknowns are now at almost 20 Phps, far too large to remain unaccounted for. If I have some time (a rare commodity lately) I'll try to follow some of them and see where they lead.

1. BTC Guild down to 7.3% of the network

Even though GHash.IO is still around 35%, a large portion of the network is in relatively few hands and now with BTC Guild losing almost 6% of the network blocks to other hashers the health of the network is not significantly better than last 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.

[ALToids]

Why has BTC Guild's orphan rate gone up to nearly 4%?  Is it because their network percentage is going down so they're less likely to decide on who the orphan winner will be?

[eleuthria]

Why has BTC Guild's orphan rate gone up to nearly 4%?  Is it because their network percentage is going down so they're less likely to decide on who the orphan winner will be?

It's because we had a bad week.  Long term average is still under 1%, which is the rule of thumb generally.  When you only have 70ish blocks during a week, each orphan is a big hit.  Looking at it on a larger picture (one visible on the pool stats page), 3 out of the last 200 blocks were orphans, all 3 of which were last week.

[organofcorti]

Why has BTC Guild's orphan rate gone up to nearly 4%?  Is it because their network percentage is going down so they're less likely to decide on who the orphan winner will be?

If you look at the orphans plot on the blog post, you'll get a better idea about the usual number of orphans a pool has. This week BTC Guild had some unusual orphan luck.

[organofcorti]

July 13th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts

Welcome, miners.


Changelog:

    Nil.

Errors:

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

Notifications:

    Nil.

0. 17% Unknown

That's a 5% increase in just one week. I'd really like to know who owns some of the addresses on the "Unknown recurring generation address"list.If anyone knows, please email me.



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.

[ALToids]

I see BTC Guilds orphan rate back to the correct 1% and Ghash.IO is hovering close to 2%.  That is essentially a 1% fee.

Slush made out like a bandit this week 

[organofcorti]

I see BTC Guilds orphan rate back to the correct 1% and Ghash.IO is hovering close to 2%.  That is essentially a 1% fee.

If you go to the blog post, the last plot on the page is orphan rates over time. You might find it interesting.