From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id A0CBCC016F for ; Fri, 15 May 2020 04:39:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 87D102E1C6 for ; Fri, 15 May 2020 04:39:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7XpLVbFPn3B for ; Fri, 15 May 2020 04:39:39 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by silver.osuosl.org (Postfix) with ESMTPS id 4EB122E1BB for ; Fri, 15 May 2020 04:39:39 +0000 (UTC) Date: Fri, 15 May 2020 04:39:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1589517576; bh=OTyZ1Xyl682L6jhzFNEJbJ5UafqV+yyT1deMeaZ15aA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=h9kQmdqojUQhHV4a4v0z+p970xZDejMM2JC6x1uCRRYYMVLXtYJPEWSUYVArRbuJH Fn+x2YSZg+XLrTAYYb1HAsJjulTQxCBhQ3EpDldVyH4FS02fBsg0OcmmnYpXG5w9nB /0lZ4aU0DahEgJFvtzaPQEB0mELEvsRsG/iEHFjU= To: Ruben Somsen From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <2-ZZw_6q-EBo5DmIK5PtzWCE9zd9FdNtYuhFf84FKxRHwmL7g7kA9YvYB9iqFFkGy_xoXARzRW8hiZa-ZcLPWeZ60PNMQc9yMdZLnTsp1yo=@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] SAS: Succinct Atomic Swap 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: Fri, 15 May 2020 04:39:44 -0000 Good morning Ruben, > Hi ZmnSCPxj, > > >on completion of the protocol, if Bob lets the refund tx#1 become valid = (i.e. does not spend the BTC txo) then Alice can broadcast it, putting both= their funds into chaos > > You forget, refund tx #1 has a script (which btw won't be visible with ta= proot): "Alice & Bob OR Alice in=C2=A0+1 day" (relative) so if Alice broadc= asts it after protocol completion, she is just giving Bob the key to her LT= C (note: if she's wise she'd move the LTC beforehand), but Bob doesn't lose= the BTC because he has both keys and can just react before the relative ti= melock expires. No chaos. Ah, that explains the existence of the Alice && Bob clause in that output t= hen. The attack is now as follows: * Alice completes the protocol up to handing over `sigSuccessAlice` to Bob. * Bob returns the `secretBob`. * Alice stalls the protocol and never sends the `Alice` privkey, and waits = for 1 day, then sneaks the refund tx #1 and spends the LTC via direct miner= collusion. The proper response here is that Bob should broadcast success tx before the= refund tx #1 becomes valid. (Which I think is the point: chaos can only occur if you let backouts becom= e valid, and it is the best policy for Bob to just spend the BTC txo well b= efore the timeout. Even if the protocol is completed, without a bring-your-own-fees that lets = you malleate the tx (i.e. CPFP hooks still require the transction itself to= reduce the fund by at least the minimum feerate), at least part of the fun= d must be lost in fees and Bob can still suffer a small loss of funds.) -- Tangentially, I now think in the case of client-server CoinSwap, the server= should take Alice position and the client should take Bob position. Suppose a client wants to do some mixing of its own received coins. It should not depend on only one server, as the server might secretly be a = surveillor (or hacked by a surveillor) and recording swaps. Thus, a client will want to make multiple CoinSwaps in sequence, to obscure= its history. (Do note the objections under "Directionality" in https://zmnscpxj.github.i= o/bitcoin/multiswap.html though; a counter to this objections is that the a= nalysis there is only applicable if the surveillor already identified the C= oinSwap sequence, but hopefully the increased steganography of CoinSwaps me= ans they are not identifiable anyway.) Since Bob really should spend its received coin before a timeout, it is bes= t for Bob to be the client; it is likely that the client will need to swap = "soon" again, meaning it has to redirect the funds to a new 2-of-2 anyway. For the final swap, the client can then spend the final coins to an HD wall= et it controls, reducing the key backup load on the client to be the same a= s normal HD wallets. Presumably the server in this situation has greater ability to dynamically = update its backups to include key backups for `secretAlice` keys. Further, if the client program has the policy that all spends out of the wa= llet must be done via a swap (similar to a rule imposed by JoinMarket where= sendpayment.py always does 1 CoinJoin), then this still matches well with = the requirement on Bob to spend the fund before the first timeout of refund= tx #1. If the client needs to spend to a classic, address-using service, then noth= ing in the SAS protocol allows Alice to receive its funds directly into a s= pecific third-party address. However, Bob can hand over a specific third-party address to use in the suc= cess tx. Indeed, the SAS protocol can be modified so that Bob can specify a set of a= ddress/value pairs to be put in the success tx instead of just Bob pubkey; = for example, Bob might swap more than the amoutn that needs to be paid to t= he third-party service, in order to give some additional leeway later for R= BF once Alice hands over the Alice privkey and Bob can remake the success t= x (and more importantly, ensure the txo is spent before refund tx #1 becoms= valid). Regards, ZmnSCPxj