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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1AEF8C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Sep 2020 00:19:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id EFF3887389
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Sep 2020 00:19:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id M360axDMlm-J
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Sep 2020 00:19:54 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch
[185.70.40.137])
by hemlock.osuosl.org (Postfix) with ESMTPS id C58D187388
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Sep 2020 00:19:53 +0000 (UTC)
Date: Thu, 24 Sep 2020 00:19:48 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1600906791;
bh=891UFWXAbMsjvhwe/QUu3BEBtrrUh4E7uHW78b/pmoY=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=CiavbUFiVAhfW/MZW2pO3mK6PrQ+e41H9tQKwcbIFHgdbZKUIdJ/yPKwWJcp/TVeQ
BTQtLFPfFBOCYpHOuisCcGKMKOIQk6bdQt2oCrff3MO4fk+u5ur7REmXBimjoZj0yx
KxaJGU6wF/J8WwRIY2ZRA2RGQWkfceRuY3cDH3KY=
To: Tom Trevethan <tom@commerceblock.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <CYPuSF4lMyhP0L21Z5fC45i_nIMdh2XLrFio4-BE3ci6YQ5CYbpjjq-aaimP3AuwND4ah6yN5PWcDGuKvg_jkBxwsXA9aWfQmK9YjJrB-RA=@protonmail.com>
In-Reply-To: <CAJvkSsfJ-ep_WA1gCCBUeLUF4FKoXiCQ+t+c6KnOUQx8xEbH_Q@mail.gmail.com>
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>
<CAJvkSsfJ-ep_WA1gCCBUeLUF4FKoXiCQ+t+c6KnOUQx8xEbH_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Thu, 24 Sep 2020 00:19:56 -0000
Good morning Tom,
> Hi ZmnSCPxj,
>
> > The SE can run in a virtual environment that monitors deletion events a=
nd records them.
> > Such a virtual environment could be set up by a rootkit that has been i=
nstalled on the SE hardware.
> > Thus, even if the SE is honest, corruption of the hardware it is runnin=
g on can allow recovery of old privkeys and violation of the tr\*st assumpt=
ion.
>
> This is true, but this threat can be mitigated with secured infrastructur=
e and the use of hardware security modules/trusted execution environments t=
hat enable secure (and potentially attestable) deletion.=C2=A0
>
> > Compare this to, for example, TumbleBit or Wasabi.
> > In those cases, even if the service providing the mixing is corrupted b=
y a rootkit on the hardware running the honest service software in a virtua=
l environment and monitoring all its internal state and communications, the=
y cannot lead to loss of funds even with cooperation of previous participan=
ts.
> >They can at most be forced into denial-of-service, but not outright thef=
t of coins.
>
> Yes, I agree. But on the other side of the scale is a comparison with cen=
tralised mixing services, which remain extremely popular.=C2=A0
>
> > I admit the new solution is superior blockspace-wise, if you consider m=
ultiple mixing rounds.=C2=A0
>
> The aim of the solution is to replicate the UX (in terms of speed) of a c=
ompletely 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 mo=
re difficult (requiring collusion=C2=A0with previous owners), has an in-bui=
lt 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 p=
rivacy guarantees as the above mentioned trust-minimised protocols.=C2=
=A0
I believe the slowness of TumbleBit and Wasabi have less to do with securit=
y than with gathering enough participants to get a reasonable anonymity set=
.
If the statechain entity itself does not participate and put up funds that =
its clients can acquire quickly, than a similar waiting period would be nec=
essary anyway to gather enough participants to make the swapping worthwhile=
.
This would then fail your goal of speed.
If the statechain entity *does* act as a participant, then a client could a=
cquire a new coin fairly quickly (as the statechain entity would be a "part=
icipant of last resort" with which it could swap right now), but the "previ=
ous participant" in that case would be the statechain entity itself, making=
its ability to outright steal funds absolutely certain, and thus not much =
better than a mixer that provides "put money in this address, I will send y=
ou money in your address" service.
(unless I can do a cut-and-choose on the hardware, i.e. buy multiple instan=
ces and reverse-engineer all except a randomly-selected one to check for ha=
rdware defects that may allow extraction of privkeys, and then use the hard=
ware that remains, I do not think the security of TEEs/HSMs is at all high.
And the TEE/HSM would be directly possessed by the statechain entity and no=
t me, presumably I as client of the statechain entity cannot audit that, so=
---)
If you are going to have a maker-taker model, where takers spend money to g=
et immediate swaps for the time that makers spend waiting, then I suggest t=
hat the SwapMarket plan by Chris Belcher would only require some number of =
confirmations of various transactions to get superior security, which would=
be a better tradeoff than what statechains provide.
Regards,
ZmnSCPxj
|
