summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Trevethan <tom@commerceblock.com>2020-09-22 16:32:06 +0100
committerbitcoindev <bitcoindev@gnusha.org>2020-09-22 15:32:20 +0000
commite56a2fb395dae5020181c4dcde2968e96c8ad1ea (patch)
tree020922b3e3118582ba029a4facbbf3039f77fb38
parent2da1c17a2cf19f9485dfc1e199023206415a9acc (diff)
downloadpi-bitcoindev-e56a2fb395dae5020181c4dcde2968e96c8ad1ea.tar.gz
pi-bitcoindev-e56a2fb395dae5020181c4dcde2968e96c8ad1ea.zip
Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.
-rw-r--r--72/0236995e00ba30355062abca0b122472d0588c303
1 files changed, 303 insertions, 0 deletions
diff --git a/72/0236995e00ba30355062abca0b122472d0588c b/72/0236995e00ba30355062abca0b122472d0588c
new file mode 100644
index 000000000..9cfb7b980
--- /dev/null
+++ b/72/0236995e00ba30355062abca0b122472d0588c
@@ -0,0 +1,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>&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--
+