> > i doubt CTV is necessary nor sufficient for this
> I would be interested to hear more on this.
A lot of people have been conflating vaults and covenants, especially lately. I believe we should
differentiate more Bitcoin vaults, a scheme that defines a "staged transaction process" [0], and Bitcoin
covenants. I find that there was a lot of confusion spread around that. Everything was a vault, from the
marketing of a mobile wallet with a 2of3 account to a covenant scheme. ( :)
It led to the confusion that a Bitcoin covenant would be necessary in order to have a Bitcoin vault. It's
clever, i don't think it's practical).
Now, CTV is useful for Bitcoin vaults. For instance i believe it's useful to pre-commit to a Cancel
transaction directly in the Unvault Script. This matters a lot as today you need to be sure that your
watchtowers (or any other network monitor) have had the Cancel transaction signature of all participants in
the vault before you sign the Unvault transaction.
A covenant, as simple as CTV, fixes this. It makes sure that not only any Unvault you sign can be Canceled,
but also that when you spin up a new watchtower you don't need to send to it all the signatures for all the
current vaults. Of course you'd want to add some secret here to avoid the annoyance of all your Unvaults being
able to be canceled by some rando on the network. But you can derive them from a secret shared only once.
Also on the topic of reducing interactivity, i think that CTV or another more powerful covenants that allows
to commit to all parts of a transaction (for malleability) can be useful for the complicated issue of fee
bumping [2].
However, it's not sufficient. You are not going to be able to receive coins on a CTV that commits to the
Unvault (whose output would commit to either the Cancel immediately, or something else after a delay). It
would be an enormous footgun. For this, i believe something like TLUV with IN_OUT_AMOUNT [3] is a much more
interesting direction.
Furthermore, committing entirely to the withdrawal amounts in advance is very impractical. It is the one
largest UX barrier in my opinion. Users don't think in coins, but in amount to transfer. In order to have an
almost decent UX you would have to prepare a first stage transaction that creates a nice (what is nice? It's
very hard to reason about) distribution of coin amounts. This is a big tradeoff between usability and cost
(granularity). Of course it's not new to CTV, It's an issue today with Revault. It's just a problem faced by
today's implementation(s) (i don't know of any other "real" vault implementation) of Bitcoin vaults that CTV
does not solve.
I realise that you might not care to receive coins on a single-sig Script and have a vaulting step in a
single-party situation. I guess i just think vaults are more interesting in organisational situations, where a
set of participants only marginally trust another one (that may be a subset) and want to both limit the amount
they have access to and apply policies on how they would use the funds.
Antoine
[0] All vaults architectures i know of are characterized by the necessity to unlock the funds in multiple
stages, one of which is timelocked.
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html