Topic: Weekly pool and network statistics - page 10. (Read 91451 times)
thanks you
April 6th 2014 Weekly Hashrate Contributor and Network Statistics
Other Weekly Hashrate Contributor and Network Statistics posts
Welcome, miners.
Changelog:
IceDrill added.
Errors:
Eligius missing from Figure 7 (data not available).
Bitparking has changed names to mmpool.com. I haven't changed over the the historical data yet, and this week's data was unavailable when the data was being collected.
Notifications:
Nil.
0. Discus Fish and KNCMiner overtake BTCGuild and Eligius.
This really is very big new. Firstly, there is not much transparency when it comes to the new top three entities.
GHash.IO is the most transparent of the three, providing share per round data that is not available for Discus Fish (aka F2Pool) or KNCMiner. However we don't know how much of GHash.IO is owned by the pool, how much is hosted by the pool, and how much is contributed by miners. I'd be much more confident comfortable knowing these details.
I don't have much data at all about F2Pool. I have communicated with the pool owner a couple of times, but pool luck data is not yet available to the public. I also don't know if the pool does any local hosting.
KNC is my largest concern right now. They now have more than 13% of the network, and they haven't made it easy to find out and track their data. If they want people to be less concerned about them having local control over machines that solved nearly one-seventh of the network blocks during the past week, then they need to be a little more open with their data and their plans.
It makes me more than a little uncomfortable that of the top five block solvers, only one is definitely a pure pool (BTCGuild), and only two of the five provide any public information (GHash.IO and BTCGuild).
1. Unknown block solvers, higher again at 12%.
This week, "Unknown" is up another 1%. I'm quite certain that more than half of that belongs to MegaBigPower.com, and another large portion belongs to another entity i have not yet been able to identify. A reader managed to identify 12ej4RU... as IceDrill, a new investor financed hashing entity. I hope to get some time during this week or next to prove that MegaBigPower.com owns certain addresses and be able to include them in next week's statistics.
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.
0. Private vs public hashing.
The number of blocks solved by the network each week hash been slowly reducing, from the 1200 to 1300 blocks per week of previous months to the current 1100 blocks per week. GHash.IO still commands about two sevenths of the network, and since the KNC solomining operation moved out of Eligius (taking ten percent of the network with them) BTCGuild and Eligius have been sharing two sevenths of the network between them. The 500TH mine seems to have moved to BTCGuild, probably due to variance from their low hashrate.
Ghash.IO has an unknown proportion of private hashing; of the remaining five sevenths of the network only two thirds are in the hands of public pools. This level of private hashing is something that has been expected but I didn't really notice it until now. I expect I'll need to start following this.
The number of blocks solved by the network each week hash been slowly reducing, from the 1200 to 1300 blocks per week of previous months to the current 1100 blocks per week. GHash.IO still commands about two sevenths of the network, and since the KNC solomining operation moved out of Eligius (taking ten percent of the network with them) BTCGuild and Eligius have been sharing two sevenths of the network between them. The 500TH mine seems to have moved to BTCGuild, probably due to variance from their low hashrate.
Ghash.IO has an unknown proportion of private hashing; of the remaining five sevenths of the network only two thirds are in the hands of public pools. This level of private hashing is something that has been expected but I didn't really notice it until now. I expect I'll need to start following this.
This is something I've been pointing out recently. The days of "X POOL IS ALMOST 51%" are likely gone, unless the pool has a massive private farm like in the case of ghash.io. When they were ~5500 TH/s, they released a statement where they included a figure of ~45% of their speed was the private farm. Since then, my suspicion is that percentage is higher. Their rate of speed growth in comparison to other pools has been very high recently, considering historically public ASIC distribution affected the top pools fairly evenly.
It's not a surprise really. Almost every manufacturer these days has a very large private farm, and/or partnerships with very large private farms. While in the past they ended up just using pools (like ASICMINER with BTC Guild, and KNCMiner with Eligius), lately they're seeming to increase the size of the private farms and running solo. Still, it's very disappointing to see the concentration of ASICs rapidly approaching the hands of just a few entities. While it's not different than pools in terms of # of people "in control" of the hash power, it's also immune to any kind of public correction.
March 23rd 2014 Weekly Hashrate Contributor and Network Statistics
Other Weekly Hashrate Contributor and Network Statistics posts
Welcome, miners.
Changelog:
Nil
Errors:
Nil known.
Notifications:
Yes, I'll email you back soon.
0. Private vs public hashing.
The number of blocks solved by the network each week hash been slowly reducing, from the 1200 to 1300 blocks per week of previous months to the current 1100 blocks per week. GHash.IO still commands about two sevenths of the network, and since the KNC solomining operation moved out of Eligius (taking ten percent of the network with them) BTCGuild and Eligius have been sharing two sevenths of the network between them. The 500TH mine seems to have moved to BTCGuild, probably due to variance from their low hashrate.
Ghash.IO has an unknown proportion of private hashing; of the remaining five sevenths of the network only two thirds are in the hands of public pools. This level of private hashing is something that has been expected but I didn't really notice it until now. I expect I'll need to start following this.
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.
March 16th 2014 Weekly Hashrate Contributor and Network Statistics
Other Weekly Hashrate Contributor and Network Statistics posts
Welcome, miners.
Changelog:
Nil
Errors:
Nil known.
Notifications:
I'm busy, not just trying to find an excuse for being slack.
0. Unknown generation addresses.
I got a lot of work done on this project during the week, in fact it's all I've done, and is the reason I'm posting this at 4am. An example of the work done on anaysing the bitcoin transaction graph for generated transactions (you might want to open the image in another tab and enlarge it):
Unfortunately I don't have time to explain the graph, although it should be simple enough to follow. Watch out for an in depth post some time this week.
1. Any comments related to actual weekly bitcoin network statistics?
No time this week, sorry.
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.
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.
March 9th 2014 Weekly Hashrate Contributor and Network Statistics
Other Weekly Hashrate Contributor and Network Statistics posts
Welcome, miners.
Changelog:
KNC Miner solo mining identified from generation addresses and have been added to the weekly statistics.
Errors:
Nil known.
Notifications:
Please excuse all puns.
0. KNC solo mining
I found the KNC Mining addresses, which they haven't been trying to hide and have used for quite a while. They debut at ~7.75% of the network. That Swedish datacentre is running hot!
1. GHash.IO loses 30% of its hashrate
This week, GHash.IO loses 30% of its hashrate and 6% of the network. This is one of only three weeks during which GHash.IO have lost such a great deal of the network. The top four pools are now much closer; last week there was more than a twenty percent difference between the top four block solvers, and this week there's only a thirteen percent difference.
2. Unknown generation addresses.
Still working on this, and still very interesting. I hadn't don't much graph theory before now, and it's a bit of a steep learning curve, but very interesting. Some apropos links:
Bitcoin Transaction Graph Analysis
An Analysis of Anonymity in the Bitcoin System (blog)
An Analysis of Anonymity in the Bitcoin System (paper)
Quantitative Analysis of the Full Bitcoin Transaction Graph
Do the rich get richer? An empirical analysis of the Bitcoin transaction network
An Analysis of Anonymity in Bitcoin Using P2P Network Tra ffic
3. Blockchain related recreation: http://bitcoinstrings.com keeps track of all the graffiti in the block chain.For light reading, or inspiration if you're trying to write a poem.
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.
Other Weekly Hashrate Contributor and Network Statistics posts
Welcome, miners.
Changelog:
KNC Miner solo mining identified from generation addresses and have been added to the weekly statistics.
Errors:
Nil known.
Notifications:
Please excuse all puns.
0. KNC solo mining
I found the KNC Mining addresses, which they haven't been trying to hide and have used for quite a while. They debut at ~7.75% of the network. That Swedish datacentre is running hot!
1. GHash.IO loses 30% of its hashrate
This week, GHash.IO loses 30% of its hashrate and 6% of the network. This is one of only three weeks during which GHash.IO have lost such a great deal of the network. The top four pools are now much closer; last week there was more than a twenty percent difference between the top four block solvers, and this week there's only a thirteen percent difference.
2. Unknown generation addresses.
Still working on this, and still very interesting. I hadn't don't much graph theory before now, and it's a bit of a steep learning curve, but very interesting. Some apropos links:
Bitcoin Transaction Graph Analysis
An Analysis of Anonymity in the Bitcoin System (blog)
An Analysis of Anonymity in the Bitcoin System (paper)
Quantitative Analysis of the Full Bitcoin Transaction Graph
Do the rich get richer? An empirical analysis of the Bitcoin transaction network
An Analysis of Anonymity in Bitcoin Using P2P Network Tra ffic
3. Blockchain related recreation: http://bitcoinstrings.com keeps track of all the graffiti in the block chain.For light reading, or inspiration if you're trying to write a poem.
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.
Wow! Ozxoin has done great!
zvs , what will be your next forecast?
I forecast that Deepbit solves a lot of blocks on blockchain.info zvs , what will be your next forecast?
Wow! Ozxoin has done great!
zvs , what will be your next forecast?
zvs , what will be your next forecast?
hoho, i seem to recall saying some time ago that slush, bitminter, and eclipsemc will have the least amt of orphans
and ghash.io will have the most (also how eligius was "funky" and btcguild needed improvement)
either ghash.io has been lucky or they finally fixed things up. can't tell myself since i havent run bitcoind in many months
find it in your PM history!
and ghash.io will have the most (also how eligius was "funky" and btcguild needed improvement)
either ghash.io has been lucky or they finally fixed things up. can't tell myself since i havent run bitcoind in many months
find it in your PM history!
Yes, ghash.io certainly seem to be winning the orphan races that they are in. I don't know if they are having fewer orphan races though.
I'm at work so I can't link to it, but my most recent weekly stats posts have a chart of orphaned block densities kernel smoothed against number of blocks solved. his makes it possible to compare different pools. Have a look if you get time.
hoho, i seem to recall saying some time ago that slush, bitminter, and eclipsemc will have the least amt of orphans
and ghash.io will have the most (also how eligius was "funky" and btcguild needed improvement)
either ghash.io has been lucky or they finally fixed things up. can't tell myself since i havent run bitcoind in many months
find it in your PM history!
and ghash.io will have the most (also how eligius was "funky" and btcguild needed improvement)
either ghash.io has been lucky or they finally fixed things up. can't tell myself since i havent run bitcoind in many months
find it in your PM history!
Yes, ghash.io certainly seem to be winning the orphan races that they are in. I don't know if they are having fewer orphan races though.
hoho, i seem to recall saying some time ago that slush, bitminter, and eclipsemc will have the least amt of orphans
and ghash.io will have the most (also how eligius was "funky" and btcguild needed improvement)
either ghash.io has been lucky or they finally fixed things up. can't tell myself since i havent run bitcoind in many months
find it in your PM history!
and ghash.io will have the most (also how eligius was "funky" and btcguild needed improvement)
either ghash.io has been lucky or they finally fixed things up. can't tell myself since i havent run bitcoind in many months
find it in your PM history!
Yes, ghash.io certainly seem to be winning the orphan races that they are in. I don't know if they are having fewer orphan races though.
hoho, i seem to recall saying some time ago that slush, bitminter, and eclipsemc will have the least amt of orphans
and ghash.io will have the most (also how eligius was "funky" and btcguild needed improvement)
either ghash.io has been lucky or they finally fixed things up. can't tell myself since i havent run bitcoind in many months
find it in your PM history!
and ghash.io will have the most (also how eligius was "funky" and btcguild needed improvement)
either ghash.io has been lucky or they finally fixed things up. can't tell myself since i havent run bitcoind in many months
find it in your PM history!
March 2nd 2014 Weekly Hashrate Contributor and Network Statistics
Other Weekly Hashrate Contributor and Network Statistics posts
Welcome, miners.
Changelog:
AntPool and KoiSystems identified from coinbase signature and generation addresses and have been added to the weekly statistics.
Errors:
Data from Polmine and Ozcoin seem unlikely.
0. KNC goes solo
As I was just about to post this I found out that KNC Mining had left Eligius and gone back to running their own pool. I didn't have time to add them in, but I will for the next post. Does anyone have the generation address used in November when they were first running their own pool?
1. Eligius overtakes BTCGuild
However with KNC gone, I wonder if they'll still be in second place next week?
2. Unknown generation addresses.
I'm still working on this, but haven't had much spare time lately.
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 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.
February 23rd 2014 Weekly Hashrate Contributor and Network Statistics
Other Weekly Hashrate Contributor and Network Statistics posts
Welcome, miners.
Changelog:
NA.
Errors:
Nil
0. Welcome back Ozcoin!
Ozcoin hooks a block this week and returns to the weekly stats for the first time in a while. It'll have been a big payday for Ozcoin miners!
1. Unknown generation addresses.
The unknown part of the network hashrate was 1 to 2 % from July 2013 to the start of this year. Since then, it's increased to about 8% of the network. I don't care if this is all solominers, but it could be that some large hashrate contributor is attempting to hide some of their hashes - which might mean they're approaching 51% of the network.
Most of my time is spent trying to find associations between the unknown generation addresses and known addresses - if you think you know something that might help, please post a comment.
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 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.
February 23rd 2014 Weekly Hashrate Contributor and Network Statistics
Other Weekly Hashrate Contributor and Network Statistics posts
Welcome, miners.
Changelog:
NA.
Errors:
Nil
0. Welcome back Ozcoin!
Ozcoin hooks a block this week and returns to the weekly stats for the first time in a while. It'll have been a big payday for Ozcoin miners!
1. Unknown generation addresses.
The unknown part of the network hashrate was 1 to 2 % from July 2013 to the start of this year. Since then, it's increased to about 8% of the network. I don't care if this is all solominers, but it could be that some large hashrate contributor is attempting to hide some of their hashes - which might mean they're approaching 51% of the network.
Most of my time is spent trying to find associations between the unknown generation addresses and known addresses - if you think you know something that might help, please post a comment.
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.
February 16th 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:
Added Figure 7: Orphaned blocks.
Usual pools missing from results:
I haven't rebuilt this part yet - still TBA.
Errors:
According to my data, Polmine has only had one orphaned block in the last 700. This may be a mistake.
0. Orphaned block chart, for the first time.
This post is a bit late as I had some problems getting the chart and the data right. I'm not going to make any more comments than that tonight, but I do have some interesting things that I need to post and I hope I get time to do that later this week.
Explanation of the tables and charts.
Table 1: Solved block statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week. Block attributions are from either coinbase signatures, known generation addresses or claimed by a particular pool block history. Includes non-Pool hashrate contributors. Note that actual pool hashrates when derived from shares submitted per unit time will be more accurate than the hashrate estimates given in this table.
"Unknown" is not an entity, but simply the group of blocks to which I cannot give attribution using the methods given above.
Table 2: Pool reported block history statistics. This table lists all statistics that can be derived from the number of blocks a hashrate contributor has solved for the past week using all solved blocks - both valid and orphaned - and difficulty 1 shares per round.
A much more accurate estimate of the hashrate, confidence intervals are unnecessary.
Orphan races lost, and percentage of solved blocks that were not added to the blockchain.
"Luck" is the usual difficulty 1 equivalent shares per round / mining difficulty, or (equivalently) accepted shares / expected shares.
CDF: The cumulative density function (CDF) measures the percentage of the time this number accepted shares / expected shares would be less than the calculated value, given the number of valid + invalid blocks.
Bitcoin per Gigashare. This figure is not an indicator of how much a miner should have expected per one million Difficulty 1 shares (or one thousand difficulty 1000 shares, 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 can not 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.
Figure 7: Density of orphaned blocks
This chart shows the density of orphaned blocks per pool, as a function of blocks solved by that pool. The fringe indicates the actual occurences of of the orphaned blocks, and the colour of the line and fringe indicate the approximate date.
Some orphan data may be missing from Polmine. The rest seem to be correct.
As usual, please post comments if there's anything you don't understand, with which you disagree, or just think is wrong.
You can view all of this weeks charts at http://organofcorti.blogspot.com.au/2014/02/february-16th-2014-weekly-hashrate.html
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.
February 9th 2014 Weekly Hashrate Contributor and Network Statistics
Other Weekly Hashrate Contributor and Network Statistics posts
Welcome, miners.
Changelog:
Changed the hashrate scaling for figure 6 to Thps.
Improved the generation address ownership algorithm, resulting in slightly fewer "Unknown" blocks.
Usual pools missing from results:
I haven't rebuilt this part yet - still TBA.
Errors:
I still haven't found any.
0. No orphaned block charts yet
I think I've found the best way to chart orphaned blocks, I just need time to do it. Hopefully I'll find time this week or the next.
1. The network hashrate continues to increase, as do unknown contributors
Another 1226 blocks solved this week, 218 more than expected. Of these, 104 blocks are from unknown contributors. If you turn to table 3, you can see that one of the generation addresses has now been assigned a total of 24 blocks, five in this week alone. Interestingly, none of the block reward has moved from this address yet. It seems there are some new cloud-hashers around. Maybe KNC has gotten their data centre going already?
That's all I have time for this week. Enjoy the chartporn, and see if you can find out to whom some of the richer unknown generation addresses belong.
Explanation of the tables and charts.
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 million Difficulty 1 shares (or one thousand difficulty 1000 shares, 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 can not 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.
Figure 5: Pool "luck" (valid + invalid solved blocks)
The orange dots are the usual accepted shares / expected shares (equivalently, shares per round / network Difficulty). The background colours are accepted shares / expected shares confidence intervals for the number of blocks solved for the week. The greater the number of blocks solved (the higher the percentage of the network) the narrower the bounds.
The "luck" data points should be outside the upper or lower boundaries only rarely. Many data points outside this range indicate unusual and unlikely "luck".
Data only goes back for the last twelve months at most - any more data points than this becomes hard to read, and recent data is most important.
Note that all solved blocks are used, otherwise the data would no longer be Erlang distributed and a CDF could not be calculated.
As usual, please post comments if there's anything you don't understand, with which you disagree, or just think is wrong.
You can view all of this weeks charts at http://organofcorti.blogspot.com.au/2014/02/february-9th-2014-weekly-hashrate.html
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.
Other Weekly Hashrate Contributor and Network Statistics posts
Welcome, miners.
Changelog:
Changed the hashrate scaling for figure 6 to Thps.
Improved the generation address ownership algorithm, resulting in slightly fewer "Unknown" blocks.
Usual pools missing from results:
I haven't rebuilt this part yet - still TBA.
Errors:
I still haven't found any.
0. No orphaned block charts yet
I think I've found the best way to chart orphaned blocks, I just need time to do it. Hopefully I'll find time this week or the next.
1. The network hashrate continues to increase, as do unknown contributors
Another 1226 blocks solved this week, 218 more than expected. Of these, 104 blocks are from unknown contributors. If you turn to table 3, you can see that one of the generation addresses has now been assigned a total of 24 blocks, five in this week alone. Interestingly, none of the block reward has moved from this address yet. It seems there are some new cloud-hashers around. Maybe KNC has gotten their data centre going already?
That's all I have time for this week. Enjoy the chartporn, and see if you can find out to whom some of the richer unknown generation addresses belong.
Explanation of the tables and charts.
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 million Difficulty 1 shares (or one thousand difficulty 1000 shares, 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 can not 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.
Figure 5: Pool "luck" (valid + invalid solved blocks)
The orange dots are the usual accepted shares / expected shares (equivalently, shares per round / network Difficulty). The background colours are accepted shares / expected shares confidence intervals for the number of blocks solved for the week. The greater the number of blocks solved (the higher the percentage of the network) the narrower the bounds.
The "luck" data points should be outside the upper or lower boundaries only rarely. Many data points outside this range indicate unusual and unlikely "luck".
Data only goes back for the last twelve months at most - any more data points than this becomes hard to read, and recent data is most important.
Note that all solved blocks are used, otherwise the data would no longer be Erlang distributed and a CDF could not be calculated.
As usual, please post comments if there's anything you don't understand, with which you disagree, or just think is wrong.
You can view all of this weeks charts at http://organofcorti.blogspot.com.au/2014/02/february-9th-2014-weekly-hashrate.html
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.
February 2nd 2014 Weekly Hashrate Contributor and Network Statistics
Other Weekly Hashrate Contributor and Network Statistics posts
Welcome, miners.
Changelog:
Changed the smoothing method for figure 3.
Added new table and chart explanations, placed immediately prior to the table / chart.
Usual pools missing from results:
I haven't rebuilt this part yet - still TBA.
Errors:
I haven't found any - please tell me if you find something.
0. Still more work to go.
I forgot to write a simple script checking for hashrate contributors that have contributed to the network recently but not for the current week, that is "Usual pools missing from results". Simple enough to do, No excuses except that I ran out of time.
I'm also unsure about how to proceed with the "orphaned blocks" chart. Initially I wanted to do a cumulative or moving average of the percentage of orphaned blocks, but from experience I know that readers see non-existent trends in these sort of plots (moving average charts do not consist of independent data and so cannot show trends) and all sorts of confusion results. Instead I've decided to do a kernel smoothed density plot. I haven't yet decided whether to plot the data separately or on one chart, or stacked or something else. Hopefully I'll come up with something soon.
Once the data reporting is just as I want it, I'll be able to start commenting on the data 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 million Difficulty 1 shares (or one thousand difficulty 1000 shares, 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 can not 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.
As usual, please post comments if there's anything you don't understand, with which you disagree, or just think is wrong.
You can view this weeks charts at http://organofcorti.blogspot.com/2014/02/february-2nd-2014-weekly-hashrate.html
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.
Other Weekly Hashrate Contributor and Network Statistics posts
Welcome, miners.
Changelog:
Changed the smoothing method for figure 3.
Added new table and chart explanations, placed immediately prior to the table / chart.
Usual pools missing from results:
I haven't rebuilt this part yet - still TBA.
Errors:
I haven't found any - please tell me if you find something.
0. Still more work to go.
I forgot to write a simple script checking for hashrate contributors that have contributed to the network recently but not for the current week, that is "Usual pools missing from results". Simple enough to do, No excuses except that I ran out of time.
I'm also unsure about how to proceed with the "orphaned blocks" chart. Initially I wanted to do a cumulative or moving average of the percentage of orphaned blocks, but from experience I know that readers see non-existent trends in these sort of plots (moving average charts do not consist of independent data and so cannot show trends) and all sorts of confusion results. Instead I've decided to do a kernel smoothed density plot. I haven't yet decided whether to plot the data separately or on one chart, or stacked or something else. Hopefully I'll come up with something soon.
Once the data reporting is just as I want it, I'll be able to start commenting on the data 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 million Difficulty 1 shares (or one thousand difficulty 1000 shares, 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 can not 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.
As usual, please post comments if there's anything you don't understand, with which you disagree, or just think is wrong.
You can view this weeks charts at http://organofcorti.blogspot.com/2014/02/february-2nd-2014-weekly-hashrate.html
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.
Thanks, iongchun. Were you mining long enough to get a feel for pool reliability?
I just tried it for nearly 2 days with 33Gh/s,
20min miner hash rate floats between 25 to 38Ghz/s, I guess it is due to high difficulty (256).
Reject rate is about 1.2%, and pool statistics from bfgminer:
Code:
Unable to get work from server occasions: 2
They replied to my email almost straight away, which was nice. No complete block history API just yet, but lots of new and interesting information!
Look forward to your report for next week
mining, statistics very good gains going well're always the case continued
Google translate did a poor job there. Would you mind posting again?
mining, statistics very good gains going well're always the case continued
Jump to: