I did some analysis of pool efficiency for: Tycho, BTCGuild, slush and luke-jr, and I have found a problem with BTCGuild. I think I need your help to verify this, to be sure that I make no mistake here.

I did setup cron about half a year ago, to be able to verify pool stats some day. And I didn't setup it for BTCGuild because they provide all_blocks.php webpage with full history. Now it's only them that appear to be problematic in those calculations. I suppose that other pool owners could also provide their history to verify my crontab downloading.

Next thing, the calculations for each pool are following:i - round number,j - difficulty index (all rounds with the same difficulty have the same j) ):

There you can see "Difficulty". I downloaded all blocks from blockexplorer for each pool, with a short script, then filtered them on "Difficulty" with grep, sorted it by hash and pasted into spreadsheet. Then I sorted pool stats by hash. And compared if those hashes are equal. You can exactly see this in tycho's case, Because I wrote extra column for hash comparison, which writes "OK" when they match. For others I didn't need to do this, because there were fewer blocks. In tycho there were 12000

Just a minor point, when difficulty changes, it means the pool rounds may have 2 difficulties, not just one.The longer the pool rounds, the more likely.You'd have to break it down at the per block level (easiest) or break those rounds that cross the difficulty change or calculate a difficulty for those rounds (worst idea of the three )

Just a minor point, when difficulty changes, it means the pool rounds may have 2 difficulties, not just one.The longer the pool rounds, the more likely.You'd have to break it down at the per block level (easiest) or break those rounds that cross the difficulty change or calculate a difficulty for those rounds (worst idea of the three )

currently I was using the difficulty of generated block. And this difficulty is in denominator so it makes the resulting fraction `shares/diff` to be smaller when difficulty goes up (which was the case most of the time). So this approach makes the pools a little more lucky than in reality. But total effect on pool luck is very small, like 0.001 or something like that. It's easy to check - get that openoffice spreadsheet, change difficulties of those blocks and see what is the result.

Maybe somebody can calculate for arsbitcoin too? I have them archived also, but didn't have time yet to calculate.

Interesting. At first glance having bad luck 3x standard deviation looks pretty bad. I will reserve final judgement until I look at the workflow but statistically peaking there is only a 1/2000 chance of a pool being that unlucky.

OP you got a donation address?I hope this is something you intended to do periodically.

-ve luck could be caused by a pool accepting shares that shouldn't have been. e.g. duplicates or if there is a delay between new block on the network and the pool detecting it and marking all new shares issued before that time as stale.

conversely +ve luck could be caused by pool rejecting shares that are valid (but still potentially submitting to bitcoin network). e.g. pools share cache has expired the work so the share is counted as unknown. Or blkmond detecting a new block before bitcoind is ready to serve work from the new block so longpolls go out with 'new' work from previous block but when they come back as a share it's rejected as stale due to prevblockhash not matching.

It is impossible to have a coherent discussion with someone who is unable to build up a logical argument. There is no logical link leading from whatever I ever said using my imperfect English to your claim that I allegedly said "BTC Guild is cheating someone". BTC Guild cheating someone may or may not be the case, I have not seen any 100% proof of either.

After you take some logic classes go read up on Stockholm Syndrome. Meanwhile, welcome to my ignore list.