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:

"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:

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 

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 
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.


> Works today with single signer ECDSA adaptor signatures[0], or with
> Schnorr + MuSig.
> Diagram here:
> 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:
>     Related work:
>     Tier Nolan Atomic Swap:
>     Monero Atomic Swap:
>     [0] 
>     [1] 
>     [2]
> bitcoin-dev mailing list

bitcoin-dev mailing list

Reply via email to