FWIW, the paper by Gugger (h4sh3d) is not the only proposed Monero atomic swap protocol. Some others that have not been implemented in production code AFAIK:
Hoenisch & Pino (2021) “Atomic swaps between Bitcoin and Monero.”
Hoenisch, Mazumdar, Moreno-Sánchez, & Ruj (2022) “Lightswap: An atomic swap does not require timeouts at both blockchains.” (needs tx presigning, which is not yet available on Monero)
Thanks! I skimmed the papers, some comments below.
The 1st paper you gave has a nice explanation of the original method by Gugger, I find it easier to read. @tl121 check out section 3 (“BTC to XMR atomic swaps”) in Hoenisch & Pino (2021) “Atomic swaps between Bitcoin and Monero.”
It highlights the problem of fees on BTC and how Bob could be exposed to a draining attack because he has to go first. IMO it’s less of a problem on BCH since our fees are significantly lower (also helped by the contracts being smaller). The above paper proposes an alternative where Alice goes first by funding XMR output, but it depends on having adaptor signatures on both chains (as opposed to just on BCH/BTC in the original protocol), which is pending more research.
The 2nd paper needs capability to pre-sign XMR, which is not supported at the moment.
The 3rd paper relies on some generic crypto magic which goes over my head 
but it seems to be universally applicable and the transactions will look like ordinary P2PKH, so it is an improvement over HTLCs since it preserves privacy and transactions would be smaller, and also allows cyclic swaps: a multi-party chain of atomic swaps, such that either the whole chain goes through, or nothing does.
The 4th paper uses one-way payment channels to implement an interactive cross-chain swap. Parties simply update the channels in ping-pong fashion: transfer the currencies in small increments to each other until the swap is complete. This sounds promising, as we can have efficient such channels on BCH!
I understand the logic of combining those concepts into one, but inventing a new type of malleability this way is mostly just confusing…
And, the important part is that we still are in a phase where the rest of the world is unaware that Bitcoin Cash fixed transaction malleability, so reusing that word for something very different is not something I think is smart.
I’ve had various people ask what malleability is still a problem in the protocol. The knowledge that we fixed them in previous hardforks is absolutely not common knowledge (the segwit loving people are basically saying if its not segwit, you still have malleability) So… My question to you is that maybe you can come up with something less loaded there. “One of the parties re-signed the tx and changed the txid” doesn’t feel like its anywhere near the same concept as malleability fixed with segwit. Transaction malleability - Bitcoin Wiki
It is a case of “scriptSig Malleability” described there, e.g. in case of 2-of-2 multisig one of the parties can malleate the scriptSig as a whole without approval of the other party, which is why it’s called “2nd-party malleability”. In case of 2-of-3 with parties A, B, C: C could intercept a TX by A & B and replace either signature with his in order to change the TXID. This is solvable by:
SegWit BIP recognizes it as malleability in Motivation section:
In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of m private key holders (as opposed to only 1 private key holder with BIP62)
We implemented BIP62, so the multisig problem persists - but it’s not really a problem for us because we have more advanced Script and can work around it by constructing SIGHASH_NOINPUT, or even better - directly use covenant to enforce particular BCH flow instead of relying on pre-signed multisig.
I did not invent the term “2nd-party malleability” I picked it up somewhere, not sure where, and searching for the term now I was able to find an old mention: Transaction Malleability: Threats and Solutions | SF Bitcoin Devs
thanks for the detailed answer. I’m not sure how this relates to my point, I already acknowledged your logical naming makes sense, I’m not arguing that.
I hope you still understood the gist of my post and please consider it.
Hello
Are there still any malleability problems?
Depends on how you define the “problem”. We implemented all of BIP-62 so closed off 3rd-party malleability.
We don’t have SegWit so it’s still possible for a single signer in multisig to generate a new signature to change TXID without approval of other signers, but this is not a problem for us because we don’t need to rely on multisig to enforce TX template - we have direct covenants for that.
Also, you can emulate SIGHASH_ANYPREVOUT by using introspection opcodes and OP_CHECKDATASIGVERIFY so it’s still possible to pre-sign descendant transactions without them being ruggable if parent TXID changes.
Implement newer scheme: Hoenisch, P. & Pino, L. (2021). Atomic Swaps between Bitcoin and Monero
Links:
Bytecode sizes:
| bytecode | v4 size |
|---|---|
| swaplock | 134 |
| swaplock_swap | 72 |
| swaplock_refund_start | 1 |
| refund | 134 |
| refund_complete | 72 |
| refund_recover | 1 |
Path sizes:
Kudos to user PHCtizen for helping me work out the new scheme!
This would be a very cool project.
Alright, the swap has finally been demonstrated on BCH & XMR mainnets!
Timeline:
We leave it to PHCitizen to complete and claim the bounty, and we wish him luck in his future endeavors!
@mainnet_pat is interested in building a real app out of this, and for that he’s seeking funding. I’m part of that flipstarter, too, but pat will be doing bulk of the work tho, I’m just doing some contract stuff & research.
I already went ahead and done some research, and realized this VES scheme will work just as well with BTC/LTC/DOGE, and can be made even simpler because those chains are scriptable (we just need OP_IF and OP_CHECKSEQUENCEVERIFY on their end), so we need just the 1 TX on BCH end for both swap & refund paths because the refund path will refund Bob directly instead of sending to the 2nd stage of the refund contract.
This is OK, because Alice doesn’t need Bob for the refund (as she does in XMR-BCH swap, where the 2nd stage is relying on another VES with roles inverted) because timelock on BTC/LTC/DOGE will just release refund path to her directly.
The BTC/LTC/DOGE contract is just this:
OP_IF
// When Alice pulls from the BCH contract, Bob will learn Alice's
// key share of this key and he can just sweep it by using this path.
<key_combined_alice_bob_ves.public_key> OP_CHECKSIG
OP_ELSE
// If timelock expires then Alice can sweep BTC back to herself using
// her own key.
<timelock_1> OP_CHECKSEQUENCEVERIFY OP_DROP
<key_alice.public_key> OP_CHECKSIG
OP_ENDIF
and I added it to my contract repo here: contracts/v4-BTC-CashTokens · master · ac-0353f40e / cross-chain-swap-ves · GitLab
Oh yeah, we can swap not just BCH but any BCH+CashTokens UTXO for XMR/BTC/LTC/DOGE. When swapping pure BCH the contract is lighter for 15 bytes of covenant code which verify CashTokens contents but other than that it all works the same.
PS @TierNolan you did BTC/LTC HTLC swaps many years back, yeah? Did you check out the new stuff (PTLCs, VES), what do you think of this scheme above?
I am searching for an independent party who can verify the atomicity of the PHCitizen’s proposed implementation, based on @bitcoincashautist 's BCH script contracts. If the implementation is verified as atomic, then PHCitizen would receive the 18.4 XMR + 2.97 BCH bounty.
Maybe someone knowledgeable about the scripts activated in May 2022 could help. It could be reasonable to pay a portion of the bounty to someone who is capable of confirming the implementation’s atomicity (or finding a flaw). Maybe the 2.4 XMR that was contributed to the bounty after PHCitizen implemented their solution, or the equivalent in BCH.
I’ve taken a look at the v4-XMR contract by @bitcoincashautist. While I haven’t done a deep dive on the cryptography used, I can verify the workings of the contract being a co-developer of CashScript.
I’ve found some outdated comments and asked to improve some comments.
Specifically, to clearly mention that the off-chain interaction that takes place in preparation for the contract (aliceSignatureVES) and that this setup is asymetrical (bobSignatureVES) is not yet revealed during the setup of the contract because bob needs to make sure refundLockingBytecode is honest.
PHCitizen’s impementation is fully written in rust is not using the Cashscript SDK, so I can’t verify his implementation.
If I needed to describe the workings of swap contract in my own words:
either 1) both parties collaborate and swap goes through in the
Swaplockcontract which uses an interactive construction ofbobSignatureVESafter the initial contract set-up
or a timelock expires and the funds are forwarded to theRefundcontract
then 2) a refund of the original funds can (should) be initiated by bob
3) if bob fails to refund within a given timeframe (=is being dishonest) alice gets his BCH after all, bob gets nothing (there is still the option to rescue the locked XMR if alice shows grace)
The contract construction favors Alice, as only bob can be punished by losing his funds and not receiving anything in return. This is because bob is favored in the asymmetrical setup where he already gets aliceSignatureVES needed to initiate a refund.
Overall, the design is sensible and because of the refund- and punishment timelocks, honest behavior is incentivized.
We can verify that he uses my contract by comparing compiled bytecode with what he has here: https://github.com/PHCitizen/bch-xmr-swap/blob/main/protocol/src/contract/mod.rs#L14C56-L14C150
c3519dc4519d00c600cc949d00cb009c6300cd7888547978a85379bb675279b27500cd54798854790088686d6d7551
cashc -h swaplock.cash (v4.0.0, v4.1.0 will differ in 1 opcode, sha256): c3519dc4519d00c600cc949d00cb009c6300cd7888547978a85379bb675279b27500cd54798854790088686d6d7551
Note that both swaplock.cash and refund.cash have the same contract “tail”, it’s just the committed contract parameters that get changed depending on whether it’s 1st or 2nd stage.
This part of Rust code appends the variables with the contract tail: https://github.com/PHCitizen/bch-xmr-swap/blob/main/protocol/src/contract/mod.rs#L46
also, we can look at published TX unlocking bytecode to further confirm:
304402204c837eb43ac0450426e224f4479aafc67520db5063f1d25a9a32b8017ce403aa022062132decb368365c7bcea94b0b763afc1c0b72d57aab4f7e198d6d334da3df1c 17a91443265bc939f862ca5c66dc9f8c4379578973b949875221027a7ce6addff4ed215b84fce6fa873fd9e0c0b8f7dc46aa6b45453af2cc4a24501976a91485bc957e1184eca3f8e3fac3bbec72bc135d8f6788ac02e803c3519dc4519d00c600cc949d00cb009c6300cd7888547978a85379bb675279b27500cd54798854790088686d6d7551
I have added optimized versions of contracts:
Contract parameters are now not at the “head” (as with contracts compiled from CashScript) but inserted where they are used. OP_IF and stack state is optimized, too, and we save 18 bytes / TX.
I changed the approach for BTC-BCH refunds to improve privacy: instead of forwarding direct to Bob’s P2PKH we now forward to a simple P2SH contract that will then forward UTXO’s contents to Bob’s P2PKH address.
This way, if happy path is used, there will be no way to tell, by just looking at BCH blockchain, whether the BCH contract was used for BTC-BCH swap or for XMR-BCH swap.
For pure BCH swaps, just remove the block of opcodes (15 bytes) that verify token state is being passed on.
Input bytecode sizes (redeem script + unlocking data) are now:
| bytecode | XMR-CashTokens | XMR-BCH | BTC-CashTokens | BTC-BCH |
|---|---|---|---|---|
| swaplock + swaplock_swap | 203 | 188 | 203 | 188 |
| swaplock + swaplock_refund_start | 131 | 116 | 131 | 116 |
| refund + refund_complete | 203 | 188 | 58 | 43 |
| refund + refund_recover | 131 | 116 | – | – |
The BTC variant of the contract is usable for swapping BCH with LTC and EVM chains, too.
For Taproot chains, we can get really small footprint on their end and also hide the fact that the TX is part of a swap (happy path will look like ordinary P2PK spend, and Taproot tweak would be used to reveal the refund when necessary).
Some updates:
@PHCitizen has successfully completed the bounty, congratulations!
@mainnet_pat has successfully raised flipstarter funds to build a swap platform, and there’s been some progress already, here’s the latest update from Pat on X:
Finished the first version of the DLEQ Tools package for Rust and JavaScript GitHub - mainnet-pat/dleq-tools
It features all routines necessary to build adaptor signatures and prove that both parties are being honest during swapThis package compiles to #nodejs and browser-compatible #wasm module. Check it out on NPM dleq-tools - npm
Next step is to build the message exchange protocol. Going to try out the #libp2p with #webrtc transport for direct browser to browser communication. Stay tuned
we need a good GUI for XMR-BCH atomic swaps wallet
and/or a common GUI wallet interface for both coin-swaps, coin-join and atomic swaps implementation done in one place
New update by @mainnet_pat on X:
$BCH
$XMR atomic swap update. Finished the core functionality of the swap and implemented the happy path and refund path in a big integration test suite as per contract v4 by bchautist. One last push to support to v4.1 and I can start working on the Web3 dApp!
Check out the great SwapLock contract research and optimization at BCR
Big thanks to Woodser for helping me out with great
monero-tslibrary and all other Monero people for being friendly and responsive
I published something like a paper: Cross-chain Atomic Swaps With Bitcoin Cash (BCH) Using One-Time Verifiably Encrypted Signatures (VES)
and as a new topic for SEO reasons
New update from @mainnet_pat on X:
I have forked cashonize and ported it to Monero blockchain. It will be the wallet for the soon to come BCH-XMR atomic swaps app: https://monujo.cash
It is a simple noncustodial single-address web wallet for everyday spendings, do not store large sums there, always back up your seeds. It uses woodser’s monero-ts with some tweaks of mine.
It is a full wallet, so it does download the raw blockchain and can be heavy on network traffic, when restoring wallets, specify the height to reduce the bandwidth, especially on mobile devices with cellular networks
Also, “monujo” means “wallet” in Esperanto. Hope it is not gibberish as I’ve looked for many Esperanto words to brand this new wallet. I pronounce it spanish-like in my head [moh-nooh-hoh], hope it is right.