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
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
|
Return-Path: <tom@commerceblock.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7132AC0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Sep 2020 15:32:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 4EB6B866F4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Sep 2020 15:32:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id vK9njxSWCW3x
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Sep 2020 15:32:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ej1-f66.google.com (mail-ej1-f66.google.com
[209.85.218.66])
by whitealder.osuosl.org (Postfix) with ESMTPS id DA62A866E3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Sep 2020 15:32:18 +0000 (UTC)
Received: by mail-ej1-f66.google.com with SMTP id i26so23457322ejb.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Sep 2020 08:32:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=commerceblock-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=5+8gNsnzfpTW0TlKb5SWz/CQG1PDECabrDC123NFXFU=;
b=Qkx/wvswFVvSJUV7+2UxmIetvA8w6NFWMuOGHxyUm/Bc3LtOwb6WeasgN3uWkD1lK1
OU0U5YEbGBOZzFJg8EQNpL5Jzx9k6hdHB81IHjj7dVlpEdDbKAyDZhY/qS84ln5kWeAq
fnMNet8kqkGeQtYcvmF25cBStlf+VomTn5FgIn3exjYPS84ojsy2psveU8C1QGKpl7ps
wxinQxLAO9arIIMLb7Dcf90nj19dtAwU15OS4EEBOHnMpUBoB90Oz1yBYcmuLRID5/lg
SRbzT3n2zOvR4SvQzfs3hcCNETt59aiF0VmZxihgzttXmdRpXcK15PnPa9oNGT7Jb77T
me+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=5+8gNsnzfpTW0TlKb5SWz/CQG1PDECabrDC123NFXFU=;
b=Xrhxi27AVRoXd9a4grStuTS7gQP7PElrfq8MIROHCYu/+p763/iXbdM+8MSskemd3E
9CLMXbaZ0Kis4XogoeG9VT5yzB6jIGezBoM/fTuO+TbBg3jEd9CXVDKQ1+ZYl9YxIhFh
pl/z3i+odOq+RmwPk+CJfoeJlIrcaujCqKAsRKdu/DrM+cwILtuqrh5zOLugeP0zkWGD
jw6ej4uPaZQ04afmdsH8e9O3GhhXP/nkerIRSvUMWJfFcmLIKJy8CakSAir+/IjvLRYo
LExwXrEC/LDyJuq8zYuV6LZR6NZ3vsGnSjn/e+9XQVO/YvYZnnVTxO7N4c+iYtcehVhV
i5fw==
X-Gm-Message-State: AOAM532rOKg/RcwrxYbUQ+6inI+81R6wgnd4vqoI6c9umvzWT5W2QlBD
iYx8OzFmqe12G0IF1/KJ2X/Y53PW6ttPnxH//VQL
X-Google-Smtp-Source: ABdhPJwk9GFQz9XxNZPBu6pFaFd2t90Pcu/Tv/ktOsR9NhsLJvwZg1fbxNs1PC33yCXmngtvFi6wQn1eGtfjg316RLw=
X-Received: by 2002:a17:906:9a1:: with SMTP id q1mr5475030eje.30.1600788737085;
Tue, 22 Sep 2020 08:32:17 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSseOx8mwYowLEnfKVEUuM5xsiYkbLdAvtaYxPpu4jY9pCg@mail.gmail.com>
<2Abk4Gqv5hJyGtA8Gg1WCP5RNuyUFkmRn1uUKp_mdUaXrRTz4SDBTPi0MGU7D5jj36VSzrqsIiO5lMR4gGRApRX2jyp8vXDeHBnFt-6ca-g=@protonmail.com>
<CAJvkSse5GDxzrDc0OeNSoHV90tsSvr-oCgY_P+p4O4T6PDUNpA@mail.gmail.com>
<TC2UtcaDKCIkjtn41sIutqApciyqaGCD3SBSEWLBk4OT12siSkWIsp2LMmlmA0CLzUNuG1W8w-hB4Pq3ko1uGwbxpjxezFWKPq4C7OLUQo8=@protonmail.com>
<CAJvkSseWZYH-dOvkFXmtKJgJOfv09La8sTb4e+2nvZYKTxNafg@mail.gmail.com>
<KRJoyx0BjttYJnlGVY3hu2T_1bTPcpU1Vq639OYyQptXx6Xm0vkrCN-23ngBK3fs0ti2dT4i4LHIxOaxqNMACJ9N27jPqoPqzaBpxiOIH8s=@protonmail.com>
In-Reply-To: <KRJoyx0BjttYJnlGVY3hu2T_1bTPcpU1Vq639OYyQptXx6Xm0vkrCN-23ngBK3fs0ti2dT4i4LHIxOaxqNMACJ9N27jPqoPqzaBpxiOIH8s=@protonmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Tue, 22 Sep 2020 16:32:06 +0100
Message-ID: <CAJvkSsfJ-ep_WA1gCCBUeLUF4FKoXiCQ+t+c6KnOUQx8xEbH_Q@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000008f04605afe8ac4e"
X-Mailman-Approved-At: Tue, 22 Sep 2020 15:38:03 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure
in a two-stage transfer protocol.
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: Tue, 22 Sep 2020 15:32:20 -0000
--00000000000008f04605afe8ac4e
Content-Type: text/plain; charset="UTF-8"
Hi ZmnSCPxj,
> The SE can run in a virtual environment that monitors deletion events and
records them.
> Such a virtual environment could be set up by a rootkit that has been
installed on the SE hardware.
> Thus, even if the SE is honest, corruption of the hardware it is running
on can allow recovery of old privkeys and violation of the tr\*st
assumption.
This is true, but this threat can be mitigated with secured infrastructure
and the use of hardware security modules/trusted execution environments
that enable secure (and potentially attestable) deletion.
> Compare this to, for example, TumbleBit or Wasabi.
> In those cases, even if the service providing the mixing is corrupted by
a rootkit on the hardware running the honest service software in a virtual
environment and monitoring all its internal state and communications, they
cannot lead to loss of funds even with cooperation of previous participants.
>They can at most be forced into denial-of-service, but not outright theft
of coins.
Yes, I agree. But on the other side of the scale is a comparison with
centralised mixing services, which remain extremely popular.
> I admit the new solution is superior blockspace-wise, if you consider
multiple mixing rounds.
The aim of the solution is to replicate the UX (in terms of speed) of a
completely centralised mixer (i.e. where the server(s) explicitly holds the
full key(s) to the deposits being swapped) but in a way that makes theft
more difficult (requiring collusion with previous owners), has an in-built
mechanism for users to get back their funds if the service is shut
down/blown-up, provides users with proof of ownership/theft, and with the
same privacy guarantees as the above mentioned trust-minimised protocols.
Cheers,
Tom
On Tue, Sep 22, 2020 at 2:00 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning Tom,
>
> > Hi ZmnSCPxj,
> >
> > > I think the entire point of non-custodiality ***is*** trust
> minimization.
> >
> > There are also legal and regulatory implications. It is much easier for
> a service to operate without requiring its users to be KYCed if it is
> non-custodial and funds cannot be frozen/seized.
>
> Complying with the letter of the law without complying to its spirit seems
> rather hair-splitting to me.
>
> Ideally, a law regarding any financial mechanisms would judge based on how
> much control the purported owner has over the actual coin and what risks it
> would entail for them, and protect citizens against risk of damage to their
> finances, not focus on whether storage is "custodial" or not.
>
> So I still suggest that, for purposes of technical discussion, we should
> avoid the term "custodial" and instead consider technical risks.
>
> >
> > > The main objection against custodiality is that someone else can
> prevent you from spending the coin.
> > > If I have to tr\*st the SE to not steal the funds, is it *really*
> non-custodial, when after a swap, a corrupted SE can, in collusion with
> other participants, take control of the coin and prevent me from spending
> it as I wish?
> >
> > I would argue that it is non-custodial if the SE performs the protocol
> as specified (i.e. securely deleting expired key shares).
>
> The SE can run in a virtual environment that monitors deletion events and
> records them.
> Such a virtual environment could be set up by a rootkit that has been
> installed on the SE hardware.
> Thus, even if the SE is honest, corruption of the hardware it is running
> on can allow recovery of old privkeys and violation of the tr\*st
> assumption.
>
> Compare this to, for example, TumbleBit or Wasabi.
> In those cases, even if the service providing the mixing is corrupted by a
> rootkit on the hardware running the honest service software in a virtual
> environment and monitoring all its internal state and communications, they
> cannot lead to loss of funds even with cooperation of previous participants.
> They can at most be forced into denial-of-service, but not outright theft
> of coins.
>
> Thus, I believe this solution is inferior to these older solutions, at
> least in terms of financial security.
>
> I admit the new solution is superior blockspace-wise, if you consider
> multiple mixing rounds.
> However, multiple mixing rounds under this solution have increased
> exposure to the risk of theft noted above, and thus it would be better,
> risk-wise, to immediately withdraw after every round, and potentially seek
> other SEs (to reduce risks arising from a particular SE being corrupted),
> thus obviating the blockspace savings.
>
>
> The above remain true regardless of what definition of "custodial" you
> have.
>
> Regards,
> ZmnSCPxj
>
--00000000000008f04605afe8ac4e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"color:rgb(80,0,80)">Hi ZmnSCPxj,</span><br>=
<div><span style=3D"color:rgb(80,0,80)"><br></span></div><div>> The SE c=
an run in a virtual environment that monitors deletion events and records t=
hem.<br>> Such a virtual environment could be set up by a rootkit that h=
as been installed on the SE hardware.<br>> Thus, even if the SE is hones=
t, corruption of the hardware it is running on can allow recovery of old pr=
ivkeys and violation of the tr\*st assumption.<span style=3D"color:rgb(80,0=
,80)"><br></span></div><div><br></div><div>This is true, but this threat ca=
n be mitigated with secured infrastructure and the use of hardware security=
modules/trusted execution environments that enable secure (and potentially=
attestable) deletion.=C2=A0</div><div><br></div><div>> Compare this to,=
for example, TumbleBit or Wasabi.<br>> In those cases, even if the serv=
ice providing the mixing is corrupted by a rootkit on the hardware running =
the honest service software in a virtual environment and monitoring all its=
internal state and communications, they cannot lead to loss of funds even =
with cooperation of previous participants.<br>>They can at most be force=
d into denial-of-service, but not outright theft of coins.<br></div><div><b=
r></div><div>Yes, I agree. But on the other side of the scale is a comparis=
on with centralised mixing services, which remain extremely popular.=C2=A0<=
/div><div><br></div><div>> I admit the new solution is superior blockspa=
ce-wise, if you consider multiple mixing rounds.=C2=A0<br></div><div><br></=
div><div>The aim of the solution is to replicate the UX (in terms of speed)=
of a completely centralised mixer (i.e. where the server(s) explicitly hol=
ds the full key(s) to the deposits being swapped) but in a way that makes t=
heft more difficult (requiring collusion=C2=A0with previous owners), has an=
in-built mechanism for users to get back their funds if the service is shu=
t down/blown-up, provides users with proof of ownership/theft, and with the=
same privacy guarantees as the above mentioned trust-minimised protocols.=
=C2=A0</div><div><br></div><div>Cheers,</div><div><br></div><div>Tom</div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Tue, Sep 22, 2020 at 2:00 AM ZmnSCPxj <<a href=3D"mailto:ZmnSCPxj@prot=
onmail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>> wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Tom,<br>
<br>
> Hi ZmnSCPxj,<br>
><br>
> >=C2=A0I think the entire point of non-custodiality ***is*** trust =
minimization.<br>
><br>
> There are also legal and regulatory implications. It is much easier fo=
r a service to operate without requiring its users to be KYCed if it is non=
-custodial and funds cannot be frozen/seized.=C2=A0<br>
<br>
Complying with the letter of the law without complying to its spirit seems =
rather hair-splitting to me.<br>
<br>
Ideally, a law regarding any financial mechanisms would judge based on how =
much control the purported owner has over the actual coin and what risks it=
would entail for them, and protect citizens against risk of damage to thei=
r finances, not focus on whether storage is "custodial" or not.<b=
r>
<br>
So I still suggest that, for purposes of technical discussion, we should av=
oid the term "custodial" and instead consider technical risks.<br=
>
<br>
><br>
> > The main objection against custodiality is that someone else can =
prevent you from spending the coin.<br>
> > If I have to tr\*st the SE to not steal the funds, is it *really*=
non-custodial, when after a swap, a corrupted SE can, in collusion with ot=
her participants, take control of the coin and prevent me from spending it =
as I wish?<br>
><br>
> I would argue that it is non-custodial if the SE performs the protocol=
as specified (i.e. securely deleting expired key shares).<br>
<br>
The SE can run in a virtual environment that monitors deletion events and r=
ecords them.<br>
Such a virtual environment could be set up by a rootkit that has been insta=
lled on the SE hardware.<br>
Thus, even if the SE is honest, corruption of the hardware it is running on=
can allow recovery of old privkeys and violation of the tr\*st assumption.=
<br>
<br>
Compare this to, for example, TumbleBit or Wasabi.<br>
In those cases, even if the service providing the mixing is corrupted by a =
rootkit on the hardware running the honest service software in a virtual en=
vironment and monitoring all its internal state and communications, they ca=
nnot lead to loss of funds even with cooperation of previous participants.<=
br>
They can at most be forced into denial-of-service, but not outright theft o=
f coins.<br>
<br>
Thus, I believe this solution is inferior to these older solutions, at leas=
t in terms of financial security.<br>
<br>
I admit the new solution is superior blockspace-wise, if you consider multi=
ple mixing rounds.<br>
However, multiple mixing rounds under this solution have increased exposure=
to the risk of theft noted above, and thus it would be better, risk-wise, =
to immediately withdraw after every round, and potentially seek other SEs (=
to reduce risks arising from a particular SE being corrupted), thus obviati=
ng the blockspace savings.<br>
<br>
<br>
The above remain true regardless of what definition of "custodial"=
; you have.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>
--00000000000008f04605afe8ac4e--
|