Topic: Weekly pool and network statistics - page 9. (Read 91284 times)

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.

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.

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.

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, any special reason why you no longer post the reports here on bitcointalk?

Anyway, thanks for the reports on your blog.

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.

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

May 4th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts


Welcome, miners.


Changelog:

    Bitparking changed to MMPool, and the "no Eligius orphans" bug fixed.

Errors:

    Nil.

Notifications:

    Nil.

0. Strange luck.

Even though lots of interesting things have been happening with pools and pool luck lately, I don't have time to comment on them. A good starting point for the interested reader is in this link.



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.

Well spotted! Fixed.

Looks like you have included the old (last week) figure 1 this time.

April 27th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts


Welcome, miners.

Changelog:
"CBT Nuggets" added.

Errors:
Bitparking has changed names to mmpool.org and I still haven't had the time to change over the historical data yet.

Notifications:
Nil.

0. More solominers
"CBT Nuggets" moved from Eligius and started solomining, continuing the trend of large miners leaving pools and solo-mining. I see this as a relatively good thing while the solominers have smallish proportions of the network. It also means that they probably have gonads made from a ferrous alloy.


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.

thank again for the info,

i mining on ghash, and the number of block is going down this week and i read some post saying they not paying some block.
and i like to compare them, 0000 utc to next day 2359 utc time to see it is the same.

and i am look at btcguild their number of block.

thank you organofcorti

http://blockorigin.pfoe.be/blocklist.php is good if it's just pools (and not solo miners) that you're interested in.

thank you!! 

can i check with you all is there a way to see how much block did a pool get per day ?
i know block chain can get the past 24 hour reading. but which i don't really sure about how the reading there work.

thank you
Joe

April 20th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts

Welcome, miners.


Changelog:

    Nil.

Errors:

    Bitparking has changed names to mmpool.org and I still haven't had the time to change over the historical data yet. Still!

Notifications:

    Nil.

0. I'm on 'bitcoin free' holidays

This means that I found some time to surreptitiously post this. Please don't tell my significant other! I'll be back on the case on Tuesday and I hope I'll get Bitparking's name changed over some time after that.


1. Address links changed to coinometrics.com

I do still appreciate all the work done by blockchain.info, however I also like the fact that coinometrics.com aims to be accurate and also explain clearly how they calculate their statistics. The selfish mining monitor is also pretty cool.

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.

It should be mmpool.org instead. 

Yep - sorry about that. I've had some other things that needed attention so I'm a bit behind. Should be posted in the next 24 hours at most, and will include Megabigpower as well.

Love your blog. It is an important contribution to the bitcoin community/ecosystem.

Stats for last week in work?

Thanks, really appreciate your efforts on this. KNC is killing it with other peoples money.