Our strategy of searching for a english string to determine if
monero_wallet_rpc is ready is not compatible with languages other than
english. Instead we assume the monero rpc is ready if it has stopped
writing to stdout. We make a json rpc request to confirm this. A better
solution would have been to configure the monero_wallet_rpc to always
output in english but there is not command line argument to configure
the language.
Closes#353.
Whenever a release branch - that is a branch starting with `release/` -
is merged into master, we create a new GitHub release based on the
version number in the branch name.
Similarly to the preview release, we extract the relevant section of
the changelog and make it the release body.
Drafting a new release can be quite involved. One has to update the
changelog correctly, bump the versions in the manifest files, commit
everything and raise a PR.
This workflow does all of that for you at the click of a button!
359: Bump bdk from 0.4.0 to 0.5.0 r=thomaseizinger a=dependabot[bot]
Bumps [bdk](https://github.com/bitcoindevkit/bdk) from 0.4.0 to 0.5.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/bitcoindevkit/bdk/blob/master/CHANGELOG.md">bdk's changelog</a>.</em></p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="f7944e871b"><code>f7944e8</code></a> Bump version to 0.5.0</li>
<li><a href="2fea1761c1"><code>2fea176</code></a> Bump deps version</li>
<li><a href="fa27ae210f"><code>fa27ae2</code></a> Update version in lib.rs</li>
<li><a href="46fa41470e"><code>46fa414</code></a> Update CHANGELOG with the new release tag</li>
<li><a href="8ebe7f0ea5"><code>8ebe7f0</code></a> Merge commit 'refs/pull/308/head' of github.com:bitcoindevkit/bdk into releas...</li>
<li><a href="eb85390846"><code>eb85390</code></a> Merge commit 'refs/pull/309/head' of github.com:bitcoindevkit/bdk into releas...</li>
<li><a href="dc83db273a"><code>dc83db2</code></a> better derivation path building</li>
<li><a href="201bd6ee02"><code>201bd6e</code></a> better derivation path building</li>
<li><a href="396ffb42f9"><code>396ffb4</code></a> handle descriptor xkey origin</li>
<li><a href="9cf62ce874"><code>9cf62ce</code></a> [ci] Manually install libclang-common-10-dev to 'check-wasm' job</li>
<li>Additional commits viewable in <a href="https://github.com/bitcoindevkit/bdk/compare/v0.4.0...v0.5.0">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>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
370: No Bitcoin deposit for Alice r=da-kami a=da-kami
The message to deposit Bitcoin only applies to Bob, not Alice.
Alice does not require any initial Bitcoin.
Co-authored-by: Daniel Karzel <daniel@comit.network>
340: Remove connection handling from swap execution and cleanup network protocol implementations r=thomaseizinger a=thomaseizinger
TODO:
- [x] Re-establish connection on Bob's side if it is dropped.
- [x] Make sure Alice buffers messages if there isn't currently a connection
- [x] Do a testnet swap to make sure it works
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
The request-response behaviour that is used for sending the transfer
proof actually has a functionality for buffering a message if we
are currently not connected. However, the request-response behaviour
also emits a dial attempt and **drops** all buffered messages if this
dial attempt fails. For us, the dial attempt will very likely always
fail because Bob is very likely behind NAT and we have to wait for
him to reconnect to us.
To mitigate this, we build our own buffer within the EventLoop and
send transfer proofs as soon as we are connected again.
Resolves#348.
The swap should not be concerned with connection handling. This is
the responsibility of the overall application.
All but the execution-setup NetworkBehaviour are `request-response`
behaviours. These have built-in functionality to automatically emit
a dial attempt in case we are not connected at the time we want to
send a message. We remove all of the manual dialling code from the
swap in favor of this behaviour.
Additionally, we make sure to establish a connection as soon as the
EventLoop gets started. In case we ever loose the connection to Alice,
we try to re-establish it.
Decomposing a RequestResponseEvent is quite verbose. We can introduce
a helper function that does the matching for us and delegates to
specific `From` implementations for the protocol specific bits.
356: Bump serde from 1.0.124 to 1.0.125 r=thomaseizinger a=dependabot[bot]
Bumps [serde](https://github.com/serde-rs/serde) from 1.0.124 to 1.0.125.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/serde-rs/serde/releases">serde's releases</a>.</em></p>
<blockquote>
<h2>v1.0.125</h2>
<ul>
<li>Improve performance of serializing <code>Ipv4Addr</code> (<a href="https://github-redirect.dependabot.com/serde-rs/serde/issues/2001">#2001</a>, thanks <a href="https://github.com/saethlin"><code>@saethlin</code></a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="e9270e59f0"><code>e9270e5</code></a> Release 1.0.125</li>
<li><a href="72060b779a"><code>72060b7</code></a> Extend test_format_u8 to include u8::MAX</li>
<li><a href="1bb23ad9d1"><code>1bb23ad</code></a> Remove format_u8 when not used by Ipv4Addr impl</li>
<li><a href="9be4c9654a"><code>9be4c96</code></a> Merge pull request 2001 from saethlin/optimize-ipaddr</li>
<li><a href="4114e90bac"><code>4114e90</code></a> Fix off-by-one mistake, explain the offset</li>
<li><a href="8bb07b0743"><code>8bb07b0</code></a> skip UTF8 checking and initialize with b'.'</li>
<li><a href="ba8c1d63c8"><code>ba8c1d6</code></a> use the algorithm from itoa</li>
<li><a href="857a805993"><code>857a805</code></a> Faster Ipv4 serialization prototype</li>
<li>See full diff in <a href="https://github.com/serde-rs/serde/compare/v1.0.124...v1.0.125">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>
355: Bump anyhow from 1.0.38 to 1.0.39 r=thomaseizinger a=dependabot[bot]
Bumps [anyhow](https://github.com/dtolnay/anyhow) from 1.0.38 to 1.0.39.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/dtolnay/anyhow/releases">anyhow's releases</a>.</em></p>
<blockquote>
<h2>1.0.39</h2>
<ul>
<li>
<p>Add an opt-in implementation of <a href="https://docs.rs/anyhow/1.0.39/anyhow/struct.Error.html#method.backtrace"><code>Error::backtrace</code></a> on stable compilers based on the <code>backtrace</code> crate (<a href="https://github-redirect.dependabot.com/dtolnay/anyhow/issues/143">#143</a>)</p>
<pre lang="toml"><code>[dependencies]
anyhow = { version = "1.0", features = ["backtrace"] }
</code></pre>
</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="8599c7b532"><code>8599c7b</code></a> Release 1.0.39</li>
<li><a href="d65af362cc"><code>d65af36</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/dtolnay/anyhow/issues/143">#143</a> from dtolnay/backtrace</li>
<li><a href="0ba6408b5e"><code>0ba6408</code></a> Add stable backtrace feature</li>
<li><a href="7e85baecce"><code>7e85bae</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/dtolnay/anyhow/issues/142">#142</a> from dtolnay/backtrace</li>
<li><a href="a476ec40ce"><code>a476ec4</code></a> Indicate a doc_cfg on the Error backtrace() method</li>
<li><a href="fea4d8a8f6"><code>fea4d8a</code></a> Eliminate some needlessly cfg'd Backtrace imports</li>
<li><a href="1631007931"><code>1631007</code></a> Ignore new missing_panics_doc pedantic clippy lint</li>
<li><a href="36265418da"><code>3626541</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/dtolnay/anyhow/issues/137">#137</a> from dtolnay/cast</li>
<li><a href="3fdef75780"><code>3fdef75</code></a> Revert "Show turbofish optional"</li>
<li><a href="4e776b8b52"><code>4e776b8</code></a> Force turbofish on all calls of .cast::<U>()</li>
<li>Additional commits viewable in <a href="https://github.com/dtolnay/anyhow/compare/1.0.38...1.0.39">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>
339: Bump dependency versions r=thomaseizinger a=thomaseizinger
Otherwise it will take a long time for dependabot to update all of
these.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
351: Show the actual BTC amount and fee to be swapped r=da-kami a=da-kami
We got user feedback, that it is confusing that the amount "found" in the wallet does not match the amount actually being swapped, thus with this PR we explicitly display the amount swapped and fees.
Co-authored-by: Daniel Karzel <daniel@comit.network>
319: Alice sweeps refunded funds into default wallet r=da-kami a=da-kami
Alice's refund scenario starts with generating the temporary wallet
from keys to claim the XMR which results in Alice' unloading the wallet.
Alice then loads her original wallet to be able to handle more swaps.
Since Alice is in the role of the long running daemon handling concurrent
swaps, the operation to close, claim and re-open her default wallet must
be atomic.
This PR adds an additional step, that sweeps all the refunded XMR back into
the default wallet. In order to ensure that this is possible, Alice has to
ensure that the locked XMR got enough confirmations.
These changes allow us to assert Alice's balance after refunding.
Co-authored-by: Daniel Karzel <daniel@comit.network>
If we enter a punish scenario we can be sure the punish timelock is expired.
Thus, we must be able to punish unless Bob published the refund transaction.
There is no benefit in racing punish against refund here, because we cannot recover from a punish tx failure anyway.
The logic was changed to:
Try to broadcast punish tx and await finality.
If either punish broadcasting of finality fails, try to fetch the refund transaction.
If it is available extract Bob's Monero key part and transition to refund.
If refund tx is not available fail without a status update.
Note that we do not distinguish different errors upon failure of punish, because
we cannot recover anyway. If we fail to retrieve Bob's refund tx, we just exit without
a status update so punish can be retried by resuming the swap.
325: Misc cleanup r=thomaseizinger a=thomaseizinger
Miscellaneous cleanups of the `swap`, `state` and `steps` modules.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Since Alice's refund scenario starts with generating the temporary wallet
from keys to claim the XMR which results in Alice' unloading the wallet.
Alice then loads her original wallet to be able to handle more swaps.
Since Alice is in the role of the long running daemon handling concurrent
swaps, the operation to close, claim and re-open her default wallet must
be atomic.
This PR adds an additional step, that sweeps all the refunded XMR back into
the default wallet. In order to ensure that this is possible, Alice has to
ensure that the locked XMR got enough confirmations.
These changes allow us to assert Alice's balance after refunding.
To achieve this, we decompose `watch_for_locked_xmr` into two parts:
1. A non-self-consuming function to construct a `WatchRequest`
2. A state transition that can now consume `self` again because
it is only called once within the whole select! expression.
Ideally, we would move more logic onto this state transition (like
comparing the actual amounts and fail the transition if it is not
valid). Doing so would have an unfortunate side-effect: We would
always wait for the full confirmations before checking whether or
not we actually receive enough XMR.
This allows us to have state transitions that consume self.
