mirror of
https://github.com/comit-network/xmr-btc-swap.git
synced 2024-10-01 01:45:40 -04:00
Bitcoin–Monero Cross-chain Atomic Swap
20f2e56e2d
271: Bob can verify that the XMR lock tx was published r=da-kami a=da-kami The Monero `txhash` log was removed. I feel the user should have the possibility to verify that the transaction was actually published so I added the tx-hash to the confirmation output. We could potentially print the tx-hash when receiving the transfer proof already, but that might not add much value compared to printing it with the confirmations. Additionally we should allow the user to at least know when the XMR can be expected in the user's wallet, otherwise the swap ends like this: ``` 2021-03-04 13:49:19 INFO Monero lock tx received 5 out of 5 confirmations ``` This is just not very informative - yes, the final transaction is an implementation detail, but I don't think we should hide the transactions from the user. By printing the tx-hash for spending from the lock-tx into the user wallet we ensure the user knows that the XMR can now be expected in the user wallet. --- To add context, here the complete log (with debug enabled) **before** this change: ``` 2021-03-04 13:30:46 DEBUG Database and seed will be stored in /Users/dakami/Library/Application Support/xmr-btc-swap 2021-03-04 13:30:46 DEBUG Starting monero-wallet-rpc on port 56145 2021-03-04 13:30:51 DEBUG Requesting quote 2021-03-04 13:30:51 INFO Received quote: 1 XMR = 0.00433500 BTC 2021-03-04 13:30:51 INFO Still got 0.01018746 BTC left in wallet, swapping ... 2021-03-04 13:30:51 INFO Spot price for 0.00500000 BTC is 1.153402537485 XMR 2021-03-04 13:30:52 DEBUG Starting execution setup with 12D3KooWCdMKjesXMJz1SiZ7HgotrxuqhQJbP5sgBm2BwP1cqThi 2021-03-04 13:30:55 INFO Published Bitcoin 3a6690a962191529892318819fb20e7f1ac4625400e64ee734056a9b2a17ad8f transaction as lock 2021-03-04 13:41:13 DEBUG Received Transfer Proof from 12D3KooWCdMKjesXMJz1SiZ7HgotrxuqhQJbP5sgBm2BwP1cqThi 2021-03-04 13:42:11 INFO Monero lock tx received 1 out of 5 confirmations 2021-03-04 13:45:33 INFO Monero lock tx received 2 out of 5 confirmations 2021-03-04 13:47:49 INFO Monero lock tx received 3 out of 5 confirmations 2021-03-04 13:48:56 INFO Monero lock tx received 4 out of 5 confirmations 2021-03-04 13:49:19 INFO Monero lock tx received 5 out of 5 confirmations 2021-03-04 13:49:19 DEBUG Encrypted signature sent 2021-03-04 13:49:19 DEBUG Alice acknowledged encrypted signature 2021-03-04 13:49:19 DEBUG watching for tx: e5569d3f0bcccac95252dffaebe74ead0360c09b76bc762de890aaa0e51afbcf 2021-03-04 13:49:20 DEBUG Received protocol error "missing transaction" from Electrum, retrying... 2021-03-04 13:49:22 DEBUG Received protocol error "missing transaction" from Electrum, retrying... ``` Co-authored-by: Daniel Karzel <daniel@comit.network> |
||
---|---|---|
.github/workflows | ||
docs | ||
monero-harness | ||
monero-rpc | ||
swap | ||
tokio-tar | ||
.gitignore | ||
.mergify.yml | ||
bors.toml | ||
BTC_XMR_atomic_swap_protocol.svg | ||
Cargo.lock | ||
Cargo.toml | ||
LICENSE | ||
README.md | ||
rust-toolchain | ||
rustfmt.toml |
XMR to BTC Atomic Swap
This repository is a proof of concept for atomically swapping XMR for BTC.
We define:
- Alice to be the actor that initially holds XMR.
- Bob to be the actor that initially holds BTC.
In the best-case scenario the protocol looks like this:
- Alice and Bob exchange a set of addresses, keys, zero-knowledge proofs and signatures.
- Bob publishes
Tx_lock
, locking up his bitcoin in a 2-of-2 multisig output owned by Alice and Bob. Given the information exchanged in step 1, Bob can refund his bitcoin if he waits until timet_1
by usingTx_cancel
andTx_refund
. If Bob doesn't refund after timet_1
, Alice can punish Bob for being inactive by first publishingTx_cancel
and, aftert_2
, spending the output usingTx_punish
. - Alice sees that Bob has locked up the bitcoin, so she publishes
Tx_lock
on the Monero blockchain, locking up her monero in an output which can only be spent with a secret key owned by Alice (s_a
) and a secret key owned by Bob (s_b
). This means that neither of them can actually spend this output unless they learn the secret key of the other party. - Bob sees that Alice has locked up the monero, so he now sends Alice a missing key bit of information which will allow Alice to redeem the bitcoin using
Tx_redeem
. - Alice uses this information to spend the bitcoin to an address owned by her.
When doing so she leaks her Monero secret key
s_a
to Bob through the magic of adaptor signatures. - Bob sees Alice's
Tx_redeem
on Bitcoin, extracts Alice's secret key from it and combines it with his own to spend the monero to an address of his own.
The repository is structured as a library and a single test function that executes the swap. The library has the following modules:
alice
: Defines the state machine that describes the swap for Alice. This includes the messages sent to/from Alice.bob
: Defines the state machine that describes the swap for Bob. This includes the messages sent to/from Bob.bitcoin
: Keys, signing functions, transactions etc. for Bitcoin. Also includes a test wallet (see below).monero
: Keys, signing functions, transactions etc. for Monero. Also includes a test wallet (see below).
Currently we have a single test function that proves the following:
- Interaction with both block chains and their respective wallets works.
- The messages required are correct and can manually drive the state transitions to execute a swap.
- It is possible to interact with, and watch, the monero blockchain using
monero-wallet-rpc
. - It is possible to watch a bitcoind instance using
bitcoin-harness
(we already knew this :)
Currently we do not do:
- Actual network communication.
- Verification that the UI is acceptable. Since we do everything in a single test function there is no user interaction, this is unrealistic for a real product.
Testing
We wrote a few additional libraries to facilitate testing:
Wallets
bitcoin
module contains a test wallet by way ofbitcoind
.monero
: module contains a test wallet by way ofmonero-wallet-rpc
.
Blockchain harnesses
We have written two harnesses for interacting with bitcoin and monero.
These harnesses wrap interaction with bitcoind
and monerod
/monero-wallet-rpc
.
We use testcontainers-rs to spin up bitcoind
, monerod
, and monero-wallet-rpc
in docker containers during unit/integration testing.