Quote from: organofcorti on December 19, 2013, 10:32:16 AM

I'm not quite following you there - BTCGuild has had well over 30% of the hashrate at times and has not caused similar issues.

I was conservative with the 25% figure and it was not based on some calculations (yes, you can say it's out of thin air), but ...

There are hundreds of thousands peers on the network and each client connects to up to 8 or 16 peers, some are connected to more (accepting inbound connections and no nat), but still there are several hops required to connect all.
Lets say Pool A has huge chunk of the hashing power, but is well connected to other (100+) peers and some pools - those pools won't have problems. A solo miner may still produce an orphan block if not well connected, which is his own problem and will rarely happen, but ...
There is a Pool B with similar (good) connectivity and also large chunk of the hashspeed, which does not have direct connection to Pool A or any of it's peers, but to some other set of pools - the end result is an increased chance for the network to be split and with that comes an increased chance for orphan blocks from both sides.
If the block generation rate is ~~slow~~ normal - 10min are enough for the blocks to pass from Pool A to Pool B, but for short blocks (like it is now) the chance for orphans increases.

Right now the situation is exactly that - GHash.IO is separated from the rest of the pools, which are well connected via the same backbone providers and has a large chunk of the power, but at the same time is connected to enough peers to propagate their work to the network.

I hope this explanation is more clear what i meant.