I don’t personally agree with this, but the concern stems from the possibility of having UTXOs with mutually exclusive spend conditions. Let me walk through an example to illustrate.
It might helpful to revisit BIP65 for some background here.
Imagine I have two UTXOs in my wallet:
- UTXO A has an
OP_CLTVscript that uses block height. - UTXO B has an
OP_CLTVscript that uses wall clock time.
These UTXOs cannot be spent together in the same transaction because they both rely on the nLockTime field for validation. Since a transaction only has a single nLockTime, you can’t satisfy both scripts at the same time. (Note: OP_CLTV uses the same kind of “indirect validation” mechanism that OP_CSV does.)
This creates an awkward scenario for wallets: how do you convey that these two UTXOs are mutually exclusive in terms of spendability?
OP_CSV avoids this problem because it uses per-input nSequence values, so the same conflict doesn’t arise. Each input can specify its own relative locktime.
I agree with this framing. Transactions are the atomic unit of validation in the Bitcoin network, and we should be able to introspect anything within the transaction.
I don’t think this principle extends to external factors like block time or block height as they aren’t directly available in the transaction we are validating. That’s why the indirection used in BIP65/BIP112 is clever: the transaction’s nLockTime/nSequence values are validated before entering the interpreter, and inside the interpreter, we just read those fields and check them against the stack parameters given to OP_CLTV/OP_CSV.
However, this indirection can result in transactions that are valid in the interpreter (and thus valid under relay policy, I believe) but can never be mined. See this PR in Bitcoin Core for examples of OP_CLTV transactions that pass relay rules but are unmineable due to BIP113’s median-time-past rules.