I don't have a single work that explains fully why CTV is the best covenant proposal. I came to this opinion slowly after many years of studying bitcoin and lightning technical design and watching the debate play out.

I think the most convincing argument today is that many builders working on different problems have converged on the same, simple tool that enables or amplifies what they can build.

James O'Bierne has been working on vaults for years. First he designed a protocol using only CTV, then leveled it up into a distinct opcode, OP_VAULT, that did not use CTV. After incorporating feedback and improving his proposal he brought CTV back in because it was the best tool for the job. Now, OP_VAULT depends on CTV as an underlying primitive. I can't think of a stronger endorsement.

https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-0345.mediawiki

Ruben Somsen and Lloyd Fournier showed that CTV improves DLC efficiency by ~30x in the worst case.

https://mailmanlists.org/pipermail/dlc-dev/2022-January/000102.html

Greg Sanders built an LN-symmetry proof of concept and, in the process, found that using CTV simplified the protocol, removing round trips and improving payment times.

https://delvingbitcoin.org/t/ln-symmetry-project-recap/359

I haven't looked into Salvatore Ingala's MATT proposal but apparently he's planning to include CTV also. Maybe nostr:npub1775tuvua6h9mkmlqm3ragxpv3z3eegahhshydj36u2xq72vve9lsq29jcw can elaborate on this one.

The other thing that gives me conviction is the simplicity of CTV's design. Saint-Exupéry said that perfection is only achieved when there is nothing left to take away. I think it's clear that BIP119 embodies this principle. It's as simple as it can be to achieve its design goals. There is nothing left to take away.

Reply to this note

Please Login to reply.

Discussion

There's a bit of a confusion between the various proposals and CTV itself. Its job is to be a TXID lock and there's not a large design space for that. None of them are competitors to CTV. In fact, CTV has no competitors at all. It's constrained to a primitive and nothing can be added or removed. Jeremy had been working on a few proposals but dropped them in favor of CTV.

Post CTV and we have basic covenants in the market, we can better determine whether we wish for OP_VAULT or OP_CCV (matt). We'll also be able to better analyze whether we want TXHASH or TEMPLATE KEY. In both cases, it would best to have a primitive that acts as a keystone for all future upgrades.

One thing that is unclear to me is how do you commit to a TXID but then later spend those funds in a different way. This is a missing puzzle piece in my mental model.

Do you use a keypath spend? What about for non-taproot addresses? Do you use a different script branch? If so, how does someone really know their funds are safu on chain without monitoring the CTV UTXO to ensure it hasn't been spent out from under them using this other script path?

I think a simple script example would go a long way towards building understanding, definitely for me, hopefully for others as well.

thanks dude! very compelling I’ve got these all bookmarked for reading later!

I'm not positive CTV is the "best" proposal, but it is ready now, extremely low risk, and can be upgraded later in future soft forks to encompass further functionality as they are deemed safe (or not).

We can wait another 10 years for a potentially better proposal. In the mean time we will need to scale bitcoin using custodial solutions, locking out most of the world from self-sovereign bitcoin store of value. And after a decade we might find out that actually CTV was the best option, or that it is too late to ever soft fork again and we missed our window.

This wouldn't be the worst outcome, but I think the risk of doing nothing is greater than the risk from activating CTV.

Yeah, to be clear I'm pro activating CTV. In terms of capability I think it's effectively equivalent to creating an ephemeral key, signing exactly one transaction with it, then destroying the key.

CTV is 64-72 bytes more efficient on chain, however, and also avoids the risks of mishandling the ephemeral keys. If they're not properly handled you could be very screwed.

Since "base" CTV can already be simulated this way, I think the risk is essentially nil. Upgraded versions that do fancier things (like what TXHASH promises) could have potential unintended consequences though, of course, and should be heavily scrutinized as they're proposed.