Some thoughts on OP_CHECKTEMPLATEVERIFY (thread)
There are two ways of approaching adding covenants to Bitcoin: recursive and hash chained. Recursive is what you expect with each coin explicitly constructing its children. Hash chained is where each coin refers to outputs by their secure hash.
The problem with hash chained is that you have to precompute everything which can possibly happen, or at least components of each thing. Since most vaults have a single sequential thread of things which happen this is entirely doable for millions of generations out, which
is never going to happen in practice, so it effectively acts evergreen. Despite being less flexible than full-blown recursion hash chaining has a lot going for it. It requires a lot less of the underlying language, and it only needs reveals of exactly the logic used at
each step. This compression matters much more than you'd expect: Recursive covenants wind up having 'large' programs in blockchain size terms, like over a kilobyte. Those can be compressed because they often use the same templates, but compressing transactions
like that is verboten in Bitcoin land because it makes the first transaction much more expensive than the later ones making transaction inclusion a very non-one-dimensional optimization problem. I don't think it's that bad because new transactions can't make other
transactions more expensive, only cheaper, so there aren't serious censorship issues, but it still is very anathema to the Bitcoin core team. Ironically the biggest problem with hash chain covenants is that they're very hard to use. Even though the demands on the chain are
simple that complexity is offloaded to the endpoints, which need to pregenerate a whole chain of possible future things and keep track of where they are in it. To date we only have a few hand-rolled examples of this which were made specifically for OP_CHECKTEMPLATEVERIFY and
There's no general purpose tooling, so this will continue to be painful for a while. Still, secure hash chains support both secure the bag and vaults, both of which are important and fairly general uses. At this point in time secure hash chaining is clearly the right approach to
adding covenant functionality to Bitcoin if it's added at all, and CTV is a reasonable implementation of that. My main main quibbles are in the details. I think txid predictability isn't usually that important and what you really want to chain out are the scriptpubkeys but
doing that isn't well supported until you hash sha streaming. Also on the ancillary proposal for allowing peer transactions to pay fees the dependencies should be on txids being spent instead of the whole transaction because that keeps transactions from dipping into
things which are none of their business, or at least enables less of it. So on the whole I come down on OP_CTV being a solidly good thing, modulo quibbles about implementation details, of which there still may be many.
