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.
Sending the transfer proof might never resolve because Bob doesn't
come back online. In that case, we need to make sure we bail out
as soon as the timelock expires.
We use the "precondition" feature of the `tokio::select!` macro to
avoid polling certain futures. In particular, we skip polling all
futures that - when resolved - require us to send a message to Alice.
This allows us to delay the ACKing of the encrypted signature up until
the swap has actually requested it.
Similarly, it allows us to wait for the ACK of the transfer proof within
the swap before continuing.
bmrng is a library providing a request-response channel that allows
the receiving end of the channel to send a response back to the sender.
This allows us to more accurately implement the functions on the
`EventLoopHandle`. In particular, we now _wait_ for the ACK of specific
messages from the other party before resolving the future.
For example, when sending the encrypted signature, the async function
on the `EventLoopHandle` does not resolve until we received the ACK
from the other party.
We also delete the `Channels` abstraction in favor of directly creating
bmrng channels. This allows us to directly control the channel buffer
which we set to 1 because we don't need more than that on Bob's side.
There is no point in first checking for the expired timelocks and
then constructing a `select!` that also watches for the timelock to
expiry.
We can simply only have the select! invocation to achieve the same
effect. In case the timelock is already expired, this future will
resolve immediately.
Normally, the polling order of `select!` is pseudo-random. We
configure it to be _biased_ here to make sure the futures are polled
in order.
The execution setup is our only libp2p protocol that doesn't have
a timeout built-in. Hence, if anything fails on Alice's side, we
would wait here forever.
Wrapping the future in a timeout ensures that we fail eventually
if this protocol doesn't succeed.
We don't need to hide the fields of this Behaviour as the only reason
for why this struct exists is because libp2p forces us to compose our
NetworkBehaviours into a new struct.
This allows loading the seller-peer-id from the database upon resuming a swap.
Thus, the parameters `--seller-peer-id` is removed for the `resume` command.
Other than the peer-id the multi address of a seller can change and thus is
still a parameter. This parameter might become optional once we add DHT support.
Awaiting the confirmations in an earlier state can cause trouble with resuming
swaps with short cancel expiries (test scenarios).
Since it is the responsibility of the refund state to ensure that the XMR can
be sweeped, we now ensure that the lock transaction has 10 confirmations before
refunding the XMR using generate_from_keys.
Sending the transfer transaction in a distinct state helps ensuring
that we do not send the Monero lock transaction twice in a restart
scenario.
Waiting for the first transaction confirmation in a separate state
helps ensuring that we send the transfer proof in a restart scenario.
Once we resume unfinished swaps upon startup we have to ensure that
it is safe for Alice to act.
If Bob has locked BTC it is only make sense for Alice to lock up the
XMR as long as no timelock has expired. Hence we abort if the BTC is
locked, but any timelock expired already.
393: Re-word changelog entry for bad readiness check of monero-wallet-rpc r=thomaseizinger a=thomaseizinger
Fix the formatting to be one line per sentence and re-word to focus on what didn't work for the user.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
392: Bump monero from 0.11.1 to 0.11.2 r=thomaseizinger a=dependabot[bot]
Bumps [monero](https://github.com/monero-rs/monero-rs) from 0.11.1 to 0.11.2.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/monero-rs/monero-rs/releases">monero's releases</a>.</em></p>
<blockquote>
<h2>0.11.2</h2>
<p><strong>Changelog</strong></p>
<ul>
<li>Fix docs.rs compilation errors, add <code>feature(doc_cfg)</code> when building on docs.rs</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="c5d6396c00"><code>c5d6396</code></a> Fix doc cfg, bump version</li>
<li>See full diff in <a href="https://github.com/monero-rs/monero-rs/compare/v0.11.1...v0.11.2">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>
