Monero-BCH Atomic Swaps

Technical
#35

This would be a very cool project.

#36

Alright, the swap has finally been demonstrated on BCH & XMR mainnets!

Timeline:

  1. @PHCitizen published his Rust implementation and performed TXs on testnets
  2. Few hours later @mainnet_pat published a mannet TX, done using his independent implementation with mainnet-js and cashscript libraries alongside cross-compiled Rust WASM for DLEQ. Also, he optimized the BCH contract a little by removing an unnecessarry sha256 op (which I already updated - v4.1.0).
  3. Shortly after, PHCitizen performed TXs on mainnets and is waiting for review to claim the bounty.

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.

4 Likes
#37

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?

#38

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.

4 Likes
#39

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 Swaplock contract which uses an interactive construction of bobSignatureVES after the initial contract set-up
or a timelock expires and the funds are forwarded to the Refund contract
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.

3 Likes
#40

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

  • Rust: c3519dc4519d00c600cc949d00cb009c6300cd7888547978a85379bb675279b27500cd54798854790088686d6d7551
  • Output of 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

4 Likes
#41

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

3 Likes
#42

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 swap

This 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

3 Likes
#43

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

2 Likes
#44

New update by @mainnet_pat on X:

$BCH :arrows_counterclockwise: $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-ts library and all other Monero people for being friendly and responsive

4 Likes
#45

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

6 Likes
#46

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.

4 Likes
#47

The nice thing about the ping pong swaps is the chains don’t have tow switch. And in to context of BTC, you only have to have a little bit, and I don’t want a lot of it.

1 Like
#48

You are a wizard for pulling this off, FYA I noticed a new bounty has been put up to integrate BCH/XMR swaps into a wallet and make usable by the average user. Not sure if this is something that interests you or someone you know.

2 Likes
#49

Little update, @mainnet_pat has been busy implementing the swap for BasicSwap DEX: [WIP] Add BCH Support by mainnet-pat · Pull Request #124 · basicswap/basicswap · GitHub

On October 20 he wrote:

This week’s report features progress on further work towards implementing the BCH swap interface. Major achievement is the happy path (lock-spend) BCH-XMR swap completion, yay! More work is needed on three other paths:

  • lock-refund
  • lock-refund-spend
  • lock-refund-refund

These will be easier to implement as most fundamentals are already in place.

3 Likes
#50

image
image914×398 55.3 KB

https://x.com/mainnet_pat/status/1850240234622967990

https://x.com/mainnet_pat/status/1850240857842094336

Absolutely incredible news. The funding part is especially bullish! As BCH gains traction & momentum, more resources are appearing from outside to fuel further growth. This is exactly what we’d expect to see from a growing community & it’s amazing to see it vindicated. Great work pat!

3 Likes
#51

This is great news, hopefully BasicSwap gets much easier to install and set up, last time I tried I totally failed about a year ago, and I am fairly technical.

2 Likes
#52

Why can’t we just use one of these: No-KYC Monero exchanges

#53

Because these are centralized so they can lock your funds and demand anything they want from you.

Atomic swaps are executed without a trusted party so no one can lock your coins.

1 Like
#54

On November 29, version 0.14.2 of BasicSwap was released. It has the first production-ready implementation of BCH<>XMR atomic swaps!

Special thanks to @mainnet_pat for most of the implementation work that made this possible, @bitcoincashautist for the theoretical work on atomic swaps, and ofrnxmr for administrative support.

6 Likes