From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1AEF8C0051 for ; 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 ; 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 ; 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 ; 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 From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <2Abk4Gqv5hJyGtA8Gg1WCP5RNuyUFkmRn1uUKp_mdUaXrRTz4SDBTPi0MGU7D5jj36VSzrqsIiO5lMR4gGRApRX2jyp8vXDeHBnFt-6ca-g=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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