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
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
|
Return-Path: <roconnor@blockstream.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 41E75C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 23 Apr 2022 19:31:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 3EA82408C7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 23 Apr 2022 19:31:10 +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: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key)
header.d=blockstream-com.20210112.gappssmtp.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ITEzLZ6daKKn
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 23 Apr 2022 19:31:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com
[IPv6:2607:f8b0:4864:20::72a])
by smtp4.osuosl.org (Postfix) with ESMTPS id E18F5408CB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 23 Apr 2022 19:31:08 +0000 (UTC)
Received: by mail-qk1-x72a.google.com with SMTP id a186so8184419qkc.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 23 Apr 2022 12:31:08 -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
:cc; bh=YbLEYlmWI7NWwpVyioK8oI6deWzrb0e1V+9P4EXIiU0=;
b=FD1YLpDokAw06mPThoxKeNsEhjzDadF/dykz3HLRxesTTgfdVy00XjxFQ93yvF/5lt
jibLH+WMRWn7So260gu13whWA5JxriLat/MBy9djaoCSkxcISk9Vtt2kZjyYAgk+8XWg
SLEbjkQB86wkpb/1rsdNLn0j5sI2QD7AsJtzNS/YI3WFFMsPMDlfRMQTo3tl64zSxpki
rop2f5PO8pvgRs5vD9S0CsTl/6AYBPvD3bbwvnvgx6kLcFHNDVBtOpByWyGifWuW9czV
GZOSaOx4RtuWW50gtdOJRfZMb+F+oN97QKVfpYFvYdWBkhm7gzTvDqsK/iz0Cecwi0A2
Znag==
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:cc;
bh=YbLEYlmWI7NWwpVyioK8oI6deWzrb0e1V+9P4EXIiU0=;
b=GCY/TZg4mAa6WLExV0SI9wjNl1Ba8jdRExqHjzShzorqo0KqfDdcTZKN1FXfTbxr42
VcixiuJ9JqTHQTD0x11+iXpewWSRBQfXfMNlcBvtDPIQlYHtnw2HzxOVmu2Zqo+w+q38
S0IXofqqWf9xFnQmmaiVlfvfwWNOI/8rJam5uDIJkLvUTnxcYFzdJchmweU63iKdsP3J
D0EGeaEZQNSm23aeTktWoCch9Ws5N5uEM6PaauBmpJzNkiormvqexW6dkH/NsikWNVpe
OHNoxNcSNO+cvkd0cqbkNsa1DD+ECmYzQNXczALWkABsV+R+HRafmOQnxW0zM6q8tl18
LVKg==
X-Gm-Message-State: AOAM531j05/81BIqcYg9OE+5N71JdsLO5XdUR3PCpjYPfy3njv/DecTv
74gzSnp8qY4rnMA+Y4o0/vN0kyJdL9n2/1iouVpvfc6pDnA=
X-Google-Smtp-Source: ABdhPJz69S0HbsPsOJsypF712Oq3T2gvz9bu3tfqNfUTGW7jexdxSkyHGdKZ3ZtFWgfH3VY+NwUSvHCAD3CFXLyQySs=
X-Received: by 2002:a05:620a:2484:b0:69e:e4d0:ca35 with SMTP id
i4-20020a05620a248400b0069ee4d0ca35mr6204358qkn.548.1650742267660; Sat, 23
Apr 2022 12:31:07 -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>
<CAMZUoK=GONdGwj34PcqjV5sFJBg+XqiSOHFk4aQoTgy00YFG=Q@mail.gmail.com>
<48a4546c-85b3-e9ff-83b5-60ba4eae2c76@mattcorallo.com>
In-Reply-To: <48a4546c-85b3-e9ff-83b5-60ba4eae2c76@mattcorallo.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Sat, 23 Apr 2022 15:30:56 -0400
Message-ID: <CAMZUoKniYvmtYXOOOqpDGyaEyzG5DObwbFQhvaYkndSnJUmvkg@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="0000000000007ae28c05dd5762ef"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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: Sat, 23 Apr 2022 19:31:10 -0000
--0000000000007ae28c05dd5762ef
Content-Type: text/plain; charset="UTF-8"
Okay, Matt explained to me the intended application of CTV vaults off list,
so I have a better understanding now.
The CTV vault scheme is designed as an improvement over the traditional
management of hot-wallets and cold-wallets. The CTV vault is logically on
the "cold-side" and lets funds be sent from the "cold" side to *one's own*
the hot wallet after the unvaulting delay. In this case, the hot wallet
funds are always at risk, so it isn't unexpected that those funds could be
stolen. After all, that is how hot wallets are today. The advantage is
that funds can be moved from the "cold" side without needing to dig out the
cold keys.
The MES vault scheme applies to a different scenario. In the MES case it
is the hot funds are inside the vault, and it is the hot key that unvaults
the funds and sends them to *customer's addresses* after a delay. If the
hot-key is used in any unauthorised way, then funds can be sent to the
address of the cold key (the MES vault actually does something fancy in
case of recovery, but it could be adapted to simply send funds to a cold
wallet).
The MES vault lie somewhere between "better" and "different" when compared
to the CTV vault. If one is unwilling to use the MES vault on the hot side
and have every withdrawl vetted, then, while you could use the MES design
on the cold side like the CTV vault, it wouldn't really offer you any
advantages over a CTV vault. However, if you are interested in managing
all your payments through a vault (as I've been imagining) then the CTV
vault comes across as ineffective when compared to an MES style vault.
On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:
> Still trying to make sure I understand this concern, let me know if I get
> this all wrong.
>
> On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
> > 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.
>
> Right, a key security assumption of the CTV-based vaults would be that you
> MUST NOT EVER withdraw
> more in one go than your hot wallet risk tolerance, but given that your
> attack isn't any worse than
> simply stealing the hot wallet key immediately after a withdraw.
>
> It does have the drawback that if you ever get a hot wallet key stole you
> have to rotate all of your
> CTV outputs and your CTV outputs must never be any larger than your hot
> wallet risk tolerance
> amount, both of which are somewhat frustrating limitations, but not
> security limitations, only
> practical ones.
>
> > 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.
>
> Of course I've always been in favor of a less constrained covenants design
> from day one for ten
> reasons, but that's a whole other rabbit hole :)
>
--0000000000007ae28c05dd5762ef
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Okay, Matt explained to me the intended application o=
f CTV vaults off list, so I have a better understanding now.</div><div><br>=
</div><div>The CTV vault scheme is designed as an improvement over the trad=
itional management of hot-wallets and cold-wallets.=C2=A0 The CTV vault is =
logically on the "cold-side" and lets funds be sent from the &quo=
t;cold" side to *one's own* the hot wallet after the unvaulting de=
lay.=C2=A0 In this case, the hot wallet funds are always at risk, so it isn=
't unexpected that those funds could be stolen.=C2=A0 After all, that i=
s how hot wallets are today.=C2=A0 The advantage is that funds can be moved=
from the "cold" side without needing to dig out the cold keys.<b=
r></div><div><br></div><div>The MES vault scheme applies to a different sce=
nario.=C2=A0 In the MES case it is the hot funds are inside the vault, and =
it is the hot key that unvaults the funds and sends them to *customer's=
addresses* after a delay.=C2=A0 If the hot-key is used in any unauthorised=
way, then funds can be sent to the address of the cold key (the MES vault =
actually does something fancy in case of recovery, but it could be adapted =
to simply send funds to a cold wallet).</div><div><br></div><div>The MES va=
ult lie somewhere between "better" and "different" when=
compared to the CTV vault.=C2=A0 If one is unwilling to use the MES vault =
on the hot side and have every withdrawl vetted, then, while you could use =
the MES design on the cold side like the CTV vault, it wouldn't really =
offer you any advantages over a CTV vault.=C2=A0 However, if you are intere=
sted in managing all your payments through a vault (as I've been imagin=
ing) then the CTV vault comes across as ineffective when compared to an MES=
style vault.<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo <<a href=
=3D"mailto:lf-lists@mattcorallo.com">lf-lists@mattcorallo.com</a>> wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Still trying t=
o make sure I understand this concern, let me know if I get this all wrong.=
<br>
<br>
On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:<br>
> It's not the attackers *only choice to succeed*.=C2=A0 If an attac=
ker steals the hot key, then they have <br>
> the option to simply wait for the user to unvault their funds of their=
own accord and then race / <br>
> outspend the users transaction with their own.=C2=A0 Indeed, this is w=
hat we expect would happen in the <br>
> dark forest.<br>
<br>
Right, a key security assumption of the CTV-based vaults would be that you =
MUST NOT EVER withdraw <br>
more in one go than your hot wallet risk tolerance, but given that your att=
ack isn't any worse than <br>
simply stealing the hot wallet key immediately after a withdraw.<br>
<br>
It does have the drawback that if you ever get a hot wallet key stole you h=
ave to rotate all of your <br>
CTV outputs and your CTV outputs must never be any larger than your hot wal=
let risk tolerance <br>
amount, both of which are somewhat frustrating limitations, but not securit=
y limitations, only <br>
practical ones.<br>
<br>
> And that's not even mentioning the issues already noted by the doc=
ument regarding fee management, <br>
> which would likely also benefit from a less constrained design for cov=
enants.<br>
<br>
Of course I've always been in favor of a less constrained covenants des=
ign from day one for ten <br>
reasons, but that's a whole other rabbit hole :)<br>
</blockquote></div></div>
--0000000000007ae28c05dd5762ef--
|
