Instead of forwarding every error, we deliberately ignore certain
variants that are not worth being printed to the log. In particular,
this concerns "UnsupportedProtocols" and "ResponseOmission".
To make this less verbose we introduce a macro for mapping a
`RequestResponseEvent` to `{alice,bob}::OutEvent`. We use a macro
because those `OutEvent`s are different types and the only other
way of abstracting over them would be to introduce traits that we
implement on both of them.
To make the macro easier to use, we move all the `From` implementations
that convert between the protocol and the more high-level behaviour
into the actual protocol module.
405: Concurrent swaps with same peer r=da-kami a=da-kami
Fixes#367
- [x] Concurrent swaps with same peer
Not sure how much more time I should invest into this. We could just merge the current state and then do improvements on top...?
Improvements:
- [x] Think `// TODO: Remove unnecessary swap-id check` through and remove it
- [x] Add concurrent swap test, multiple swaps with same Bob
- [ ] Save swap messages without matching swap in execution in the database
- [ ] Assert the balances in the new concurrent swap tests
- [ ] ~~Add concurrent swap test, multiple swaps with different Bobs~~
- [ ] ~~Send swap-id in separate message, not on top of `Message0`~~
Co-authored-by: Daniel Karzel <daniel@comit.network>
- Swap-id is exchanged during execution setup. CLI (Bob) sends the swap-id to be used in his first message.
- Transfer poof and encryption signature messages include the swap-id so it can be properly associated with the correct swap.
- ASB: Encryption signatures are associated with swaps by swap-id, not peer-id.
- ASB: Transfer proofs are still associated to peer-ids (because they have to be sent to the respective peer), but the ASB can buffer multiple
- CLI: Incoming transfer proofs are checked for matching swap-id. If a transfer proof with a different swap-id than the current executing swap is received it will be ignored. We can change this to saving into the database.
Includes concurrent swap tests with the same Bob.
- One test that pauses and starts an additional swap after the transfer proof was received. Results in both swaps being redeemed after resuming the first swap.
- One test that pauses and starts an additional swap before the transfer proof is sent (just after BTC locked). Results in the second swap redeeming and the first swap being refunded (because the transfer proof on Bob's side is lost). Once we store transfer proofs that we receive during executing a different swap into the database both swaps should redeem.
Note that the monero harness was adapted to allow creating wallets with multiple outputs, which is needed for Alice.
`check_tx_key` can run into an overflow error when handling `-1` values for confirmations.
This most likely happens when a transaction is not in mempool yet.
In order to avoid unwanted side effects in the tests (i.e. failure because the transfer is seemingly confirmed, when it is not yet),
we add a guard that checks for values close to u64::MAX.
Note that we cannot check for the exact value of u64::MAX, because it seems that there is an addition somewhere in monerod/wallet-rpc,
that results in `-1` (first), `-2` (second) (...) until the transaction is in mempool.
397: Always log at debug level to file r=rishflab a=rishflab
WILL SQUASH DOWN TO 3 COMMITS WHEN APPROVED!
Log at debug level to file
EnvFilter is applied globally. This means you cannot log at INFO level
to the terminal and at DEBUG level to log files. To get a around this
limitation I had to implement the layer trait on a new type and filter
in the on_event() trait method. Each swap has its own log file denoted
by its swap_id. The logger appends to the existing file when resuming a
swap.
Closes#278
I think the `DebugTerminalPritner` and `InfoTerminalPrinter` could be consolidated with some effort with some generics wizardry. It works for now and I think it can be done later. I wish in general there was a cleaner way to do this.
Co-authored-by: rishflab <rishflab@hotmail.com>
EnvFilter is applied globally. This means you cannot log at INFO level
to the terminal and at DEBUG level to log files. To get a around this
limitation I had to implement the layer trait on a new type and filter
in the on_event() trait method. Each swap has its own log file denoted
by its swap_id. The logger appends to the existing file when resuming a
swap.
Closes#278
402: Update ASB docs r=thomaseizinger a=da-kami
- remove outdated known limitations
- link to latest release
- mention of resuming swap upon restart and Bitcoin commands
Co-authored-by: Daniel Karzel <daniel@comit.network>
399: Bump bmrng from 0.5.0 to 0.5.1 r=thomaseizinger a=dependabot[bot]
Bumps [bmrng](https://github.com/oguzbilgener/bmrng) from 0.5.0 to 0.5.1.
<details>
<summary>Commits</summary>
<ul>
<li><a href="c2dad4d718"><code>c2dad4d</code></a> (cargo-release) version 0.5.1</li>
<li><a href="9c7b9b5e64"><code>9c7b9b5</code></a> fix: Implement for ReceiveError</li>
<li><a href="bfe74a5af9"><code>bfe74a5</code></a> docs: Fix inaccuracies around send</li>
<li><a href="d282479172"><code>d282479</code></a> (cargo-release) start next development iteration 0.5.1-alpha.0</li>
<li>See full diff in <a href="https://github.com/oguzbilgener/bmrng/compare/v0.5.0...v0.5.1">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
400: Release version 0.4.0 r=da-kami a=comit-botty-mc-botface
Hi @da-kami!
This PR was created in response to a manual trigger of the release workflow here: https://github.com/comit-network/xmr-btc-swap/actions/runs/721831897.
I've updated the changelog and bumped the versions in the manifest files in this commit: 1687f84aa1.
Merging this PR will create a GitHub release and upload any assets that are created as part of the release build.
Co-authored-by: COMIT Botty McBotface <botty@coblox.tech>
Co-authored-by: Daniel Karzel <daniel@comit.network>
396: Remove default connection details from CLI r=thomaseizinger a=rishflab
Connecting buyers to us by default is not consistent with our vision of
a decentralised network of sellers.
Closes#395
Co-authored-by: rishflab <rishflab@hotmail.com>
398: Bump dprint/check from v1 to v1.2 r=thomaseizinger a=dependabot[bot]
Bumps [dprint/check](https://github.com/dprint/check) from v1 to v1.2.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/dprint/check/releases">dprint/check's releases</a>.</em></p>
<blockquote>
<h2>v1.2</h2>
<p>Upgrade to support new <em>dprint.json</em> configuration file name.</p>
<h2>v1.1</h2>
<p>Upgrades to dprint 0.12.0 for support for the new <em>dprint.json</em> configuration file.</p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="58765d1963"><code>58765d1</code></a> fix: Fix version in README.md</li>
<li><a href="3951ef3848"><code>3951ef3</code></a> feat: Upgrade to dprint 0.12.0</li>
<li><a href="5a6244b61d"><code>5a6244b</code></a> chore: Update instructions.</li>
<li>See full diff in <a href="https://github.com/dprint/check/compare/v1...58765d19636462e70cd83fe4de8dfc16e7d6f5d2">compare view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
387: Improve the resilience of the network layer r=thomaseizinger a=thomaseizinger
We improve the resilience in two ways:
1. Use a timeout on Bob's side for the execution-setup.
2. Use the `bmrng` library to model the communication between Alice and Bob.
See commit messages for details.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
391: asb Bitcoin withdraw and balance commands r=da-kami a=da-kami
Fixes#368
Note: Balance prints both balances - which assumes that the Monero wallet RPC is running. I think that is fine for now.
Co-authored-by: Daniel Karzel <daniel@comit.network>
Edge cases of UTXOs where value < fee cause the BDK's `coin_select` calculation to panic.
This issue was fixed upstream thus we point the BDK dependency against the commit of the merged fix.
376: ASB resumes unfinished swaps after startup r=da-kami a=da-kami
Fixes#374
- [x] Save Bob peer-id in database for Alice
- [x] Alice: Wait for `10` Monero confirmations in `BtcRefunded` instead of `XmrLocked` (requires extending the RPC to distinguish locked / unlocked balance)
- [x] Save Alice peer-id in database for Bob ~~(+ multiaddress and remove params from resume)~~
- [ ] ~~Refactor Bob in test setup (handle event-loop in test setup similar to Alice)~~
I decided against refactoring Bob in the test setup, because eventually we might still want to add concurrent swap tests with multiple Bobs. The refactoring I had in mind would not allow such kind of tests.
Generally, the current state of the changes already contains enough added value to open the PR :)
Follow ups out of scope
- [ ] Parametrize database with role (Alice / Bob) and remove all the (currently useless) mapping between DB and protocol types.
- [ ] Alice: Wait for transfer proof ack before transitioning to new `XmrLocked`
Co-authored-by: Daniel Karzel <daniel@comit.network>
It might very well be that the cancel transaction is already published.
If that is the case, there is no point in failing the command. We simply
transition to cancel and exit normally.
The reason this comes up now is because Alice now properly waits for
the cancel timelock as well and publishes the cancel transaction first.
Ultimately, she should not do that because there is no benefit to her
unless she can also publish the punish transaction.
