> I don't think implementing a CTV opcode that we expect to largely
be obsoleted by a TXHASH at a later date is yielding good value from a
soft fork process.
This presumes the eventual adoption of TXHASH (or something like it). You're presenting a novel idea that, as far as I know, hasn't had much time to bake in public. Like Jeremy, I'm concerned by the combinatorial growth of flags and the implications that has for testing. Caching for something like TXHASH looks to me like a whole different ballgame relative to CTV, which has a single kind of hash.
Let's not overstate the concern around the combinatorics
of TXHASH. It's not like there is a vast amount of cross-flag interaction we are talking about here. There are also a combinatorial number of ways of assembling
opcodes in Bitcoin script, but we aren't required to exhaustively test every single
possible Script program.
Even if we were to adopt something like TXHASH, how long is it going to take to develop, test, and release? My guess is "a while" - in the meantime, users of Bitcoin are without a vault strategy that doesn't require either presigning transactions with ephemeral keys (operationally difficult) or multisig configurations that would make Rube Goldberg blush (operationally difficult and precarious). The utility of vaulting seems underappreciated among consensus devs and it's something I'd like to write about soon in a separate post.
> The strongest argument I can make in favour of CTV would be something
like: "We definitely want bare CTV and if we are going to add CTV to
legacy script (since we cannot use TXHASH in legacy script), then it is
actually easier not to exclude it from tapscript, even if we plan to add
TXHASH to tapscript as well."
Another argument for CTV (which I find especially persuasive) is its simplicity - it's relatively easy to reason about and, at this point, pretty well understood. It seems like a low-risk change relative to some of the other covenant proposals, nearly all of which elicit a good deal of headscratching (at least from me) and seem to require not only larger on-chain footprints but sizable code changes.
> I am sensitive to technical debt and soft fork processes
If OP_CTV ends up being the most practical approach for vaulting - among other things - in terms of weight (which it seems to be at the moment) I don't think "technical debt" is an applicable term.
Technical debt isn't a measure of weight of transactions. It's a measure of the code complexity needed to implement, in this case, a Bitcoin Script interpreter.
By itself, adding a single new hash format for CTV isn't that complex, and it is certainly simpler than this TXHASH proposal. But then we need to add another two slightly different hash formats for APO support. And tomorrow we will need yet another set of transaction hash formats for the next thing, and so on, with each instance requiring going through its own soft-fork process. It is at that point we end up with something more complicated and with more deployment risk than if we had just done something like TXHASH at the very beginning. But unlike other programming environments, we cannot refactor our way out of such a situation. We cannot make a new script version while deprecating the old one. Our only option here is to be mindful of the long term implications of the design choices we are making today.