diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2020-06-04 16:37:53 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-06-04 16:37:59 +0000 |
| commit | 4845afc22c530ab57ae1b084767d3f2d5aed0edc (patch) | |
| tree | bafe1dc279efd5e69f9dc1c69c83401a27f534fa | |
| parent | 2bbcf77dace5e77745ff58fd9981a79551f02240 (diff) | |
| download | pi-bitcoindev-4845afc22c530ab57ae1b084767d3f2d5aed0edc.tar.gz pi-bitcoindev-4845afc22c530ab57ae1b084767d3f2d5aed0edc.zip | |
Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility
| -rw-r--r-- | 50/0ba0cd084c6395160037f45836c5d723afdefb | 154 |
1 files changed, 154 insertions, 0 deletions
diff --git a/50/0ba0cd084c6395160037f45836c5d723afdefb b/50/0ba0cd084c6395160037f45836c5d723afdefb new file mode 100644 index 000000000..261ef587c --- /dev/null +++ b/50/0ba0cd084c6395160037f45836c5d723afdefb @@ -0,0 +1,154 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 68CD0C016E + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <ZmnSCPxj@protonmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <mW43gzUcbr5HziCafjw_a-yZb3sdNl7SrsUTBpQFnZzVwRgpSVFUZzg4u6ORXzs9fc8KeWbdpGuCPnrA3iYjdmc1O_E84hyL-Qsr3cvqVGY=@protonmail.com> +In-Reply-To: <0U3wfLU9DpPZ7pwMOAr4xned-mOcHrpje4aLLiXZOt1qGuMhhyh36kAYJMEyv9bNjH2pMEzkkKK2rkAt9BD2pv_XknjdeqxEkEFsfSr4JAc=@protonmail.com> +References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net> + <CAPv7TjY9h8n-nK_CPiYCWYDcbXpT1gfRMQDgf9VUkcR532rxOw@mail.gmail.com> + <VxL93WE7bDrK1riquTWTTEgJj9mDQ4W5CuhOgdnnDPeidw2ho6evVh4cLZLz0jEYMqejaD1tiLULVTXkNRbI5A7wSwV49qSwnXcTWCDJ96E=@protonmail.com> + <cbf78f63-cf8c-c5d8-06ea-afc79aabc23c@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 <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, 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 + + |