@taltamir
Let's slow down and think this through, shall we? You claim:
Whether you:
a. force 0.8 to reject valid blocks which it predicts 0.7 cannot process - currently cannot be done
b. force 0.8 to not generate blocks which it predicts 0.7 cannot process - currently can be done
The result is the same, you avoid a fork.
Unfortunately, this statement glosses over a crucial detail. In scenario A, as I understand, you mean "force
most 0.8 miners to reject valid blocks which it predicts 0.7 cannot process". And you are correct, currently I know of no way to do this.
Whereas, in B, you must force
all nodes to refrain from generating blocks like the one that caused this incident. Otherwise, in a
mixed environment of 0.7, 0.8 unmodified, 0.8 with option B
someone could start a fork the same way as just happened. Do you see? It's the
all part that makes us reject your proposal B in the short term. Neither A nor B is workable as of now. Block generators are advised to use 0.7 or earlier. As long as
most do, we (probably) avoid this kind of a fork.
I don't know why the forum banner still claims that mining on 0.8 is OK. Miners using 0.8 risk wasting hashes by building on a block that the majority (0.7-compatible network) will reject. Perhaps someone who has followed on IRC can comment?
The programmers who made 0.8 didn't consider this forking scenario. This platitude is thus entirely without merit
Pipe down, I am sure the developers thought long and hard about ways that 0.8 might cause a fork. One slipped through, because accidents happen.
I remember reading not every 0.7 node rejected the block, and the behavior was not even consistent within a same node; some nodes would accept the block after being restarted after initially rejecting it.
That would mean that 0.7 nodes are capable of producing blocks that other nodes of the exact same version may or may not accept, depending on factors which are hard to predict.
That would mean continuing to use 0.7 is an even bigger issue.
I agree with you, it is a big issue, and I feel confident that the core developers and stakeholders will find a reasonable solution pretty soon if they haven't already.