diff options
author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2020-09-24 00:19:48 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2020-09-24 00:19:56 +0000 |
commit | 26346c80d2084e55cafbdd3606ef5f30b085e564 (patch) | |
tree | b4c0b57b379f76c9edd63874cbf5ffed40b88061 | |
parent | 271ec536e21137cabc3644a21a3e947f48a9df0d (diff) | |
download | pi-bitcoindev-26346c80d2084e55cafbdd3606ef5f30b085e564.tar.gz pi-bitcoindev-26346c80d2084e55cafbdd3606ef5f30b085e564.zip |
Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.
-rw-r--r-- | 61/73242dc074b28201d624250e3d32bf53812c51 | 136 |
1 files changed, 136 insertions, 0 deletions
diff --git a/61/73242dc074b28201d624250e3d32bf53812c51 b/61/73242dc074b28201d624250e3d32bf53812c51 new file mode 100644 index 000000000..53894ec31 --- /dev/null +++ b/61/73242dc074b28201d624250e3d32bf53812c51 @@ -0,0 +1,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 + |