MIME-Version: 1.0
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
 <d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com>
 <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org>
 <c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com>
 <CAPfvXfJe6YHViquT8i+Kq2QUjZDZyUq24nKkJd2a6dYKgygxNQ@mail.gmail.com>
In-Reply-To: <CAPfvXfJe6YHViquT8i+Kq2QUjZDZyUq24nKkJd2a6dYKgygxNQ@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Fri, 22 Apr 2022 13:25:12 -0400
Message-ID: <CAMZUoK=GONdGwj34PcqjV5sFJBg+XqiSOHFk4aQoTgy00YFG=Q@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f232ec05dd418243"
Subject: [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory")
	soft forks)
Precedence: list

--000000000000f232ec05dd418243
Content-Type: text/plain; charset="UTF-8"

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.

--000000000000f232ec05dd418243
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Apr 22, 2022 at 12:29 PM James O&=
#39;Beirne via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr">This vault design (<a href=3D"https://github.com/jamesob=
/simple-ctv-vault" target=3D"_blank">https://github.com/jamesob/simple-ctv-=
vault</a>)<br><div dir=3D"ltr">is a good benchmark for evaluating covenant =
proposals because it&#39;s (i)<br>simple and (ii) has high utility for many=
 users of Bitcoin. I would<br>love to see it implemented in one or all of t=
hese alternatives, but I<br>am almost certain no one will do it in the next=
 few months because the<br>implementations, tooling, and in some cases even=
 complete <br></div><div dir=3D"ltr">specifications do not exist.<br></div>=
</div></blockquote><div><br></div>Quoting from the link above:</div><div cl=
ass=3D"gmail_quote"></div><div class=3D"gmail_quote" style=3D"margin-left:4=
0px"><h3>Detecting theft</h3>
<p>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 i=
s to trigger an unvault.</p></div><div class=3D"gmail_quote"><p><br></p><p>=
It&#39;s not the attackers *only choice to succeed*.=C2=A0 If an attacker s=
teals 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.=C2=A0 Indeed, this is what we expect would hap=
pen in the dark forest.<br></p><p>A key feature of the MES vault design is =
that the destination address is included, and committed to, by the unvaulti=
ng step.=C2=A0 However, this can only be achieved with a less constrained d=
esign for covenants.</p><p>I suppose I can see that the damage from a hot k=
ey theft could be more contained under some circumstances using a CTV vault=
, but let us not overstate the value of the CTV vault.<br></p><p>And that&#=
39;s not even mentioning the issues already noted by the document regarding=
 fee management, which would likely also benefit from a less constrained de=
sign for covenants.<br></p></div></div>

--000000000000f232ec05dd418243--