Since there is no known way to consistently find blocks faster than the difficulty level and there are many ways to lower the over all return (DDoS, bugs, fees, latency, etc) there is a persistent negative bias on the distribution of pool performance.
Let's see:
DDoS:
Might make accepting shares difficult/impossible, maybe even sending out valid blocks to the network --> more invalids, but surely not more shares/block
Bugs:
They could lead to accepting + paying solutions twice, acepting + paying invalid solutions etc --> Might increase the shares per block
Fees:
Are an arbitrary concept, do not influence the shares per block, only the payment per share
Latency:
Maybe from miner <--> pool? Increases the stale share rate and might even cause some valid solutions not being pushed to the net (if pushpoold is not "brave" enough to dare to cause a chain split) --> might lead to more invalid blocks or even more shares/block
The real question is: How high is this persistent negative bias (that HAS to exist, with solo mining on a very well connected node as a baseline) throughout all pools and which pool is best there? Also: Why do some pools have a bigger negative bias consistently?
Oh and by the way:
Long Polls are also far too often VERY ineffective or too late, if you look at statistics by pool hoppers! These are the main cause for stale shares and can lead to significantly lower payouts, if you have a pool that performs porly there.
Vlad the Petulant had cited overall return as the gold standard for pools. I was pointing out that overall returns are likely never to be perfectly efficient for pools given all the things that can go wrong and the lack of known incidents/methods/etc that increase positive luck. That was why I was interested in the distribution of all the other pools Vladdie searched through. The data at
http://www.l0ss.net/index30.php shows this bias for the previous 20 days and as more data is gathered, it should give us an idea of the size of the bias.
As for Vladdums claims to not understand how system failures could lead to invalid blocks, Mainframe Mining Cooperative cited the following:
"...with some unfortunate side effects of reduced I/O to one of the storage array disk clusters the pool cluster is using which was causing some latency and load issues for the pool. At the very moment we found block 142,496 we were getting this array back up to speed and im convinced that everything running a bit slower is what caused us to lose our first race."https://bitcoin.org.uk/forums/topic/125-the-story-behind-our-little-orphan-block-142496/@Vlad, now that you cry libel defense you can either come at me with a lawyer by filing a john doe lawsuit and compel bitcointalk.org to reveal my IP address and then subpoena my ISP for my identity and then proceed with the lawsuit to recover damages. Or you can add your claims of a libel defense to the list of things you have posted in this thread that are not correct.
If Vlad ever bothers to post the data he supposedly gathered on the other pools we might get to the bottom of this. I doubt he will, since it will likely make his claims look baseless. Until that time,
http://www.l0ss.net/index30.php speaks volumes with nothing to refute it.