Perhaps its angels dancing on the heads of pins— but you can never check the validity of a signature without the scriptPubKeys, you can— however— check if the nlocktime is valid, e.g. and defer the more expensive operation of worrying about the signatures for transactions which have met their locktime requirements.
It also means that no transaction scheduling logic— e.g. code that decides if a transaction is locked yet needs to deal with scripts, and it means that the invariant that if a signature is invalid for a transaction is is always invalid, remains preserved (e.g. script remains a pure function with no non-deterministic inputs). E.g. you could still cache the entirety of script evaluation.
The downside with the criteria sniffing is that it's possible to have inputs with a mutually exclusive locktime type— e.g. two txins which can never be spent in the same transaction. This seemed inelegant to me, especially in contrast to the elegance of the rest of the approach. I still think it's better— just wish I had a way to avoid the risk of mutual exclusion. Obviously a receiver can just demand to use one type or the other.
Well one way to think about all this is that a script is valid in a given context. Currently that context is simply the transaction itself and the scriptPubKeys of previous transactions; my patch would expand that context to include the transaction and the current block height/time. Your version of the patch cleverly avoids having to expand the context.
We've already got good reason to expand the context to be at least the CTxOut's of previous transactions, and expanding it still further to include things like block hashes is a common request. If more such things were added I'd be inclined to formalize this notion of "Context" in the EvalScript() and so-on routines. Easy to see why you might not want to have to do that of course.
Pity Satoshi just didn't make transactions have a nLockHeight and nLockTime separately.
Another odd concern with locktime in general is that it's incompatible with the natural solution to the y2038 problem (which isn't a real problem for the rest of the system since you can just unwrap header timestamps into 64 bit values).
Well as we discussed before on -wizards, locktime usage with a timelock rather than a block height lock may create bad incentives for miners to skew timestamps anyway; might be a good idea to disable it entirely. Also, it's not the 2038 problem, it's later: nLockTime is unsigned.
Thanks very much for making the patch source available!
I try to get my head around about your conversation with Peter regarding to the implementation details, but I am not sure what is the better implementation Peter's or yours?
Well, they're both ideas at this point, not fully fledged "implementations" per-se. I'm sure quite sure what's the better approach; need to think through it all some more.
