Quote from: Rarrikins on March 15, 2013, 07:08:20 PM

Quote from: taltamir on March 15, 2013, 06:48:17 PM

The blocks being rejected by 0.7 are:
1. Possible to generate with 0.7 as well as 0.8
2. Perfectly valid blocks according to standard.
3. Being rejected because of a bug in 0.7

It will never, ever matter which blocks can be generated in regard to forking.

What matters is what blocks are accepted and what blocks are rejected.

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.

The issue is that option A is stupid and not doable. You would need to create a new version with a special block rejection engine to arbitrarily reject valid blocks predicted to be rejected by the bugged v0.7.
While for option B you simply have to alter the configuration of 0.8

And keep in mind that in reality you will see a mixed environment of 0.7, 0.8 unmodified, 0.8 with option B.
Bitcoin is without central authority and with people voting by implementing whatever solution they want, if any (meaning there are going to be many people who implement NEITHER solution)
As a miner, using 0.8 with option B gives you the lowest chance to generate an orphan block. followed by using 0.7 and then by option A

Quote

With bank accounts, consistency in transactions is far more important than avoiding minor bugs in implementing the specifications that don't affect the consistency or correctness of the transactions.

This is a hindsight analysis of what you would have done differently had you been one of the programmers working on 0.8 and had known about this possible issue in advance.
The programmers who made 0.8 didn't consider this forking scenario. This platitude is thus entirely without merit

Quote

This is why they made the decision to switch the mining pools to 0.7 for now. This gives the vast majority of hashing power to a universally-consistent chain.

That was merely emergency measure to resolve the fork

Quote from: justusranvier on March 15, 2013, 09:34:20 PM

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.