..
The pools all run on individual hosts - and are NAT'd out of the colo on individual addresses. The pools are not technically going down - they're just on different forks of the chain. We're trying to make this harder to happen - each pool has each other blacklisted, so block confirmations have to come from the network, not another pool. So ninja/burst-team believe they've one a block, others on the network agree with them, the other pools don't and we're forked. What would really help is spreading the hashing power over all the pools. With so much hash power on burst-team and Ninja, it's not hard for them to create forks.
..
IMHO, criss-cross blacklisting the major pools is a bad idea.
A "fork" situation is quite normal and will be resolved quickly
(usually within minutes).
The time needed for that is a function of propagation time.
By blacklisting known major block creators from each other,
you _increase_ propagation time.
This leads to the situation that pools are on different forks
longer than necessary with undesired side effects.
When like 50% of overall hashpower comes from just 2,3,4
pools, these 2,3,4 machines should have each other on their
trusted peerlist. Maybe a code tweak to force them staying
interconnected would help. Blacklisting is the exact opposite
of what is needed here.
What is the reasoning for this blacklisting ?
(I could be wrong on that, though.)