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! 
Topic: Weekly pool and network statistics - page 11. (Read 91444 times)
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! 
Always love these reports!
Where the hell have you been? Good to see you back here, been a while.
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
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!
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.
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
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)
Always love these reports!
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.
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.
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
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.
Thanks for the report, organofcorti.
I am surprised to see Discus Fish growing so rapidly for the past months.
Is it indeed a pool? Or is it sort sort of private mining farm?
I am surprised to see Discus Fish growing so rapidly for the past months.
Is it indeed a pool? Or is it sort sort of private mining farm?
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
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?
Thanks for the report, organofcorti.
I am surprised to see Discus Fish growing so rapidly for the past months.
Is it indeed a pool? Or is it sort sort of private mining farm?
I am surprised to see Discus Fish growing so rapidly for the past months.
Is it indeed a pool? Or is it sort sort of private mining farm?
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
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 for the report, organofcorti.
I am surprised to see Discus Fish growing so rapidly for the past months.
Is it indeed a pool? Or is it sort sort of private mining farm?
I am surprised to see Discus Fish growing so rapidly for the past months.
Is it indeed a pool? Or is it sort sort of private mining farm?
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
Thanks for the report, organofcorti.
I am surprised to see Discus Fish growing so rapidly for the past months.
Is it indeed a pool? Or is it some sort of private mining farm?
I am surprised to see Discus Fish growing so rapidly for the past months.
Is it indeed a pool? Or is it some sort of private mining farm?
January 26th 2014 Weekly Pool and Network Statistics
Other weekly pool and network statistics posts
Other weekly pool and network statistics posts
Welcome, miners.
Changelog:
Everything - see below
Usual pools missing from results:
I haven't rebuilt this part yet - TBA.
Errors:
I haven't found any - please tell me if you find something.
0. Update almost complete
The reasons behind working on a new method of gathering and analysing network hashrate contribution statistics for the last few months :
Orphaned blocks were often incorrectly reported by pools.
There is a wide variety of block history reporting methods, some of which don't report block heights, and some of which don't report block creation times, some report block hashes, and some report only the transaction hash of the generation address transaction.
I had no simple way to integrate new hashrate sources.
I had no way to attribute blocks to generation addresses.
I decided to gather the pool statistics into one dataframe, and then grep the block chain for the reported block hashes or transaction hash. Once found, each block is marked as confirmed.
This means that I have an accurate record of orphaned blocks, but it also means that I can use the blockchain height and timestamp recorded on the blockchain to fill in the data that some pools do not report.
Only orphaned blocks can't be assigned a timestamp in this way, and for pools which do not report the creation time of an orphaned block I use the timestamp of the block that won the orphan race. For pools reporting neither block height nor time of orphaned blocks, I use the next time the pools solves a block. In these latter two cases some inaccuracy may occur.
Several important notes:
There are several pools with missing historical data or are missing from historical data completely. This only affects the extent of the historical data charts (for example Figure 2) but not the accuracy - except for some early values of top three pool's combined hashrates.
I have requested this data from several pools but have not yet heard back, except from BTC Guild which doesn't have the data available anymore, and BTC Mine which will deliver their complete history soon.
I won't be including pool-hopping charts unless pool-hopping becomes common once more.
1. Weekly statistics using blockchain data
Using only blockchain data, the following statistics can be reported:
An estimate of the hashrate (with the upper and lower 95% confidence interval bounds).
Valid blocks solved.
The percentage of network blocks solved.
The first table is a compilation of those statistics, including non pool sources such as CloudHashing and pools that don't have public reporting of statistics, such as Discus Fish. Note that actual pool hashrates (where available) will be more accurate.
2. Weekly statistics using pool reported data
The weekly statistics that can be calculated using all solved blocks - both valid and orphaned - and difficulty 1 shares per round are:
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.
3. Reused but unknown generation addresses
Unknown generation addresses that are not reused are probably solominers or private mining concerns that don't have share-holders wanting to follow transactions. However, reused addresses are probably from hash contributors that do not wish to remain anonymous. These need to be identified so they can be removed from the "Unknown" group. I'm not interested in identifying those who wish to remain completely anonymous, so I'm not trying to trace originating IP addresses (as Blockchain.info does).
Table 3:Blocks solved by unknown but re-used generation addresses Jan 27 2013 to Jan 26 2014
(not included - see blog for table)
4. Percentage of network blocks
The only change here is that I'm not bothering with percentage of the network hashrate, which was inaccurate due to an increase in the number of hashrate sources with estimated hashrates.
5. 51% attack chart
There are several changes here compared to the previous version is that hashrates are all estimated from blocks solved, and the history goes back to the earliest date my data contains three known pools. As previously mentioned, some pool data may be missing from the earliest data points.
6. Network percentage history of the current top ten contributors.
Data is calculated from the number of blocks each contributor added to the blockchain during the week, rather than using hashrates and estimated hashrates, and becuase of this should be more accurate with a longer history. The other changes are cosmetic.
7. Average hashrate per solved block (valid + invalid)
The only changes here are cosmetic:
Changes to facet labels and background.
The last two weeks are included rather than just the last week.
BTC Guild not included. This is because I've simplified data that I scrape and collect to improve robustness of the data collection. However, BTC Guild has a very good hashrate chart which has matched my past estimates quite well and which I regard as accurate.
The network hashrate per 144 blocks is also not included, since I think it is of limited use to readers more interested in pools.
8. Pool "luck"
I have wanted to remove either the shares per round / network Difficulty chart or the CDF chart, since they measure the same thing. However I couldn't make up my mind as to which would be the better chart to keep. In the end I came up with something I think is better than both.
This chart is new and might look a little confusing at first, but is actually simple and intuitive to follow once you get the hang of it. 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.
9. User hashrate and combined user hashrate densities
Cosmetic changes only.
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/01/january-26th-2014-weekly-pool-and.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 pool and network statistics posts
Other weekly pool and network statistics posts
Welcome, miners.
Changelog:
Everything - see below
Usual pools missing from results:
I haven't rebuilt this part yet - TBA.
Errors:
I haven't found any - please tell me if you find something.
0. Update almost complete
The reasons behind working on a new method of gathering and analysing network hashrate contribution statistics for the last few months :
Orphaned blocks were often incorrectly reported by pools.
There is a wide variety of block history reporting methods, some of which don't report block heights, and some of which don't report block creation times, some report block hashes, and some report only the transaction hash of the generation address transaction.
I had no simple way to integrate new hashrate sources.
I had no way to attribute blocks to generation addresses.
I decided to gather the pool statistics into one dataframe, and then grep the block chain for the reported block hashes or transaction hash. Once found, each block is marked as confirmed.
This means that I have an accurate record of orphaned blocks, but it also means that I can use the blockchain height and timestamp recorded on the blockchain to fill in the data that some pools do not report.
Only orphaned blocks can't be assigned a timestamp in this way, and for pools which do not report the creation time of an orphaned block I use the timestamp of the block that won the orphan race. For pools reporting neither block height nor time of orphaned blocks, I use the next time the pools solves a block. In these latter two cases some inaccuracy may occur.
Several important notes:
There are several pools with missing historical data or are missing from historical data completely. This only affects the extent of the historical data charts (for example Figure 2) but not the accuracy - except for some early values of top three pool's combined hashrates.
I have requested this data from several pools but have not yet heard back, except from BTC Guild which doesn't have the data available anymore, and BTC Mine which will deliver their complete history soon.
I won't be including pool-hopping charts unless pool-hopping becomes common once more.
1. Weekly statistics using blockchain data
Using only blockchain data, the following statistics can be reported:
An estimate of the hashrate (with the upper and lower 95% confidence interval bounds).
Valid blocks solved.
The percentage of network blocks solved.
The first table is a compilation of those statistics, including non pool sources such as CloudHashing and pools that don't have public reporting of statistics, such as Discus Fish. Note that actual pool hashrates (where available) will be more accurate.
2. Weekly statistics using pool reported data
The weekly statistics that can be calculated using all solved blocks - both valid and orphaned - and difficulty 1 shares per round are:
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.
3. Reused but unknown generation addresses
Unknown generation addresses that are not reused are probably solominers or private mining concerns that don't have share-holders wanting to follow transactions. However, reused addresses are probably from hash contributors that do not wish to remain anonymous. These need to be identified so they can be removed from the "Unknown" group. I'm not interested in identifying those who wish to remain completely anonymous, so I'm not trying to trace originating IP addresses (as Blockchain.info does).
Table 3:Blocks solved by unknown but re-used generation addresses Jan 27 2013 to Jan 26 2014
(not included - see blog for table)
4. Percentage of network blocks
The only change here is that I'm not bothering with percentage of the network hashrate, which was inaccurate due to an increase in the number of hashrate sources with estimated hashrates.
5. 51% attack chart
There are several changes here compared to the previous version is that hashrates are all estimated from blocks solved, and the history goes back to the earliest date my data contains three known pools. As previously mentioned, some pool data may be missing from the earliest data points.
6. Network percentage history of the current top ten contributors.
Data is calculated from the number of blocks each contributor added to the blockchain during the week, rather than using hashrates and estimated hashrates, and becuase of this should be more accurate with a longer history. The other changes are cosmetic.
7. Average hashrate per solved block (valid + invalid)
The only changes here are cosmetic:
Changes to facet labels and background.
The last two weeks are included rather than just the last week.
BTC Guild not included. This is because I've simplified data that I scrape and collect to improve robustness of the data collection. However, BTC Guild has a very good hashrate chart which has matched my past estimates quite well and which I regard as accurate.
The network hashrate per 144 blocks is also not included, since I think it is of limited use to readers more interested in pools.
8. Pool "luck"
I have wanted to remove either the shares per round / network Difficulty chart or the CDF chart, since they measure the same thing. However I couldn't make up my mind as to which would be the better chart to keep. In the end I came up with something I think is better than both.
This chart is new and might look a little confusing at first, but is actually simple and intuitive to follow once you get the hang of it. 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.
9. User hashrate and combined user hashrate densities
Cosmetic changes only.
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/01/january-26th-2014-weekly-pool-and.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.
I've struggled to find time to complete the update to include more block statistics and more unknown hashrate sources. I've had to give up for the moment, and so I've posted this week's update based on the old scripts.
You can only do what you can do when you can do it.
I appreciate what you do do.
Thanks,
Sam
Cheers, Sam. I'll have something pretty cool soon, I hope.
I've struggled to find time to complete the update to include more block statistics and more unknown hashrate sources. I've had to give up for the moment, and so I've posted this week's update based on the old scripts.
You can only do what you can do when you can do it.
I appreciate what you do do.
Thanks,
Sam
January 19th 2014 Weekly Pool and Network Statistics
Other weekly pool and network statistics posts
Welcome, miners.
Changelog:
Nil.
Usual pools missing from results:
No time to check.
Errors:
Nil.
Pools with coinbase signature:
ASICMiner: "Mined By ASICMiner"
Alydian5335: "Alydian5335"
Bitparking: "bitparking"
BitMinter: "BitMinter"
BTCGuild: "Mined by BTC Guild", "BTC Guild DE", "BTC Guild 2", "BTC Guild US2", "BTC Guild GW"
CoinLab: "CoinLab"
Discus Fish: "七彩神仙鱼" and "Made in China"
EclipseMC: "EMC"
Eligius: "Eligius"
50BTC.com: "Hi from 50BTC.com" and "50BTC.com"
GHash.IO: "ghash.io" (not current)
GIVE-ME-COINS.com: "Mined at GIVE-ME-COINS.com"
HHTT: "HHTT"
Megabigpower "megabigpower.com"
175btc.com": "Mined By 175btc.com"
Ozcoin: "ozcoin"
Pierce and Paul: "For Pierce and Paul"
Triplemining: "Triplemining.com"
Slush's pool: "slush"
Recent coinbase messages:
258692 "To my honey, by bitfish."
259575 259622 259625 "EMC: Organofcorti lives!"
263952 "btcpoolman"
Pool hopping:
Nil.
1. Update incomplete
I've struggled to find time to complete the update to include more block statistics and more unknown hashrate sources. I've had to give up for the moment, and so I've posted this week's update based on the old scripts.
2. Now I'm off to bed.
Goodnight!
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/01/january-19th-2014-weekly-pool-and.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 pool and network statistics posts
Welcome, miners.
Changelog:
Nil.
Usual pools missing from results:
No time to check.
Errors:
Nil.
Pools with coinbase signature:
ASICMiner: "Mined By ASICMiner"
Alydian5335: "Alydian5335"
Bitparking: "bitparking"
BitMinter: "BitMinter"
BTCGuild: "Mined by BTC Guild", "BTC Guild DE", "BTC Guild 2", "BTC Guild US2", "BTC Guild GW"
CoinLab: "CoinLab"
Discus Fish: "七彩神仙鱼" and "Made in China"
EclipseMC: "EMC"
Eligius: "Eligius"
50BTC.com: "Hi from 50BTC.com" and "50BTC.com"
GHash.IO: "ghash.io" (not current)
GIVE-ME-COINS.com: "Mined at GIVE-ME-COINS.com"
HHTT: "HHTT"
Megabigpower "megabigpower.com"
175btc.com": "Mined By 175btc.com"
Ozcoin: "ozcoin"
Pierce and Paul: "For Pierce and Paul"
Triplemining: "Triplemining.com"
Slush's pool: "slush"
Recent coinbase messages:
258692 "To my honey, by bitfish."
259575 259622 259625 "EMC: Organofcorti lives!"
263952 "btcpoolman"
Pool hopping:
Nil.
1. Update incomplete
I've struggled to find time to complete the update to include more block statistics and more unknown hashrate sources. I've had to give up for the moment, and so I've posted this week's update based on the old scripts.
2. Now I'm off to bed.
Goodnight!
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/01/january-19th-2014-weekly-pool-and.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.
The lack of growth in Slush's pool saddens me. I hate seeing it shrink like this. I think most of the problem is that people can't wrap their head around it's distribution system(who gets how much of the reward). They are always second guessing it, incorrectly. How it works is addressed weekly in it's support thread. Sad... 
I'd like to see it prosper too, and it certainly has a good deal of uptime. But since he's using a non-standard and exploitable reward method, he needs to either be available or employ someone to be available. Look at DrHaribo or eleuthria - they spend most of every day helping miners, and thats with easily understood reward methods.
I understand Trezor is important, and it's probably all Slush has time to deal with right now. But he is taking a 2% fee and at the current exchange rate I'm sure he could get someone to answer questions about the pool for him.
The lack of growth in Slush's pool saddens me. I hate seeing it shrink like this. I think most of the problem is that people can't wrap their head around it's distribution system(who gets how much of the reward). They are always second guessing it, incorrectly. How it works is addressed weekly in it's support thread. Sad...
January 12th 2014 Weekly Pool and Network Statistics
Other weekly pool and network statistics posts
Welcome, miners.
Changelog:
"Luck" for BTCGuild not included, and I will not be including it again until I can find a measurement in which I have more confidence. This is nothing to do with my confidence in BTC Guild, just the difficulty in calculating a luck score that is comparable to those of other pools, since BTC Guild does not report shares per round.
Usual pools missing from results:
Deepbit, GIVE-ME-COINS.com, 175btc.com, BTCDig, Ozcoin, Itzod: No blocks solved this week.
50BTC.com - API no longer working. I'll need to contact them to get this fixed.
Errors:
Nil.
Pools with coinbase signature:
ASICMiner: "Mined By ASICMiner"
Alydian5335: "Alydian5335"
Bitparking: "bitparking"
BitMinter: "BitMinter"
BTCGuild: "Mined by BTC Guild", "BTC Guild DE", "BTC Guild 2", "BTC Guild US2", "BTC Guild GW"
CoinLab: "CoinLab"
Discus Fish: "七彩神仙鱼" and "Made in China"
EclipseMC: "EMC"
Eligius: "Eligius"
50BTC.com: "Hi from 50BTC.com" and "50BTC.com"
GHash.IO: "ghash.io" (not current)
GIVE-ME-COINS.com: "Mined at GIVE-ME-COINS.com"
HHTT: "HHTT"
Megabigpower "megabigpower.com"
175btc.com": "Mined By 175btc.com"
Ozcoin: "ozcoin"
Pierce and Paul: "For Pierce and Paul"
Triplemining: "Triplemining.com"
Slush's pool: "slush"
Recent coinbase messages:
258692 "To my honey, by bitfish."
259575 259622 259625 "EMC: Organofcorti lives!"
263952 "btcpoolman"
Pool hopping:
Nil.
1. I had a wonderful break, thank you for all your Christmas / New Year well-wishing.
As well as a nice break in the country-side, I've been working hard on a way to get real time charts going. The big hurdle was to come up with an automated way of assigning blocks to pools. I've now done this based on coinbase signatures, known generation addresses and blocks claimed by pools. In the short term this allows me a great deal of flexibility and ease when invistigating block ownership; in the medium term I'll be able to base weekly data on blockchain results and pool website results separately; and in the long term it will be the engine on which real time charts can be produced. I've still got lots of work to do, but it's coming along (and it's why this post is being published a week late.
As an example of the sorts of things I can do, have a look at this:
http://bitbin.it/3iIbl6tA
It's a .csv table (easy to import into spreadsheeting software) and provides the attribution for each block, and whether or not the block creator was identifiable by either coinbase signature or generation address, or whether the pool claimed the block on their website, and what proof they used that the block was theirs (tx hash or block hash). Where available, the number of difficulty 1 equivalent shares / network difficulty (the standard "luck" calculation) is given in the final column - larger than 1.0 is poor "luck", less than 1.0 is good "luck".
2. Donation address has changed.
My previous donation address was a personal address I used for everything. The new address:
1QC2KE4GZ4SZ8AnpwVT483D2E97SLHTGCG
is only going to be used for blog donations so I can keep track of them better.
3. GHash.io
I'm not going to write much about this. I think much of the panic of the past week is due to poor interpretation of the 24 hour Blockchain.info pie charts, which are affected by variance. The weekly average is at about 32% of the network, and the rate of increase is less than it has been. It's important to encourage GHash.io to reduce its network percentage but there's no need for the sorts of witch hunts we've been seeing - the worst since those protesting against DeepBit when that pool was king.
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/01/january-12th-2013-weekly-pool-and.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.
Because, Trongersoll, like me you're a sticky-beak
Jump to: