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 7D2D7C016E for ; Sat, 6 Jun 2020 01:40:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 658E48638E for ; Sat, 6 Jun 2020 01:40:32 +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 k3v-GWg4DiiJ for ; Sat, 6 Jun 2020 01:40:30 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 8E17F86302 for ; Sat, 6 Jun 2020 01:40:30 +0000 (UTC) Date: Sat, 06 Jun 2020 01:40:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1591407628; bh=D68ita+Gg18KoFs0mxXUiDoxN7N2Els+idgT39BNb3g=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=i1oOMu3Oh+OLovXhVImANUDeFaTnNA1GDjdPDJwK+wennKNoNS//z9yJyoRJTTpmB t7s/PEwIQk336cYPj3ijhZ6I6WylgIXIhPLOAX/6q3bSOe8QTFSmYBDlEd+KsW2lr1 P6PJ/Bmrs0uhuNDMn0TZHcMcoCV0dHYc53pHYIlY= To: Chris Belcher From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net> <5LiZqpFxklAAbGFiiAE3ijRbIteODXKcHrXvGJ-qabgQj5hG8beFtHNbVZ-XUxETVwduJYz94UYuJGAPxBrbGeZpSClUtXYsPJBABfr03KM=@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] 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: Sat, 06 Jun 2020 01:40:32 -0000 Good morning Chris, > I think I'm having trouble understanding this, does it work like this: > > Say we're in the 2-party coinswap case (Alice and Bob) > > We have Alice's funding transaction: > Alice UTXO ---> 2of2 multisig (Alice+Bob) > > And we have the regular contract transaction > 2of2 multisig (Alice+Bob) ---> Alice+timelock1 OR Bob+hashlock > > And you propose a second pre-signed transaction? > 2of2 multisig (Alice+Bob) ---> Bob+timelock2 No, it is: 2of2 multisig (Alice+Bob) --(nLockTime=3Dlocktime1)-> Alice The timelock is imposed as a `nLockTime`, not as an `OP_CLTV` (so not in t= he output of the tx, but part of the tx), and the backout returns the funds= to Alice, not sends it to Bob. This transaction is created *before* the contract transaction. The order is: * Create (but not sign) Alice funding tx (Alice --> Alice+Bob). * Create and sign Alice backout transaction (Alice+Bob -(nLockTime=3Dlockti= me1)-> Alice). * Create (but not sign) Bob funding tx (Bob --> Alice+Bob+sharedSecret). * Create and sign Bob backout transaction (Alice+Bob+sharedSecret -(nLockti= me=3Dlocktime2)-> Bob) where timelock2 < timelock1. * Sign and broadcast funding txes. * At this point, even if Bob funding tx is confirmed but Alice funding tx= is not, Bob can recover funds with the backout, but Alice cannot steal the= funds (since there is no hashlock branch at this point). * When Alice funding tx is confirmed, create and sign contract transaction = (Alice+Bob --> Alice+timelock1 OR Bob+hashlock). * When Bob funding tx is confirmed and Bob has received the Alice contract = transaction, create and sign Bob contract transaction (Alice+Bob+sharedSecr= et --> Bob+timelock2 OR Alice+hashlock). * Continue as normal. In effect, the backout transaction creates a temporary Spilman unidirection= al time-bound channel. We just reuse the same timelock on the HTLC we expect to instantiate, as th= e time bound of the Spilman channel; the timelock exists anyway, we might a= s well reuse it for the Spilman. Creation of the contract tx invalidates the backout tx (the backout tx is `= nLockTime`d, the contract tx has no such encumbrance), but the backout allo= ws Alice and Bob to fund their txes simultaneously without risk of race los= s. However, they do still have to wait for (deep) confirmation before signing = contract transactions, and Bob has to wait for the incoming contract transa= ction as well before it signs its outgoing contract transaction. The protocol is trivially extendable with more than one Bob. The insight basically is that we can split CoinSwap into a "channel establi= shment" phase and "HTLC forwarding" phase followed by "HTLC resolution" and= "private key handover". HTLC forwarding and HTLC resolution are "done offchain" in the channels, an= d channel establishment can be done in any order, including reverse. Indeed, the Spilman channel need not have the same timelock as the HTLC it = will eventually host: it could have a shorter timelock, since the contract = transaction has no `nLockTime` it can be instantiated (with loss of privacy= due to the nonstandard script) before the Spilman timeout. Regards, ZmnSCPxj