1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
Return-Path: <roconnor@blockstream.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9E929C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 17:25:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 85BA383EB7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 17:25:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key)
header.d=blockstream-com.20210112.gappssmtp.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id QgpCzM3xv_uu
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 17:25:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com
[IPv6:2607:f8b0:4864:20::830])
by smtp1.osuosl.org (Postfix) with ESMTPS id 688F783DF7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 17:25:24 +0000 (UTC)
Received: by mail-qt1-x830.google.com with SMTP id hf18so6010785qtb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 10:25:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-com.20210112.gappssmtp.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=VCnx0astiHB9Yifhob5aBMA/BcYoyNwG0Lt3vZVEq8o=;
b=Dxs+X4FKKy3+VRpz50T3O94AhKCqEoWf6oHg4nRZFjZnEuZT/MjMMw+0hTTtYgTB1I
v5Lute+Adc+qafGePZgPrMRkcCeZGRaMKofXidUKpjdvMW9bP1L+Pz2tn4/xS5blcGch
U4RSni8rP4q9Y8SP+eSF1H87eS+wzVT3vBXNgSqhtOW0E4s4FCLYVlaLv0CqBL2QMQWA
hDMlUZr5ypEqVkCpW1JuWySfrU1QypXo1wusdj6j+pDOmxfUo4o8s0H2rPnH/3uVjsmb
TpcLMmxsnai/6nX2/1OiqbJyqYQPFP6Da2/7CSwpHENvLxNSiaOfGzDd1htoRtJ4IQGu
vvzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=VCnx0astiHB9Yifhob5aBMA/BcYoyNwG0Lt3vZVEq8o=;
b=0znE7N7hWP5/KUd//thnwdq3JfANLiOnUzcQjtOl3dwVzmyl0CT5YEd8C0zWZoV8JB
4js12tpWADFzoOZWYRB2TGJhSYntLG/jGMPiWk7wjQDyUO9ru88CXMmdVuLkZiNSlazm
d8MVUcqQWmC48X4sex/n2vmqL+mdSt+m1VMKA9wTiOnVCRbZqjK3J5GTIApE71BtQuXy
HwVNQOeF0dNhd8R6/GJmEzrcA69mal+Jtch5j+Bk8oKteuXNkusRyPLPWrzZABXf2lzM
CB4P7Rn6wepJvWuId7tnVDUsxPwWwrgSP1+kRNA2FJGtYIYagB/Iuzso+DQnpf53ehyi
F1GQ==
X-Gm-Message-State: AOAM530WCBJiE7LK7nKHue4wB9OY4b7hlg/UnO5obAdbFI+9ANINqQ+U
np1Fixkt/cT5Zt7TA4FY1MAnJsZ7+LbhgIFV1fKkyOvK1qUSPQ==
X-Google-Smtp-Source: ABdhPJwvxw2dqNEnUHII2SOz+RyGqyUX/vvujJGvMZmZGSfeQRavwi9Xg8c1V3856gQ/a66lXj6OSJYGgvELKe9lR0Q=
X-Received: by 2002:a05:622a:118b:b0:2f2:163:d2da with SMTP id
m11-20020a05622a118b00b002f20163d2damr4042885qtk.677.1650648323070; Fri, 22
Apr 2022 10:25:23 -0700 (PDT)
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)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2022 17:25:25 -0000
--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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org">bitcoin-dev@lists.linuxfoundation.org</a>> 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'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'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--
|
