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

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

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

July 20th 2014 Weekly Hashrate Contributor and Network Statistics

Other weekly pool and network statistics posts

Welcome, miners.


Changelog:

    Nil.

Errors:

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

Notifications:

    Nil.

0. GHash.IO hit 39.99% this week?

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



Explanation of the tables and charts.

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

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





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

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

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





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

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



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

Ah, understood. Thank you.

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

Sweet! Thanks for that.

1. I assume "shares" is total submitted shares and "difficulty" is ?
2. Any chance of historical data?

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

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

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

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

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 

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.

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.

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.

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?

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.

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.

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.

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.

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

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

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