Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-22 📝 Original message:On Fri, Apr 22, 2022 at ...
📅 Original date posted:2022-04-22
📝 Original message:On Fri, Apr 22, 2022 at 12:29 PM James O'Beirne via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220422/a55ab1e9/attachment.html>;
📝 Original message:On Fri, Apr 22, 2022 at 12:29 PM James O'Beirne via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220422/a55ab1e9/attachment.html>;