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 89477C016F for ; Mon, 11 May 2020 16:45:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 8096926087 for ; Mon, 11 May 2020 16:45:29 +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 jR6f-4izcCC5 for ; Mon, 11 May 2020 16:45:27 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) by silver.osuosl.org (Postfix) with ESMTPS id B6F6B26084 for ; Mon, 11 May 2020 16:45:26 +0000 (UTC) Date: Mon, 11 May 2020 16:45:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1589215523; bh=+yZI/W6D6JiROi9otdoZz/FqrAjqHlp2ueNwq2Kffd4=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=VoUYag0aNxMTuRCpdcynBrS/dl4hbQ2W52Eivd1kQf9yFU/zWt8ERUafCt84DQuKZ D2fS/zWiS0gayEXwqf+bU0cXfvItRCpjEn/NCxLTqADqsBfhjE1+hrJlop2pvnTGNO ZzKQh0usHPfd1fOgvWkWi4GzrAz0rHKwBhzeZ4m8= To: Ruben Somsen , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 11 May 2020 16:45:29 -0000 Good morning Ruben, CoinSwap for privacy is practically a "cross" chain atomic swap with the sa= me chain and token for both sides of the swap, see also this set of ideas: = https://github.com/AdamISZ/CoinSwapCS/issues/53 "Instead, Bob simply hands secretBob to Alice" is basically the same as pri= vate key turnover, as best as I can understand it, and gives significant ad= vantages, also described in passing here: https://lists.linuxfoundation.org= /pipermail/bitcoin-dev/2020-May/017816.html Overall, this looks very much like a working CoinSwap as well. The Refund tx does not need anything more than a 2-of-2 script. The "OR Alice in +1 day" branch can be implemented, at least on Bitcoin and= similar blockchains, by signing a specific `nSequence`, or if the chain fo= rking predates BIP68, by using absolute locktimes and signing a specific `n= LockTime`, with the destination being just "Alice". This should help privacy, as now all `scriptPubKey`s will be 2-of-2 (or P2P= KH with 2p-ECDSA). (It strikes me that the relative locktime is unnecessary on the output of t= his refund tx --- as long as both participants agree on either Alice or Bob= having a longer locktime, you can just use the locktime on the refund tx d= irectly as backout; see the topic "`nLockTime`-protected Backouts" on the C= oinSwapCS issue link) If you are willing to accept protocol complexity, having a variety of diffe= rent versions of the transactions with different feerates could be used rat= her than the Decker-Russell-Osuntokun "eltoo" bring-your-own-fees method. In terms of privacy this is better as you would not be using anything other= than the most boring `SIGHASH_ALL` signing flag, whereas the Decker-Russel= l-Osuntokun will be identifiable onchain (and thus possibly flag the transa= ction as "of interest" to surveillors) due to use of `SIGHASH_ANYPREVOUT`. As long as the one resolving a particular side of the swap is the one that = ocmpletes the signature (which I believe holds true for all branches?) then= it would select the version of the transaction with the best feerate, whic= h it effectively pays out to what it recovers. Regards, ZmnSCPxj > Works today with single signer ECDSA adaptor signatures[0], or with > Schnorr + MuSig. > > Diagram here: > https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f#file= -succinctatomicswap-svg > > Advantages: > > - Requires merely two on-chain transactions for successful completion, > as opposed to four > > - Scriptless, and one of the chains doesn't need to support timelocks > - Can be used for efficient privacy swaps, e.g. Payswap[1] > > Disadvantages: > > - Access to money is contingent on remembering secrets (backup complexi= ty) > - Online/watchtower requirement for the timelock supporting chain (not > needed with 3 tx protocol) > > Protocol steps: > > 0.) Alice & Bob pre-sign the following transactions, with exception o= f > the signatures in [brackets]: > > - success_tx (money to Bob): [sigSuccessAlice] + [sigSuccessBob] > - revoke_tx (timelock): sigRevokeAlice + sigRevokeBob, which must then > be spent by: > -- refund_tx (relative timelock, refund to Alice): [sigRefundAlice] > > > - {sigRefundBob} > -- timeout_tx (longer relative timelock, money to Bob): > sigTimeoutAlice + [sigTimeoutBob] > > {sigRefundBob} is an adaptor signature, which requires secretAlice to= complete > > 1.) Alice proceeds to lock up 1 BTC with Bob, using keyAlice & keyBob= as pubkeys > > If protocol is aborted after step 1: > > > - Alice publishes the revoke_tx, followed by the refund_tx & > sigRefundBob, to get her BTC back > > - If Alice neglects to publish the refund_tx in time, Bob will claim > the BTC with the timeout_tx > > 2.) Bob locks up altcoins with Alice, using secretAlice & secretBob a= s pubkeys > > If protocol is aborted after step 2: > > - Once Alice publishes sigRefundBob, Bob learns secretAlice and > regains control over the altcoins > > 3.) Protocol completion: > > - Alice hands adaptor signature {sigSuccessAlice} to Bob, which > requires secretBob to complete > > - Bob could now claim the BTC via the success_tx, reveal secretBob, > and thus give Alice control over the altcoins (=3D 3 tx protocol) > > - Instead, Bob simply hands secretBob to Alice > - Likewise, Alice hands keyAlice to Bob to forego her claim on the refu= nd_tx > - Bob continues to monitor the chain, because he'll have to respond if > Alice ever publishes the revoke_tx > > More graceful protocol failure: > > If the protocol aborts after step 1, Alice would have been forced to > make three transactions in total, while Bob has made none. We can > reduce that to two by introducing a second refund_tx with timelock > that can be published ahead of the revoke_tx and directly spends from > the funding transaction. Publishing this transaction would also revea= l > secretAlice to Bob via an adaptor signature. In the 3 tx protocol, > this output can go directly to Alice. In the 2 tx protocol with > online/watchtower requirement, this output needs a script: spendable > by Alice + Bob right away OR by Alice after a relative timelock. It i= s > important to note that this transaction must NOT be published during > step 3. Once Bob can complete the success_tx, the revoke_tx is needed > to invalidate the success_tx prior to revealing secretAlice. > > FAQ: > > - Why not allow Alice to still claim the altcoins if she accidentally > lets Bob publish the timeout_tx? > > Alice could send the revoke_tx at the same time, revealing both > secrets and causing likely losses. This can be solved by adding yet > another transaction, but it wouldn't be efficient and wouldn't > motivate Alice to behave. > > - Is it possible to implement this protocol on chains which only > support absolute timelocks? > > Yes, but then Bob must spend his swapped coins before the timelock > expires (or use the 3 tx protocol). Be aware that the revoke_tx MUST > confirm before the timeout_tx becomes valid, which may become a > problem if fees suddenly rise. The refund_tx can also not be allowed > to CPFP the timeout_tx, as they must confirm independently in order t= o > invalidate the success_tx first. > > - Can't Alice just publish the revoke_tx after protocol completion? > > Yes, she'd first have to move the altcoins (to invalidate > secretAlice), and could then try to claim the BTC by publishing the > revoke_tx, forcing Bob to react on-chain before the refund_tx becomes > valid. The eltoo[2] method of paying for fees (requires > sighash_anyprevout) or a second CPFP-able output may be an improvemen= t > here (and also mitigates fee rising issues), but note that this also > increases the required amount of tx data if the protocol doesn't > complete successfully. > > - Can this be made to work with hash locks? > > Yes, by making the altcoins spendable via sigAlice + preimageBob OR > sigBob + preimageAlice, and ensuring the contracts on the BTC side > reveal either pre-image. Do note that this is not scriptless and will > thus increase the transaction size. > > Open question: > > Perhaps it's possible to perform an atomic swap in and out of > Lightning with only a single on-chain transaction. This would require > some kind of secondary set of HTLCs, allowing the sender to cancel a > Lightning payment by revealing a secret after a certain period of > time. > > -- Ruben Somsen > > Thanks to Lloyd Fournier for feedback and review. > > If you find any further errors, I will endeavor to fix them here: > https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f > > Related work: > > Tier Nolan Atomic Swap: > https://bitcointalk.org/index.php?topic=3D193281.msg2224949#msg222494= 9 > Monero Atomic Swap: > https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md > > [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-No= vember/002316.html > > [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Janu= ary/017595.html > > [2] https://blockstream.com/eltoo.pdf > > > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev