Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 22B85C0051 for ; Tue, 22 Sep 2020 01:00:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 081B68601B for ; Tue, 22 Sep 2020 01:00:56 +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 FDOcd5KLDbCh for ; Tue, 22 Sep 2020 01:00:54 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by whitealder.osuosl.org (Postfix) with ESMTPS id 3AF6C85FC0 for ; Tue, 22 Sep 2020 01:00:54 +0000 (UTC) Date: Tue, 22 Sep 2020 01:00:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1600736451; bh=hVdrlPRvnyfVxrf32DuOXz+Aq3gkNLHROThclfoxqi4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=taOUBo5jot/6lIZSuMVteVrB3Wmcevb/Z8d32e/+AEul6YIHmd+hZQecyRAdMdaZW Z4H7sW4aaQ0SwLhR2nkkwRlAk65LO9fGz+kEFgkqEMk8Dr9dAnZEbpgTahxpTuuFeq +r53WTuDMDAoqUMeeKtXo5aREmYUT1mFQ2DO8zs8= 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: Tue, 22 Sep 2020 01:00:56 -0000 Good morning Tom, > Hi ZmnSCPxj, > > >=C2=A0I think the entire point of non-custodiality ***is*** trust minimi= zation. > > 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-cu= stodial and funds cannot be frozen/seized.=C2=A0 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 thei= r finances, not focus on whether storage is "custodial" or not. So I still suggest that, for purposes of technical discussion, we should av= oid the term "custodial" and instead consider technical risks. > > > The main objection against custodiality is that someone else can preven= t you from spending the coin. > > If I have to tr\*st the SE to not steal the funds, is it *really* non-c= ustodial, when after a swap, a corrupted SE can, in collusion with other pa= rticipants, take control of the coin and prevent me from spending it as I w= ish? > > 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 r= ecords them. Such a virtual environment could be set up by a rootkit that has been insta= lled 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 en= vironment and monitoring all its internal state and communications, they ca= nnot 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 o= f coins. Thus, I believe this solution is inferior to these older solutions, at leas= t in terms of financial security. I admit the new solution is superior blockspace-wise, if you consider multi= ple 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 obviati= ng the blockspace savings. The above remain true regardless of what definition of "custodial" you have= . Regards, ZmnSCPxj