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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 22B85C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Sep 2020 01:00:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 081B68601B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Sep 2020 01:00:56 +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 FDOcd5KLDbCh
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Sep 2020 01:00:54 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by whitealder.osuosl.org (Postfix) with ESMTPS id 3AF6C85FC0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Sep 2020 01:00:54 +0000 (UTC)
Date: Tue, 22 Sep 2020 01:00:43 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1600736451;
bh=hVdrlPRvnyfVxrf32DuOXz+Aq3gkNLHROThclfoxqi4=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=taOUBo5jot/6lIZSuMVteVrB3Wmcevb/Z8d32e/+AEul6YIHmd+hZQecyRAdMdaZW
Z4H7sW4aaQ0SwLhR2nkkwRlAk65LO9fGz+kEFgkqEMk8Dr9dAnZEbpgTahxpTuuFeq
+r53WTuDMDAoqUMeeKtXo5aREmYUT1mFQ2DO8zs8=
To: Tom Trevethan <tom@commerceblock.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <KRJoyx0BjttYJnlGVY3hu2T_1bTPcpU1Vq639OYyQptXx6Xm0vkrCN-23ngBK3fs0ti2dT4i4LHIxOaxqNMACJ9N27jPqoPqzaBpxiOIH8s=@protonmail.com>
In-Reply-To: <CAJvkSseWZYH-dOvkFXmtKJgJOfv09La8sTb4e+2nvZYKTxNafg@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>
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: Tue, 22 Sep 2020 01:00:56 -0000
Good morning Tom,
> Hi ZmnSCPxj,
>
> >=C2=A0I think the entire point of non-custodiality ***is*** trust minimi=
zation.
>
> 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-cu=
stodial and funds cannot be frozen/seized.=C2=A0
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 thei=
r finances, not focus on whether storage is "custodial" or not.
So I still suggest that, for purposes of technical discussion, we should av=
oid the term "custodial" and instead consider technical risks.
>
> > The main objection against custodiality is that someone else can preven=
t you from spending the coin.
> > If I have to tr\*st the SE to not steal the funds, is it *really* non-c=
ustodial, when after a swap, a corrupted SE can, in collusion with other pa=
rticipants, take control of the coin and prevent me from spending it as I w=
ish?
>
> 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 r=
ecords them.
Such a virtual environment could be set up by a rootkit that has been insta=
lled 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 en=
vironment and monitoring all its internal state and communications, they ca=
nnot 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 o=
f coins.
Thus, I believe this solution is inferior to these older solutions, at leas=
t in terms of financial security.
I admit the new solution is superior blockspace-wise, if you consider multi=
ple 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 obviati=
ng the blockspace savings.
The above remain true regardless of what definition of "custodial" you have=
.
Regards,
ZmnSCPxj
|
