On Fri, Jan 28, 2022 at 10:14 AM James O'Beirne <james.obeirne@gmail.com> wrote:
> Technical debt isn't a measure of weight of transactions.

Sorry, my original sentence was a little unclear. I meant to say that the notion that CTV is just a subpar waypoint en route to a more general covenant system may not be accurate if it is a more efficient way (in terms of chainstate/weight) to express highly useful patterns like vaults. In that case, characterizing CTV as technical debt wouldn't be right.

It only costs a few more weight units, on the order of 2 or 3, to use TXHASH in place of CTV.  Notably, the reverse, using CTV in place of TXHASH, is much more expensive, requiring more than 32 weight units.
 
> Our only option here is to be mindful of the long term implications of the design choices we are making today.

Your points are well taken - I don't think anyone is arguing against thinking hard about consensus changes. But I have yet to see a proposal for covenants that is as efficient on-chain and easy to reason about as CTV is.

I also think there's some value in "legging into" covenants by deploying a simple, non-recursive construction like CTV that services some very important uses, and then taking as much time as necessary to think about how to solve more existential problems, like UTXO scalability, that likely require a recursive covenant construction.

There doesn't have to be mutual exclusion in the approaches, especially when the maintenance burden of CTV seems to be so low. If we end up deploying something that requires a wider variety of in-script hashing, it seems likely that CTV's hash will be able to "free ride" on whatever more general sighash cache structure we come up with.

Perhaps there is some misunderstanding.  TXHASH + CSFSV doesn't allow for complex or recursive covenants.  Typically CAT is needed, at minimum, to create those sorts of things.  TXHASH still amounts to deploying a non-recursive covenant construction.

With regards to CTV, in short my primary criticisms are (1) Push semantics is preferable to verify semantics, because simulating verify semantics from push is cheap, while simulating push semantics from verify is not particularly cheap.
And (2) given Push semantics we ought to have parameters to support both CTV-style hashes and APO-style hashes (which in the presence of CSFSV gives us APO applications), and, while we are at it, as many other style hashes as we can reasonably devise so we don't have to go through yet another soft-fork process every time someone comes up with a new subset of transaction data they would like to be hashed for their application.

I understand why CTV was designed with verify semantics: it would like to be NOP compatible.  That certainly made sense pre-tapscript.  I just haven't (yet) found the use cases for that compatibility to be compelling in a post-tapscript world.