ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-05-11 📝 Original message:Good morning Ruben, ...
📅 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: 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 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: 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev