📅 Original date posted:2020-05-11 📝 Original message:Good morning Ruben, CoinSwap for privacy is practically a "cross" chain atomic swap with the same chain and token for both sides of the swap, see also this set of ideas: github.com/AdamISZ/CoinSwapCS/issues/53 "Instead, Bob simply hands secretBob to Alice" is basically the same as private key turnover, as best as I can understand it, and gives significant advantages, also described in passing here: 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 forking predates BIP68, by using absolute locktimes and signing a specific `nLockTime`, with the destination being just "Alice". This should help privacy, as now all `scriptPubKey`s will be 2-of-2 (or P2PKH with 2p-ECDSA). (It strikes me that the relative locktime is unnecessary on the output of this 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 directly as backout; see the topic "`nLockTime`-protected Backouts" on the CoinSwapCS issue link) If you are willing to accept protocol complexity, having a variety of different versions of the transactions with different feerates could be used rather 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-Russell-Osuntokun will be identifiable onchain (and thus possibly flag the transaction 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, which 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: > 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 complexity) > - 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 of > 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 as 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 (= 3 tx protocol) > > - Instead, Bob simply hands secretBob to Alice > - Likewise, Alice hands keyAlice to Bob to forego her claim on the refund_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 reveal > 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 is > 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 to > 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 improvement > 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: > gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f > > Related work: > > Tier Nolan Atomic Swap: > bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 > Monero Atomic Swap: > github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md > > [0] lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002316.html > > [1] lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017595.html > > [2] blockstream.com/eltoo.pdf > > > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev