path: root/72/0236995e00ba30355062abca0b122472d0588c

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>&gt; The SE c=
an run in a virtual environment that monitors deletion events and records t=
hem.<br>&gt; Such a virtual environment could be set up by a rootkit that h=
as been installed on the SE hardware.<br>&gt; 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>&gt; Compare this to,=
 for example, TumbleBit or Wasabi.<br>&gt; 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>&gt;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>&gt; 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 &lt;<a href=3D"mailto:ZmnSCPxj@prot=
onmail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>&gt; 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>
&gt; Hi ZmnSCPxj,<br>
&gt;<br>
&gt; &gt;=C2=A0I think the entire point of non-custodiality ***is*** trust =
minimization.<br>
&gt;<br>
&gt; 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 &quot;custodial&quot; or not.<b=
r>
<br>
So I still suggest that, for purposes of technical discussion, we should av=
oid the term &quot;custodial&quot; and instead consider technical risks.<br=
>
<br>
&gt;<br>
&gt; &gt; The main objection against custodiality is that someone else can =
prevent you from spending the coin.<br>
&gt; &gt; 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>
&gt;<br>
&gt; 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 &quot;custodial&quot=
; you have.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--00000000000008f04605afe8ac4e--