Re: [bitcoin-dev] SAS: Succinct Atomic Swap

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

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: https://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: 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 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:
> 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 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:
>     https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f
>
>     Related work:
>
>     Tier Nolan Atomic Swap:
>     https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
>     Monero Atomic Swap:
>     https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md
>
>     [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002316.html
>
>     [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/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