Weekly pool and network statistics

[organofcorti]

Discus Fish is the pool operator’s nickname, his/her pool is f2pool.com
Pity that no much public data can be found there for unregistered user.

Thanks! I'll have to update the pool name. Do you mine there?

Of course not, you can read from my signature

Perhaps I should have written "Have you mined there?"

From what I read on f2pool’s website, it is a PPS pool with 4% fee (24 BTC paid per block),
payout is made once a day for miners with balance of 0.0005 BTC or more.
It seems only Stratum is supported as mining protocol.
I guess tx fee is kept by the pool.

Google translate tells me similar. I'll try their support address, but I'm not sure they'll respond to an english email out of the blue.

[wknight]

Always love these reports!

[Sonny]

I'll try their support address, but I'm not sure they'll respond to an english email out of the blue.

Discus Fish is a Chinese pool that was started by Chinese student bitcoin enthusiasts. I don't know much more about it. There's a bit of information about the relationship between Discus Fish and "For Pierce and Paul" here: http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/12/29

Judging from that chat log, I guess they will welcome you if you show yourself as organofcorti.

Code:

20:07 wangchun if you read organofcorti's weekly report, we are "Discus Fish" (pool) and "For Pierce and Paul" (solo) 

[iongchun]

Of course not, you can read from my signature

Perhaps I should have written "Have you mined there?"

From what I read on f2pool’s website, it is a PPS pool with 4% fee (24 BTC paid per block),
payout is made once a day for miners with balance of 0.0005 BTC or more.
It seems only Stratum is supported as mining protocol.
I guess tx fee is kept by the pool.

Google translate tells me similar. I'll try their support address, but I'm not sure they'll respond to an english email out of the blue.

Hope you have progress with it, organofcorti.
I tried the pool for some time, and observe the following:
1. The pool always gives out works of difficulty 256, no matter with 333Mh/s or 33Gh/s hardware;
2. No pool statistics is available even for a registered user. I can only see user hashrate graph, miner hashrate, balance, etc.;
3. Payout is round to 0.0001, the remaining is kept in user balance.


Regards,
iongchun

[organofcorti]

you have progress with it, organofcorti.
I tried the pool for some time, and observe the following:
1. The pool always gives out works of difficulty 256, no matter with 333Mh/s or 33Gh/s hardware;
2. No pool statistics is available even for a registered user. I can only see user hashrate graph, miner hashrate, balance, etc.;
3. Payout is round to 0.0001, the remaining is kept in user balance.


Regards,
iongchun

Thanks, iongchun. Were you mining long enough to get a feel for pool reliability?


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!

[organofcorti]

Always love these reports!

Where the hell have you been? Good to see you back here, been a while.

[wknight]

Always love these reports!

Where the hell have you been? Good to see you back here, been a while.

Lots of projects at the day to day job . Things are starting to free up a bit more. I am glad you stuck with the pool reports!

[bitcoinmining]

mining, statistics very good gains going well're always the case continued

[organofcorti]

mining, statistics very good gains going well're always the case continued

Google translate did a poor job there. Would you mind posting again?

[iongchun]

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

I think this pool could be considered stable.

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

[organofcorti]

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.

[organofcorti]

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.

[organofcorti]

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.

[organofcorti]

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

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


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.

[organofcorti]

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.

[zvs]

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!

[organofcorti]

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!

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.

[zvs]

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!

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.

Was thinking about it some too & I guess I could be wrong anyway..... re: bitminter + eclipseMC combined seem to get about 1/4th as many blocks as ghash.io?  so it could be similar proportionately

[organofcorti]

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!

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.

Was thinking about it some too & I guess I could be wrong anyway..... re: bitminter + eclipseMC combined seem to get about 1/4th as many blocks as ghash.io?  so it could be similar proportionately

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.

[cyrpi4]

Wow! Ozxoin has done great!
zvs , what will be your next forecast?