diff options
author | Tom Trevethan <tom@commerceblock.com> | 2020-09-22 16:32:06 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2020-09-22 15:32:20 +0000 |
commit | e56a2fb395dae5020181c4dcde2968e96c8ad1ea (patch) | |
tree | 020922b3e3118582ba029a4facbbf3039f77fb38 | |
parent | 2da1c17a2cf19f9485dfc1e199023206415a9acc (diff) | |
download | pi-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/0236995e00ba30355062abca0b122472d0588c | 303 |
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>> 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-- + |