Quote from: JorgeStolfi on March 22, 2016, 03:24:55 AM

That is mathematically impossible. A soft fork, by definition, is a change that only makes the rules more restrictive: that is, some transactions that were valid by the old rules are invalid by the new ones, whereas all transactions that are valid by the new rules are also valid by the old ones.

That is why I mentioned using the version field. People who use undefined versions for their transactions need to accept that there is a risk.

The P2SH soft fork could easily have only applied to the outputs for version 2 (and above) transactions. The way it was actually done was to make it so that certain outputs could have been made unspendable. If someone happened to have a locked transaction with a P2SH output, then it would have ended up unspendable.

Similarly, it could have used one of the NOPs as trigger. Using undefined nops in locked transactions is also a risky thing to do.

Code:

<20 byte hash> OP_P2SH_VERIFY

That would even have used fewer bytes.

It would be worth making a statement of what are reasonable things to do with locked transactions. Using undefined versions and undefined NOPs would be risky.