From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 68CD0C016E for ; Thu, 4 Jun 2020 16:37:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 5822086D88 for ; Thu, 4 Jun 2020 16:37:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWcp591sQwwb for ; Thu, 4 Jun 2020 16:37:57 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 35F5E86BAE for ; Thu, 4 Jun 2020 16:37:57 +0000 (UTC) Date: Thu, 04 Jun 2020 16:37:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1591288674; bh=lV9rUpjy27Zh/JRtO8jTskk+dao81PA+muQUR+sGrpI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=XlJwsgJ4h5FyTpyniFwg0kfSB+SZIpNuA8ScX5lvtXMu2w8us0YDAefFb+3IMvYPW 2DO8SqzAEZCMF6OyPFkfCm2dGtWsXrlZLzSdOHDZE1ItZyAkebVs+xImWBZV2TY7In mnXjaqrbEazWrHEI/4NrqbNxTwOUdIqxls27orCo= To: ZmnSCPxj , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <0U3wfLU9DpPZ7pwMOAr4xned-mOcHrpje4aLLiXZOt1qGuMhhyh36kAYJMEyv9bNjH2pMEzkkKK2rkAt9BD2pv_XknjdeqxEkEFsfSr4JAc=@protonmail.com> References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net> <5LiZqpFxklAAbGFiiAE3ijRbIteODXKcHrXvGJ-qabgQj5hG8beFtHNbVZ-XUxETVwduJYz94UYuJGAPxBrbGeZpSClUtXYsPJBABfr03KM=@protonmail.com> <0U3wfLU9DpPZ7pwMOAr4xned-mOcHrpje4aLLiXZOt1qGuMhhyh36kAYJMEyv9bNjH2pMEzkkKK2rkAt9BD2pv_XknjdeqxEkEFsfSr4JAc=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility 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, 04 Jun 2020 16:37:59 -0000 Good morning yet again Chris, > > For the avoidance of theft, it is probably better for Bob to wait for A= lice-side funding tx to confirm, probably deeply because reorgs suck. I realized that the *other* improvement I proposed in the [CoinSwapCS issue= ](https://github.com/AdamISZ/CoinSwapCS/issues/53) would help with this. Specifically, `nLockTime`-protected Backouts. Suppose we have an S6 route as so, with Alice as taker and Bob1 and Bob2 as= makers: Alice -> Bob1 -> Bob2 -> Alice We assume here that Bob1 and Bob2 directly talk to Alice and that if Bob1 w= ants to talk to Bob2 it is done via Alice, so in the below if we say "Bob1 = sends to Bob2" we imply that this is done via Alice. 1. Alice solicits fresh pubkeys from Bob1 and Bob2. 2. Alice gives timeouts L1 and L2 to Bob1, and L2 and L3 to Bob2, such tha= t L1 > L2 > L3, as well as negotiated amount, fees, etc. 3. Alice creates (but does NOT sign) a funding tx paying to Alice && Bob1 = and gives the txid to Bob1. 4. Bob1 creates and signs a tx spending from the Alice funding tx and payi= ng to Alice, with `nLockTime =3D L1`, and gives the signature to Alice. 5. Bob1 creates (but does NOT sign) a funding tx paying to Bob1 && Bob2 an= d gives the txid to Bob2. 6. Bob2 creates and signs a tx spending from the Bob1 funding tx and payin= g to Bob1, with `nLockTime =3D L2`, and gives the signature to Bob1. 7. Bob2 creates (but does NOT sign) a funding tx paying to Bob2 && Alice a= nd gives the txid to Alice. 8. Alice creates and signs a tx spending from the Bob2 funding tx and payi= ng to Bob2, with `nLockTime =3D L3`, and gives the signature to Bob2. 9. Alice signals everyone to sign their respecting funding txes and broadc= ast them. The rest of the CoinSwap protocol executes as normal once the funding txes = are deeply confirmed. The only thing that Bob1 (resp. Bob2) needs to wait for is that the signatu= res for the incoming HTLC / PTLC have been received before forwarding to th= e next hop. This allows all funding txes to be confirmed in the same block, or even in = some suitable random order (by having Alice send the signal out at differen= t times/blocks to different makers). The `nLockTime`d backout transactions are sufficient to allow everyone to r= ecover their funds unilaterally in case one of the other funding txes do no= t confirm. A similar technique can be done for SAS as well, but this removes the lack = of encumbrance in the LTC-side output of SAS, which removes the advantage o= f having an otherwise unencumbered output. In effect, the above creates Spilman unidirectional payment channels along = the route, bringing the fiddly timing details offchain where it is less vis= ible to observers. -- However, note that this still allows a form of griefing attack. Basically, Alice can induce Bob1 and Bob2 to lock their funds for some time= , by completing the above ritual, but not signing and broadcasting its own = funding tx. Bob1 and Bob2 will have been induced to lock their funds for L2 and L3, res= pectively, while Alice only has to RBF away its own funding tx. Alice might do this if it is actually another maker and it wants to take ou= t its competitors Bob1 and Bob2, reducing their available liquidity for a t= ime and cornering the SwapMarket. This can be mitigated by replacing step 9 with: 9. Alice gives its signed funding tx to Bob1. 10. Bob1 gives its signed funding tx to Bob2. 11. Bob2 gives its signed funding tx to Alice. 12. Alice signals everyone to broadcast their funding txes. Then Bob1 (resp. Bob2) can monitor the mempool/blockchain and check as well= if its outgoing funding tx has been broadcast/confirmed, and if so broadca= st the incoming funding tx. Or better, if Bob1 (resp. Bob2) does not receive the Alice signal fast enou= gh, it will broadcast its incoming funding tx anyway. This is only a mitigation: Alice could have pre-prepared a replacement to t= he funding tx that it broadcasts near miners just before it signals Bob1 an= d Bob2 to broadcast all transactions. For full protection against griefing attacks, Bob1 (resp. Bob2) have to wai= t for the incoming funding tx to be confirmed deeply before broadcasting it= s outgoing funding tx as well. Regards, ZmnSCPxj