Miners have no incentive to employ monitoring of the blockchain via multiple clients like Eligius did to avoid mining any blocks on the invalid chain, if they're just going to be reimbursed anyway.
Except that in this case 0.8 miners were technically mining on a good chain and it was quite hard to detect that there was a problem. My pool has been always checking if it has the same blockchain as some other nodes, obviously this cannot cover all possible cases.
No, you mined an invalid block (under the standing Bitcoin rules) and other 0.8 miners were building on top of an invalid chain.
If you were testing against multiple implementations, you could have caught the problem as Eligius did.
(Not to say you are at fault for the hardfork, but these are the reality of it)
You are really crazy.
Yes, start off with an ad hominem. Fits your post pretty well.
Slush was creating blocks with "official" client and following the dev's advise to increase the block size.
There is no such thing as official, and I already agreed he isn't at fault for the problem.
The block is accepted by every 0.8 nodes. What do you mean by "an invalid block under the standing Bitcoin rules"?
EDIT: If a bug could be considered a "rule", should we all move back to v0.1 as it represents the "orthodox" bitcoin rules?
There was a hardfork around the move to 0.3, so that is the oldest that would work to any extent with the standing Bitcoin rules.
Changes in rules require advance planning and notification, and the consent of the economic majority (note,
not the mining majority).
Nobody had any notice of 0.8's rule change (because nobody knew about the rule), and the majority of Bitcoin users (including the economic majority) enforced the standing rules.
0.8 was the "odd man out" disagreeing over the network rules. All* the other clients agreed the block was invalid.
The objective way to look at the situation is to pretend 0.8 was a completely new client with unknown source/origin introduced to the network by an unknown party.
* The only other exception I am aware of was Coinbase's proprietary node, which I think can be agreed does not make a difference on its own.A rule should be something agreed to every nodes.
However, according to BIP0050:
This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).
As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule.