Topic: Weekly pool and network statistics - page 6. (Read 91451 times)

No that thread's name is incorrect.
It's still just a centralised modified standalone p2pool used as a normal pool, not as a peer to peer pool (and not connected to p2pool)

ASICMiner runs AntPool?

They run AntPool, and also talked about joining P2Pool to promote decentralization (https://bitcointalksearch.org/topic/bitmain-announces-antpool-855548) with some of their hashrate, although we have not seen anything yet...

They're getting at least some of their income from BTC Guild, eg:
https://blockchain.info/tx/3cdb5647417fa1fc42cbf545491b7663382c2c839e93e80bc34ca5b8d91d4dfd

I couldn't find any significant income from other pools.

I think it's possible.
1) Bitmain announced new batches in the first weeks of Bitmain - the same time as hashrate increasing
2) They change miners in their datacenter from S4->S5. Of course they are interested in testing miners before changing.
But now we can see even hashrate decreasing with current BTC price, non-effective miners will off.

Is AM's own hashrate in Discus? I think we will see an increasing of AM's hashrate in March, shareholders wrote about it.

Ha! Thanks. Just lacking time lately.


Interesting. So you'd assume that once the current batch is sold it will be at least that size?

As advertising 

January 11th 2015 Network Statistics
http://organofcorti.blogspot.com/2015/01/january-11th-2014-network-statistics.html

January 11th 2015 Mining Pool Statistics
http://organofcorti.blogspot.com/2015/01/january-11th-2015-mining-pool-statistics.html

January 11th 2015 Block Maker Statistics
http://organofcorti.blogspot.ru/

"Massive increase in hashrate around the new year?" - Likely Bitmain S5 tested new hardware

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

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

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

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

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

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

Np. Thanks for providing p2pool hashrate data

Fine by me Thanks for the continued updates!

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

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


December 7th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts

Welcome, miners.


Changelog:

    Nil.

Errors:

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

Notifications:

    Nil.

0. No more Discus Fish pool stats for a while

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

1. Network continues to contract.

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


Explanation of the tables and charts.

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

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





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

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

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




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

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



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

November 16th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts



Welcome, miners.

Changelog:
Nil.

Errors:
Discus Fish still seem to update their data irregularly. Until they update more regularly, their data in the second table , and for figure 4, 5 and 7 will only be based on that subset.

Notifications:
Nil.

0. I've been busy, sorry!

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

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


Explanation of the tables and charts.

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

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





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

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

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




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

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



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

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

Organofcorti, you just rock!

November 2nd 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts

Welcome, miners.

Changelog:

    Nil.


Errors:

    Discus Fish still seem to update their data irregularly. Until they update more regularly, their data in the second table , and for figure 4, 5 and 7 will only be based on that subset.


Notifications:

    Nil.


0. Eleuthria calls it a day.
Yesterday, BTC Guild's operator Eleuthria announced that he would be leaving BTC Guild hopefully selling the operation, otherwise closing it. Eleuthria has been a vocal miner advocate and has spent a great deal of time helping new miners understand what they've gotten themselves into.

The community will be much less interesting - and fun - without him. El, we hope you stick around, even if you're not running a mine any more.



Explanation of the tables and charts.

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

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





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

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

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




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

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



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

October 26th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts

Welcome, miners.

Changelog:
Nil.

Errors:
Discus Fish still seem to update their data irregularly. Until they update more regularly, their data in the second table , and for figure 4, 5 and 7 will only be based on that subset.

Notifications:
Nil.

0. Block propagation latency and sand size.
I don't have anything interesting to write about pools or the network this week. For the last couple of weeks I've been spending all my free time investigating block propagation times provided by coinometrics.com using their network monitoring tools.

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

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

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



Explanation of the tables and charts.

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

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





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

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

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




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

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



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

October 19th 2014 Weekly Hashrate Contributor and Network Statistics

Other Weekly Hashrate Contributor and Network Statistics posts


Welcome, miners.

Changelog:

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


Errors:

    Discus Fish still seem to update their data irregularly. Until they update more regularly, their data in the second table , and for figure 4, 5 and 7 will only be based on that subset.


Notifications:

    Nil.


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

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

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


Explanation of the tables and charts.

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

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





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

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

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




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

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



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