@lunarboy @AdrianX Anthony Towns has just post a pretty good write-up about forks on btc dev ml. He defined teo different kind of soft-forks: safe and damaging.
In his opinion BIP65 with OP_CLTV and BIP112 with OP_CSV belong to the former category because:
"they both redefine a non-standard opcode and would not get relayed or mined by old, non-upgraded nodes, and are thus "safe soft forks" per above terminology"
link to the full message: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011467.html
edit: another telling extract:
"*But* a soft fork that only forbids transactions that would previously not have been mined anyway should be the best of both worlds, as it automatically reduces the likelihood of old miners building newly invalid blocks to a vanishingly small probability; which means that upgraded bitcoin nodes, non-upgraded bitcoin nodes, /and/ SPV clients *all* continuing to work fine during the upgrade."
In his opinion BIP65 with OP_CLTV and BIP112 with OP_CSV belong to the former category because:
"they both redefine a non-standard opcode and would not get relayed or mined by old, non-upgraded nodes, and are thus "safe soft forks" per above terminology"
link to the full message: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011467.html
edit: another telling extract:
"*But* a soft fork that only forbids transactions that would previously not have been mined anyway should be the best of both worlds, as it automatically reduces the likelihood of old miners building newly invalid blocks to a vanishingly small probability; which means that upgraded bitcoin nodes, non-upgraded bitcoin nodes, /and/ SPV clients *all* continuing to work fine during the upgrade."