On Fri, Apr 22, 2022 at 12:29 PM James O'Beirne via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

This vault design (https://github.com/jamesob/simple-ctv-vault)

is a good benchmark for evaluating covenant proposals because it's (i)
simple and (ii) has high utility for many users of Bitcoin. I would
love to see it implemented in one or all of these alternatives, but I
am almost certain no one will do it in the next few months because the
implementations, tooling, and in some cases even complete

specifications do not exist.

Quoting from the link above:

Detecting theft

This unvault step is critical because it allows us to detect unexpected behavior. If an attacker had stolen our hot wallet keys, their only choice to succeed in the theft is to trigger an unvault.

It's not the attackers *only choice to succeed*.  If an attacker steals the hot key, then they have the option to simply wait for the user to unvault their funds of their own accord and then race / outspend the users transaction with their own.  Indeed, this is what we expect would happen in the dark forest.

A key feature of the MES vault design is that the destination address is included, and committed to, by the unvaulting step.  However, this can only be achieved with a less constrained design for covenants.

I suppose I can see that the damage from a hot key theft could be more contained under some circumstances using a CTV vault, but let us not overstate the value of the CTV vault.

And that's not even mentioning the issues already noted by the document regarding fee management, which would likely also benefit from a less constrained design for covenants.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev