Weekly pool and network statistics

[organofcorti]

I've tried to explain it simply so I've left some things out. If it doesn't make sense, ask again and I'll try to make it a bit more clear.

Digesting.
Thanks all,
Sam

So, looking at Eclipse, .68 for (d1 shares per round)/network difficulty, looks pretty good.  But the chance of getting that luck is only 4%?

Not quite, but almost.

Rather than the probability of an average of 0.68 (over 26 rounds) being equal to 0.04 (or 4%), it's actually the probability of an average of 0.68 or less.(if you're trying to calculate this at home, keep in mind these are round values and won't give exactly the same results).

[os2sam]

I've tried to explain it simply so I've left some things out. If it doesn't make sense, ask again and I'll try to make it a bit more clear.

Digesting.
Thanks all,
Sam

So, looking at Eclipse, .68 for (d1 shares per round)/network difficulty, looks pretty good.  But the chance of getting that luck is only 4%?

Not quite, but almost.

Rather than the probability of an average of 0.68 (over 26 rounds) being equal to 0.04 (or 4%), it's actually the probability of an average of 0.68 or less.

There we go, I got it now.
Thanks,
Sam

[organofcorti]

17th November 2013 weekly pool and network statistics


Other weekly pool and network statistics posts

Welcome, miners.


Changelog:

    Added BTCDig - thanks for the API, dbitcoin.

Usual pools missing from results:

    Deepbit - no blocks solved this week.
    Ozcoin -no user hashrate data this week. Cloudflare prevents my attempts to screen scrape the relevant tables, so I won't be able to include Ozcoin in Figure 8 until that changes.

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", plus a new signature, "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. EclipseMC has crazy good luck

An average of 0.49 shares per round / mining difficulty for 41 solved blocks has a CDF of 0.000028. This means that luck as good as or better than that should occur only once every 35, 661 repeats of 41 blocks solved. This is very unlikely - there has only been about 6, 500 groups of 41 blocks solved ever. So either Eclipse has had extremely good luck, or there's a problem with the data. Given the strange changes in hashrate per round, it may be the latter so I'll find some time to audit the script I use to pull Eclipse's data.

2. Most pools lose some of their network; GHash.IO challenges BTCGuild.

The network hashrate is back up to 126% of expected, and the only pools to show an increase in their proportion of the network are GHash.IO, Discus Fish and ASICMiner. Since the latter two are small pools/entities, is seems that GHash.IO has increased it proportion of the network at everyone else's expense. In other words, much of the extra 262 extra blocks solved can be attributable to GHash.IO. At this rate it won't be long before they overtake BTCGuild.

Now would be a good time to throw some hashes as some of the smaller pool. Spreading your hashes amongst several pools will reduce your overall income variance and also help keep the network less centralised.

3. 50BTC now at 2Thps.

Seems like miners are returning. Check the latest gossip in the 50BTC thread on the bitcointalk.org forum.



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.au/2013/11/november-17th-2013-weekly-pool-and.html

You can view all previous charts at http://organofcorti.blogspot.com.au/search?q=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.

[juhakall]

What does "CDF" stand for?

Cumulative distribution function.

Aha, well I wish I could say that was helpful.

What is the theory of operation behind that term?

Did you read wikipedia?

In short, it reflects luck. The lower it is, the better the luck is.
CDF can tell you the probability of a block being found with a given number of shares.
50% value corresponds to expected value, i.e. neutral luck.

50% is indeed the "median", rather than "mean" (expected value).

If my understand is correct, block finding is like a poisson process and number of blocks found should follow poisson distribution.
Of course, the rate parameter changes continuously as miners go on and off, and every 2016 blocks at difficulty adjustment.

This is correct - the CDF measures the probability that a random variable will be larger or (in this case) smaller than a given random variable.

Here, the random variable is the average (d1 shares per round)/network difficulty for a given number of rounds, which is described by the Erlang distribution.

You'll notice for example that Itzod, with an average (d1 shares per round)/network difficulty of 1.19  had a CDF of 0.73, with 7 blocks solved. This means that 73% of the time a pool solves 7 blocks, the average  (d1 shares per round)/network difficulty  will be lower - and luck will be better.

OTOH   GHash.IO  had an average of  1.11 for 261 blocks soved, with a CDF of 0.96, so 96% of the time 261 blocks are solved, the average will be less than 1.11.

The more blocks solved, the "narrower" the CDF.

I've tried to explain it simply so I've left some things out. If it doesn't make sense, ask again and I'll try to make it a bit more clear.

Very good explanation, thanks! I had always wondered how the CDF could vary so much on pools with similar (d1 shares per round)/network difficulty values, but that bolded part made it embarrassingly simple to understand.

[Inaba]

@Organofcorti:  The crazy luck I think have may been due to anonymous PPS shares not being included in the round totals for share count.  I've corrected that issue and share counts should be proper going forward.

[organofcorti]

@Organofcorti:  The crazy luck I think have may been due to anonymous PPS shares not being included in the round totals for share count.  I've corrected that issue and share counts should be proper going forward.

Thanks Inaba - I've updated the blog post to reflect that. Do you think this could have also created the hashrates spikes I've been seeing?

[Inaba]

It's possible, yes...

I think I found one other place that is not showing the shares properly and it might affect the share count for a round... I need to investigate it further, but it's kinda late here.  I will get to it ASAP.  The share count should definitely be more accurate but I'm not sure it's 100% accurate without further investigation.  The way I have PPS, Anonymous PPS and DGM shares in the tables makes collating all those shares properly somewhat difficult, as they all reside in different tables in the database, which makes paying the shares much easier.  If it had it to do over, I'd have designed it very differently, but with all projects that kind of grow as time goes along, it's kind of convoluted now.

The pool originally started as Prop, then switched to GM, then to DGM, then added PPS, then added Anonymous PPS... ugh.

[organofcorti]

I think I found one other place that is not showing the shares properly and it might affect the share count for a round... I need to investigate it further, but it's kinda late here.  I will get to it ASAP.  The share count should definitely be more accurate but I'm not sure it's 100% accurate without further investigation.

Great! Looking back at previous posts, I think the "crazy good luck" started to occur the week previous to the October 27th post (or maybe the week before the October 20th post). The hashrate spikes began in the last week or two of September. I hope that helps in some way.

The way I have PPS, Anonymous PPS and DGM shares in the tables makes collating all those shares properly somewhat difficult, as they all reside in different tables in the database, which makes paying the shares much easier.  If it had it to do over, I'd have designed it very differently, but with all projects that kind of grow as time goes along, it's kind of convoluted now.

I know what you mean - you can't really plan for something you don't know will happen. I have the same problem (on a much smaller scale) with the scripts I run to generate the weekly reports. Part of them are jungles of code and well overdue for a rewrite

The pool originally started as Prop, then switched to GM, then to DGM, then added PPS, then added Anonymous PPS... ugh.

Yeah, remember who initially recommended you change to GM, way back when?

[ok]

Hi there,

Will it be possible to add a column on these nice reports with the Number of Blocks Solved per Thps weekly on each pool. This could give an additional measure on how the pool did during the week and how lucky it was as compared to others.

[os2sam]

Hi there,

Will it be possible to add a column on these nice reports with the Number of Blocks Solved per Thps weekly on each pool. This could give an additional measure on how the pool did during the week and how lucky it was as compared to others.

The "Mean shares per round/Difficulty" does that, "that" being how lucky it was compared to other pools.

Of course I guess I had a THs of power I wouldn't mind a measure of how well/bad I did in comparison without using my calculator.

[ok]

Hi there,

Will it be possible to add a column on these nice reports with the Number of Blocks Solved per Thps weekly on each pool. This could give an additional measure on how the pool did during the week and how lucky it was as compared to others.

The "Mean shares per round/Difficulty" does that, "that" being how lucky it was compared to other pools.

Of course I guess I had a THs of power I wouldn't mind a measure of how well/bad I did in comparison without using my calculator.

Yes, I think it will be quite useful to have that column (may be per 100GHs instead of 1THs) so that readers have that measure handy in addition to the Mean shares per round.

[organofcorti]

Hi there,

Will it be possible to add a column on these nice reports with the Number of Blocks Solved per Thps weekly on each pool. This could give an additional measure on how the pool did during the week and how lucky it was as compared to others.

The "Mean shares per round/Difficulty" does that, "that" being how lucky it was compared to other pools.

Of course I guess I had a THs of power I wouldn't mind a measure of how well/bad I did in comparison without using my calculator.

Yes, I think it will be quite useful to have that column (may be per 100GHs instead of 1THs) so that readers have that measure handy in addition to the Mean shares per round.

Interesting, but why would this be a better or more useful measure of luck than the canonical one? If I squeeze another column in there, I want to be certain theres a need for it.

Blocks per Thps will change when difficulty changes, so it's not very handy to look at over time. You'd need to multiply by difficulty. If you also by 2^32 you get estimated number of hashes to create those blocks. Divide by Thps, and you get a measurement with units sec^-1. Multiply by total seconds in a week and you get the inverse of the standard luck measurement: hashes / (difficulty * blocks * 2^32).

I appreciate the idea, but I just don't think theres a need for another closely related luck measurement - CDF and the usual one will do.

[organofcorti]

24th November 2013 weekly pool and network statistics.


Other weekly pool and network statistics posts

Welcome, miners.


Changelog:

    Nil

Usual pools missing from results:

    Deepbit - no blocks solved this week.
    BTCDig - no blocks solved this week.
    BTCMine - no blocks solved this week.

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", plus a new signature, "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. EclipseMC has normal luck and normal hashrates per round.

After Inaba made a few changes to his APIs, the data seems much more normal - both luck and hashrates are similar to other pools.

2. Historical network proportions.

Last week I suggested mining at smaller pools. This week I posted a historical chart of network proportions which some of you might find interesting - some current small pools were much larger, and some current large pools started out with very small proportions of the network.

3. 50BTC still hanging in there ....

Not much news in the 50BTC thread on the bitcointalk.org forum.

I wonder who is providing their hashes? Maybe from the pool owners?


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.au/2013/11/november-24th-2013-weekly-pool-and.html

You can view all previous charts at http://organofcorti.blogspot.com.au/search?q=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]

1st December 2013 weekly pool and network statistics


Other weekly pool and network statistics posts

Welcome, miners.


Changelog:

    Nil

Usual pools missing from results:

    50BTC.com, BTCMine, Triplemining: No blocks solved this week.

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", plus a new signature, "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. BTCGuild and GHash.IO

GHash.IO keep increasing their share of the network, most likely due to CEX.IO trading. I'm not sure how I feel about this - it's an increase in the proportion controlled by a single entity, but in effect any pool has the same control of hashes. It should make no difference that (as far as I'm aware) CEX.IO maintains the hash sources locally rather than the sources being distributed. Is there a downside I'm not understanding?

2. The network hashrate has increased 20629 % in the last 12 months

I was looking over a few old posts and found this one from a year ago.50BTC.com was top dog, BTCGuild and Deepbit shared second place. Now it's BTCGuild and GHash.IO (which didn't even exist then) and Deepbit and 50BTC.com are at ~ 1Thps each. Fortunes change rapidly in bitcoinworld.

A side note - the network hashrate just passed the half a petahash mark.

3. My apologies for not returning emails over the past week or two.

I'm stuck on a very interesting problem which has lead me down a rabbit hole, and as a result I've been putting of responding to emails. I hope to get on to that shortly.

Anyway, I must go. The rabbit hole awaits ....



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/2013/12/december-1st-2013-weekly-pool-and.html

You can view all previous charts at http://organofcorti.blogspot.com.au/search?q=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.

[Dannie]

Seems like the best ever week for btcguild with a CDF of 0.01.
As always, thanks for the report

[eleuthria]

GHash.IO keep increasing their share of the network, most likely due to CEX.IO trading. I'm not sure how I feel about this - it's an increase in the proportion controlled by a single entity, but in effect any pool has the same control of hashes. It should make no difference that (as far as I'm aware) CEX.IO maintains the hash sources locally rather than the sources being distributed. Is there a downside I'm not understanding?

Only extra worry from cex.io/ghash.io that is different from past concerns is accountability.  If a public pool *attempted* to do something nefarious that pool just committed suicide whether they succeed or fail at the gamble.  When a pool that has ~1 PH/s (based on estimates looking at their speed fluctuations during known pool issues for public vs private) privately owned, there is no accountability left.  Pair that with using a 0% fee for what was already the 2nd largest mining entity before the public was allowed in.  If they attempt something, there is basically no downside.  If the public hashrate leaves due to an attempt, they aren't actually losing anything (no fee) other than the mining time on their private farm.

[gmaxwell]

It should make no difference that (as far as I'm aware) CEX.IO maintains the hash sources locally rather than the sources being distributed. Is there a downside I'm not understanding?

The excuse giving for years of why consolidations of ten percent, twenty percent, or even more, in the hands of pool operators didn't effectively disprove the Bitcoin security model was that pool operators were more obligated than a typical miner to behave with the public interest at heart because the hashrate controlling miners could vote with their feet.

I've never been too fond of the argument: evidence (e.g. miners voting with their feet very slowly even when a pool is clearly robbing them) suggests otherwise... But that argument doesn't even exist for GHash.io/CEX.io: the miners are captive and cannot leave. Worse, there is a moral hazard because an unknown portion of the hardware is paid for by other people (at top dollar rates too) and so if some stunt they perform debases its value... so what? Heck, perhaps it drops the market value down to nothing an cex can buy their obligations back for a song. This means that CEX.io can probably profit from an attack even if that attack ultimately fails.

[organofcorti]

8th December 2013 weekly pool and network statistics


Other weekly pool and network statistics posts

Welcome, miners.

Changelog:

    Nil

Usual pools missing from results:

    50BTC.com, Triplemining, Deepbit: No blocks solved this week.
    BTCMine,  Giga's pool: Both closed.

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.

Welcome, miners!

1. BTCGuild and GHash.IO

GHash.IO overtook BTCGuild this week - the now have a quarter of a percent more of the network than BTCGuild.

Last week I wrote:

    "GHash.IO keep increasing their share of the network, most likely due to CEX.IO trading. I'm not sure how I feel about this - it's an increase in the proportion controlled by a single entity, but in effect any pool has the same control of hashes. It should make no difference that (as far as I'm aware) CEX.IO maintains the hash sources locally rather than the sources being distributed. Is there a downside I'm not understanding?"

I received a couple of good responses on bitcointalk.org:

From eleuthria, BTCGuild pool op:

    "Only extra worry from cex.io/ghash.io that is different from past concerns is accountability.  If a public pool *attempted* to do something nefarious that pool just committed suicide whether they succeed or fail at the gamble.  When a pool that has ~1 PH/s (based on estimates looking at their speed fluctuations during known pool issues for public vs private) privately owned, there is no accountability left.  Pair that with using a 0% fee for what was already the 2nd largest mining entity before the public was allowed in.  If they attempt something, there is basically no downside.  If the public hashrate leaves due to an attempt, they aren't actually losing anything (no fee) other than the mining time on their private farm."

From gmaxwell, bitcoin developer:

    "The excuse giving for years of why consolidations of ten percent, twenty percent, or even more, in the hands of pool operators didn't effectively disprove the Bitcoin security model was that pool operators were more obligated than a typical miner to behave with the public interest at heart because the hashrate controlling miners could vote with their feet.

    I've never been too fond of the argument: evidence (e.g. miners voting with their feet very slowly even when a pool is clearly robbing them) suggests otherwise... But that argument doesn't even exist for GHash.io/CEX.io: the miners are captive and cannot leave. Worse, there is a moral hazard because an unknown portion of the hardware is paid for by other people (at top dollar rates too) and so if some stunt they perform debases its value... so what? Heck, perhaps it drops the market value down to nothing an cex can buy their obligations back for a song. This means that CEX.io can probably profit from an attack even if that attack ultimately fails."

Thanks for explaining that, guys. I feel a little foolish for not having taken market forces into account.

2. "Unknown" at 10% of the network

I've developed my scripts to cast a wide a net as possible when identifying block owners, even so there are 137 blocks unaccounted for by the usual sources. I wonder if there are a bunch of new solominers? The network solved over 1300 blocks this week, so there are certainly new hash sources being added.

3. In memoriam

(Last "in memoriam" post)

I was once again busy all week on a project unrelated to mining and missed the planned closure of GigaVPS and Liquidbits' Mineb.tc pool (referred to as "Giga's pool" in the weekly stats). I'm sad to see the pool go, it was a good pool, stable and with great stats. I wish Giga VPS and LiquidBits the best in whatever project to which they next turn their attention. for those readers interested,  I posted an audit of the the pool's "luck" in August

It also looks like dbitcoin and company have finally moved the remaining hashes from BTCMine to BTCDig. I'm glad to see a famous old mine continuing under a new guise.

Bitclockers.com has been down for so long now that I'm also considering that pool closed.

So here's an update of the "In memoriam" chart of the percentage of hashrates of all the dead pools for which I have records, in order of the last week in which they solved a block.

As I wrote last time:

    "Please take some time to think about the pool operators who ran these pools, loved them as if they were their own children, and did their part to help secure the network. Also, don't forget about the many other pools that didn't make it -  Arsbitcoin and Continuum pool (the first pool to use the Geometric method of reward distribution, the progenitor of DGM) come to mind, but there have been many others, especially those that were unable to change from a proportional reward method."


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/2013/12/december-8th-2013-weekly-pool-and.html

You can view all previous charts at http://organofcorti.blogspot.com.au/search/label/weeklypoolstatisticsand 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]

15th December 2013 weekly pool and network statistics


Other weekly pool and network statistics posts

Welcome, miners.


Changelog:

    Nil

Usual pools missing from results:

    BTCDig, Triplemining, Deepbit: No blocks solved this week.

Errors:

    The hashrate (or possibly luck, or both) estimates for either BTCGuild or  GHashIO are  incorrect. I'm not sure which.

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. BTCGuild and GHash.IO

You might notice that although BTCGuild's hashrate is higher than GHash.IO's hashrate, it solved fewer blocks. This would indicate a worse luck for BTCGuild than for GHash.IO, and yet the results show the reverse.

I'm not sure which of the results are in error - my BTCGuild script is complicated and the script for GHash.IO is new. I'll be spending tonight trying to figure out what the problem is.


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/2013/12/december-15th-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.

[eleuthria]

Hi organofcorti,
  If I had to guess...your ghash.io average speed is wrong.  They were ahead of BTC Guild up until the end of this week based on my interim checks.  Then again, the luck *seems* off (I don't think pool luck has been 104% this last week, it wasn't good for the first half of the week at least).  I'll take a look on my end to see if I can find what my calculated luck % was for the week.