summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorZmnSCPxj <ZmnSCPxj@protonmail.com>2020-09-24 00:19:48 +0000
committerbitcoindev <bitcoindev@gnusha.org>2020-09-24 00:19:56 +0000
commit26346c80d2084e55cafbdd3606ef5f30b085e564 (patch)
treeb4c0b57b379f76c9edd63874cbf5ffed40b88061
parent271ec536e21137cabc3644a21a3e947f48a9df0d (diff)
downloadpi-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/73242dc074b28201d624250e3d32bf53812c51136
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
+