161: Introduce configuration file and initial setup through CLI r=da-kami a=da-kami
PRs chained on top of this one:
- [x] https://github.com/comit-network/xmr-btc-swap/pull/163 Configurable config with `--config` option on CLI (we will need this for swaps with ourselves...)
- [x] ~~https://github.com/comit-network/xmr-btc-swap/pull/165 Reset config with `--reset-config` option on CLI (this makes it easier for the user to clean up)~~
- [x] https://github.com/comit-network/xmr-btc-swap/pull/166 data-dir, in accordance to config-dir, should be pointed to the appropriate default directory using `directory-next`
Looks n' feel:
Initial startup:
```
2021-01-28T01:35:45.000205Z INFO swap::trace: Initialized tracing with level: INFO
2021-01-28T01:35:45.001286Z INFO swap: Database and Seed will be stored in directory: /Users/dakami/CoBloX/TEMP/swap-data-dir/alice
2021-01-28T01:35:45.003391Z INFO swap::config::seed: Read in seed from file: /Users/dakami/CoBloX/TEMP/swap-data-dir/alice/seed.pem
2021-01-28T01:35:45.003603Z INFO swap::config: Config file not found, running initial setup...
? Enter Bitcoind URL (including username and password if applicable) or hit return to use default (http://127.0.0.1:18332) › http://dakami:xkz4nyywpKf3BigwKIRdVijmWzaHCOmUisepQpDlsXnhpNd6uO@127.0.0.1:18332/
✔ Enter Bitcoind URL (including username and password if applicable) or hit return to use default · http://dakami:xkz4nyywpKf3BigwKIRdVijmWzaHCOmUisepQpDlsXnhpNd6uO@127.0.0.1:18332/
? Enter Bitcoind wallet name › alice
✔ Enter Bitcoind wallet name · alice
? Enter Monero Wallet RPC URL or hit enter to use default (http://127.0.0.1:38083/json_rpc) ›
✔ Enter Monero Wallet RPC URL or hit enter to use default · http://127.0.0.1:38083/json_rpc
2021-01-28T01:35:58.553401Z INFO swap::config: Initial setup complete, config file created at /Users/dakami/Library/Application Support/xmr-btc-swap/config.toml
2021-01-28T01:35:58.647761Z INFO swap: Connection to Bitcoin wallet succeeded, balance: 0.00744521 BTC
2021-01-28T01:35:58.650060Z INFO swap: Connection to Monero wallet succeeded, balance: 29.095359550000 XMR
2021-01-28T01:35:58.650258Z INFO swap: Swap sending 0.030000000000 XMR and receiving 0.00060000 BTC started with ID e07b2cc1-3749-48fd-931a-6cbaf57b8124
2021-01-28T01:35:59.004306Z INFO swap::protocol::alice::swap: Current state:started
```
After:
```
2021-01-28T01:36:57.881654Z INFO swap::trace: Initialized tracing with level: INFO
2021-01-28T01:36:57.882691Z INFO swap: Database and Seed will be stored in directory: /Users/dakami/CoBloX/TEMP/swap-data-dir/alice
2021-01-28T01:36:57.884171Z INFO swap::config::seed: Read in seed from file: /Users/dakami/CoBloX/TEMP/swap-data-dir/alice/seed.pem
2021-01-28T01:36:57.884353Z INFO swap::config: Using config file at default path: /Users/dakami/Library/Application Support/xmr-btc-swap/config.toml
2021-01-28T01:36:57.996153Z INFO swap: Connection to Bitcoin wallet succeeded, balance: 0.00744521 BTC
2021-01-28T01:36:57.998648Z INFO swap: Connection to Monero wallet succeeded, balance: 29.095359550000 XMR
2021-01-28T01:36:57.998928Z INFO swap: Swap sending 0.030000000000 XMR and receiving 0.00060000 BTC started with ID 08dd6dc1-9460-4c0a-91ef-a05df309b6ed
2021-01-28T01:36:58.353738Z INFO swap::protocol::alice::swap: Current state:started
```
Command:
```
run --package swap --bin swap --
--data-dir /Users/dakami/CoBloX/TEMP/swap-data-dir/alice
sell-xmr
--receive-btc 0.0006
--send-xmr 0.03
```
Co-authored-by: Daniel Karzel <daniel@comit.network>
Co-authored-by: Daniel Karzel <daniel.karzel@coblox.tech>
143: Upgrade to tokio 1.0 r=D4nte a=rishflab
When we were refactoring tests we realised we probably want the ability to abort a `tokio::JoinHandle` to kill the `EventLoop` to simulate a real world crash. tokio 1.0 is needed for this. It is probably about time to upgrade tokio anyway.
In order to upgrade to tokio 1.0 the following dependencies were also upgraded in the swap crate and monero-harness-rs
* backoff
* libp2p
* request
UPDATE: This should be merged until the following dependencies are uprgraded to Tokio 1.0 or Tokio compat is used
- [x] bitcoin-harness-rs https://github.com/coblox/bitcoin-harness-rs/pull/20
Co-authored-by: rishflab <rishflab@hotmail.com>
Co-authored-by: Franck Royer <franck@coblox.tech>
Alice was attempting to create a new event loop using the same listen addr as the old one which was still running. This commit aborts the event loop before creating a new one.
Upgrade bitcoin harness dependency to latest commit
Upgrade backoff to fix failing tests. The previous version of backoff had a broken version of the retry function. Upgraded to a newer comit which fixes this problem.
Upgrade hyper to 0.14 as the 0.13 was bringing in tokio 0.2.24
Upgraded bitcoin harness to version that uses tokio 1.0 and reqwest 0.11
Upgrade reqwest to 0.11. Reqwest 0.11 uses tokio 1.0
Upgrade libp2p to 0.34 in preparation for tokio 1.0 upgrade
159: Introduce "one shots" r=D4nte a=D4nte
Instead of Alice sending messages to Bob by replying on a `RequestResponse` channel, she just acks reception on the channel and open her own channel to send messages to Bob.
This means we do not need to carry the channel around anymore and instead carry Bob's peer id.
We take this opportunity to rename messages as per the sequence diagram.
At this stage we only touch message 4 & 5 as they are the one shots messages of the protocol.
Decoupling message 4 from message 3 (still current called 2) will allow the introduction of an await/async behaviour that handles message 1, 2, 3.
To introduce message 1, 2, 3 we will introduced the async/await behaviour using https://github.com/comit-network/rust-libp2p-async-await
First, we need to upgrade tokio and libp2p.
Please note that thanks to this change, Alice now uses Bob's peer id to send message meaning that recovery is improved (as before we could not save the channel to the db).
Co-authored-by: Franck Royer <franck@coblox.tech>
As per the proposed changed in the sequence diagram.
The aim is to have a unique terminology per message instead of having
the same name for 2 consequent messages that share the same behaviour.
Note that the aim is to remove the shared `RequestResponse` behaviours.
154: Clean up `lib.rs` r=D4nte a=D4nte
Do not remove it just yet as there are still issues with the CI but proceed with some clean up.
Merging this now to avoid further merge conflicts.
Co-authored-by: Franck Royer <franck@coblox.tech>
155: Bob saves lock proof after received so he can resume swap r=da-kami a=da-kami
Introducing a new state was too much so I added the additional required information to the enum state rather than adding another struct.
As discussed earlier we should cleanup the state machine (enum states vs data structs) at some point :)
Co-authored-by: Daniel Karzel <daniel@comit.network>
153: Remove newlines from import statements to avoid problems r=da-kami a=da-kami
Rust fmt automatically groups the imports (from top to bottom) as `pub use` `use crate` and `use`.
There is no need to introduce sections which cause annoyance when auto importing using the IDE.
Co-authored-by: Daniel Karzel <daniel@comit.network>
Rust fmt automatically groups the imports (from top to bottom) as `pub use` `use crate` and `use`.
There is no need to introduce sections which cause annoyance when auto importing using the IDE.
149: Fix Alice redeem scenario r=da-kami a=da-kami
Follow up of #144, partial fix of https://github.com/comit-network/xmr-btc-swap/issues/137
Fix Alice redeem scenario
- Properly check the timelocks before trying to redeem
- Distinguish different failure scenarios and reactions to it.
- if we fail to construct the redeem transaction: wait for cancel.
- if we fail to publish the redeem transaction: wait for cancel but let the user know that restarting the application will result in retrying to publish the tx.
- if we succeed to publish the tx but then fail when waiting for finality, print error to the user (secreat already leaked, the user has to check manually if the tx was included)
Co-authored-by: Daniel Karzel <daniel@comit.network>
142: Rename Swap amounts to Swap req/res r=D4nte a=D4nte
As per #140
Question: Do we prefer `Negotiation Request/Response` to `Swap Request/Response`?
Co-authored-by: Franck Royer <franck@coblox.tech>
- Properly check the timelocks before trying to redeem
- Distinguish different failure scenarios and reactions to it.
- if we fail to construct the redeem transaction: wait for cancel.
- if we fail to publish the redeem transaction: wait for cancel but let the user know that restarting the application will result in retrying to publish the tx.
- if we succeed to publish the tx but then fail when waiting for finality, print error to the user (secreat already leaked, the user has to check manually if the tx was included)
