How are OP_CSV and OP_CLTV backwards compatible

Question

I am not able to see how older nodes prior to BIP 68, BIP112 and BIP 65 are able to prevent adding Transactions to their mempool when the newer rules are deliberately breached. I want to separate two cases I don't understand:

1. OP_CLTV. Lets say an UTXO Output is locked by <30Blocks OP_CLTV OP_DROP HASH160 PKH CHECKSIG>. Nodes following the new standard will check the nlocktime field of a transaction so that it is earlier than the time in the encumbrance. But if I publish this transaction to older nodes, for them the ScriptPubkey is not TimeLocked. So how are older miners prevented to mine on such invalid transactions

2. OP_CSV. For this OP_Code I could see, that older Nodes will not include transactions with a version number >=2. Otherwise we would have the same problems, that older nodes would include those transactions in their mempool without being able to check whether they are breaching the relative time lock.

With the new Script Versioning introduced by Segwit, these cases got easier. But using NOPs backwards compatibility seems very hard.

Answer 1

When it comes to soft forks, backwards compatible does not mean that old nodes will follow the new rules - that would mean that the new rules are already implemented. Rather backwards compatible means that following the new rules does not make previously invalid transactions valid, i.e. old nodes will still see those transactions as valid.

So what ends up happening is that, yes, old nodes will consider some invalid transactions as valid because they are valid under the old rules and not under the new rules.

It is for this reason that soft forks are only activated when it is likely that almost every miner (and hopefully every node) has upgraded to software that will follow the new rules. This is done by having miners signal inside of their blocks that they have upgraded and are ready to validate under the new rules. The soft fork only becomes active only when a certain threshold of signaling blocks is reached.

For OP_CLTV, the new rules were only to be enforced after 750 out of the previous 1000 blocks signaled by using a block version number >= 4. Even so, the rules were only enforced in blocks which have a version number >= 4. Once 950 out of the previous 1000 blocks had a block version number >= 4, then no blocks with a version number < 4 were allowed, and so at that point, all miners had to be enforcing the new rules.

For OP_CSV, the new rules were only to be enforced when 1915 out of a 2016 block difficulty period signaled by having a specific bit set in the version number. This also had a built in grace period of one difficulty period (2016 blocks) to allow for upgrades after the threshold was reached. So when the threshold is reached in one period, the next period the soft fork is not activated to allow for everyone to upgrade, and then the period after that is when the soft fork became active.

Through these deployment mechanisms, we can be reasonably sure that miners will not mine a block that includes a transaction that is invalid under the new rules. Miners should be upgraded when they begin signaling.

Furthermore, transactions using these new features are typically considered non-standard to old nodes. This means that old nodes will not relay those transactions, and so any miners using an old nodes will not accept them into their mempool and thus not include them in blocks. This is an additional protection as any miner who is following the standardness rules (and most are) will not include any transactions using the new rules (valid or invlaid) as they consider them to be non-standard.