This command uses a rendezvous node to find sellers (i.e. ASBs) and query them for quotes.
Sellers, that can be dialed and queried for a quote will be listed.
604: Bump torut from 0.1.9 to 0.1.10 r=thomaseizinger a=dependabot[bot]
Bumps [torut](https://github.com/teawithsand/torut) from 0.1.9 to 0.1.10.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/teawithsand/torut/releases">torut's releases</a>.</em></p>
<blockquote>
<h2>Release 0.1.10</h2>
<p>Deprecated onion services V2 and all stuff associated with it.
Updated tokio version.
Implemented std::error::Error for error types in this crate, support for these errors is very basic and all that was done was implementing Error trait for existing error types. No error structure refactoring was done.</p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="8a26ddde79"><code>8a26ddd</code></a> Implemented std::error::Error for error types</li>
<li><a href="c5cee8a369"><code>c5cee8a</code></a> Implemented std::error::Error for error types</li>
<li><a href="caed51d697"><code>caed51d</code></a> Deprecated v2 onion service stuff</li>
<li><a href="87bcde20bb"><code>87bcde2</code></a> Updated tokio version</li>
<li>See full diff in <a href="https://github.com/teawithsand/torut/compare/v0.1.9...v0.1.10">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
You can trigger a rebase of this PR 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>
605: Merge `--seller-addr` and `--seller-peer-id` into `--seller` parameter r=thomaseizinger a=thomaseizinger
This simplifies the CLI's interface.
It wills also play nicely with https://github.com/comit-network/xmr-btc-swap/pull/593.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Instead of formatting to a string right away, we parse the multiaddress
into a stricter data structure that only allows the kind of addresses
we can dial through Tor.
This will allow us to perform further checks on the parsed address.
585: Configurable kraken websocket url via the ASB config r=thomaseizinger a=cimble-code
- Allows the ASB operator to configure a custom kraken websocket url via the ASB config.
- Addresses the issue of price control first brought up [here](https://github.com/comit-network/xmr-btc-swap/discussions/571)
> Gotya.
There is a relatively easy to implement (but temporary) solution for that. We could let the user configure the kraken websocket url via the ASB config. That way you can plug in your own service. The only requirement is that your service publishes prices updates in the same format as [kraken](https://docs.kraken.com/websockets/), e.g. :
_Originally posted by @bonomat in https://github.com/comit-network/xmr-btc-swap/discussions/571#discussioncomment-885535_
Co-authored-by: Your Name <you@example.com>
Closing the connection upon completing the `swap_setup` protocol caused problems on the ASB side, because the CLI would close the connection before the last message was properly processed. This would result in swaps going into execution on the CLI side, but not on the ASB side.
The CLI ensures an open connection to the ASB over the complete course of a swap. So it does not make much sense to allow a protocol to close the connection (the CLI would immediately redial).
For the Alice we set the initial `KeepAlive` to `10` seconds because Bob is expected to request a spot price in reasonable time after opening a connection on the protocol. Since Tor connections can take some time we set 10 seconds fow now for resilience.
Given that we combined the `spot_price` and the `execution_setup` messaging into one protocol we should allow the protocol to take longer than 60 seconds to complete.
This is especially important for connections over Tor, where messaging can take significantly longer than over clearnet.
I ran some tests with Tor and did not run into issues with the 60 seconds, but we get very close to the timeout, so we better make it more resilient by adding more time.
When swapping on testnet we ran into a problem where the CLI started the swap after sending all messages successfully, but the ASB ran into a `connection closed` error at the end of the `swap_setup` and the swap state machine was never actually triggered.
Flushing and closing the stream on both sides should ensure that we don't run into this problem and both parties gracefully exit the protocol.
Some network and application specific code does not belong in the protocol module and was moved.
Eventloop, recovery and the outside behaviour were moved to the respective application module because they are application specific.
The `swap_setup` was moved into the network module because upon change both sides will have to be changed and should thus stay close together.
Having `spot_price` and `execution_setup` as separate protocols did not bring any advantages, but was problematic because we had to ensure that `execution_setup` would be triggered after `spot_price`. Because of this dependency it is better to combine the protocols into one.
Combining the protocols also allows a refactoring to get rid of the `libp2p-async-await` dependency.
Alice always listens for the `swap_setup` protocol. When Bob opens a substream on that protocol the spot price is communicated, and then all execution setup messages (swap-id and signature exchange).
Includes a new state that is used to await BTC lock tx finality. Upon starting the swap we initially only wait for the BTC lock tx to be seen in the mempool.
This is guarded by a short timeout (3 mins), because it is assumed that in the current setup (sport_price + execution_setup only triggered upon funds being available already) the lock transaction should be picked up almost instanly after the execution setup succeeded.
Similar to the CLI the ASB has to ensure that the execution_setup is executed within a certain time.
Without a timeout the price (returned by `spot_price` would be guaranteed with the CLI indefinitely.
It seems the current chosen channel timeouts are still not optimal.
I ran into issues with swapping over Tor and traced them down to the CLI timeout of the bmrng channel.
It appears that the ASB was not running as quick as the CLI, which caused a timeout on the CLI side (in addition to the delay when sending messages over Tor).
Only `execution_setup` caused the problem so far, but I would recommend changing all the channel timeouts to one minute to avoid this problem.
581: Remove dead code r=thomaseizinger a=da-kami
583: Bump reqwest from 0.11.3 to 0.11.4 r=thomaseizinger a=dependabot[bot]
Bumps [reqwest](https://github.com/seanmonstar/reqwest) from 0.11.3 to 0.11.4.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/seanmonstar/reqwest/releases">reqwest's releases</a>.</em></p>
<blockquote>
<h2>v0.11.4</h2>
<ul>
<li>Add <code>ClientBuilder::resolve()</code> option to override DNS resolution for specific domains.</li>
<li>Add <code>native-tls-alpn</code> Cargo feature to use ALPN with the native-tls backend.</li>
<li>Add <code>ClientBuilder::deflate()</code> option and <code>deflate</code> Cargo feature to support decoding response bodies using deflate.</li>
<li>Add <code>RequestBuilder::version()</code> to allow setting the HTTP version of a request.</li>
<li>Fix allowing "invalid" certificates with the <code>rustls-tls</code> backend, when the server uses TLS v1.2 or v1.3.</li>
<li>(wasm) Add <code>try_clone</code> to <code>Request</code> and <code>RequestBuilder</code></li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/seanmonstar/reqwest/blob/master/CHANGELOG.md">reqwest's changelog</a>.</em></p>
<blockquote>
<h2>v0.11.4</h2>
<ul>
<li>Add <code>ClientBuilder::resolve()</code> option to override DNS resolution for specific domains.</li>
<li>Add <code>native-tls-alpn</code> Cargo feature to use ALPN with the native-tls backend.</li>
<li>Add <code>ClientBuilder::deflate()</code> option and <code>deflate</code> Cargo feature to support decoding response bodies using deflate.</li>
<li>Add <code>RequestBuilder::version()</code> to allow setting the HTTP version of a request.</li>
<li>Fix allowing "invalid" certificates with the <code>rustls-tls</code> backend, when the server uses TLS v1.2 or v1.3.</li>
<li>(wasm) Add <code>try_clone</code> to <code>Request</code> and <code>RequestBuilder</code></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="f5fe17876a"><code>f5fe178</code></a> v0.11.4</li>
<li><a href="8e5af459e5"><code>8e5af45</code></a> Allow overriding of DNS resolution to specified IP addresses(<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/561">#561</a>) (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/1277">#1277</a>)</li>
<li><a href="c4388fcff9"><code>c4388fc</code></a> WASM: Add <code>try_clone</code> implementations to <code>Request</code> and <code>RequestBuilder</code> (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/1286">#1286</a>)</li>
<li><a href="b48cb4a5aa"><code>b48cb4a</code></a> Add native-tls-alpn feature (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/1283">#1283</a>)</li>
<li><a href="bbeb1ede4e"><code>bbeb1ed</code></a> Bump ssri from 6.0.1 to 6.0.2 in /examples/wasm_github_fetch (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/1262">#1262</a>)</li>
<li><a href="841d47c6a2"><code>841d47c</code></a> Bump url-parse from 1.4.7 to 1.5.1 in /examples/wasm_github_fetch (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/1267">#1267</a>)</li>
<li><a href="33bc7939b4"><code>33bc793</code></a> Bump lodash from 4.17.19 to 4.17.21 in /examples/wasm_github_fetch (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/1269">#1269</a>)</li>
<li><a href="b0af278f78"><code>b0af278</code></a> Implement "default" functions of the trait to fix "insecure" mode (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/1259">#1259</a>)</li>
<li><a href="8d3e27966c"><code>8d3e279</code></a> use ZlibDecoder for deflate responses (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/1257">#1257</a>)</li>
<li><a href="b88f309339"><code>b88f309</code></a> Fix small typos in <code>Client</code> docs (<a href="https://github-redirect.dependabot.com/seanmonstar/reqwest/issues/1253">#1253</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/seanmonstar/reqwest/compare/v0.11.3...v0.11.4">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
You can trigger a rebase of this PR 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: Daniel Karzel <daniel@comit.network>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
566: Bump rand_chacha from 0.3.0 to 0.3.1 r=thomaseizinger a=dependabot[bot]
Bumps [rand_chacha](https://github.com/rust-random/rand) from 0.3.0 to 0.3.1.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/rust-random/rand/blob/master/CHANGELOG.md">rand_chacha's changelog</a>.</em></p>
<blockquote>
<h2>[0.3.19] - 2017-12-27</h2>
<h3>Changed</h3>
<ul>
<li>Require <code>log <= 0.3.8</code> for dev builds</li>
<li>Update <code>fuchsia-zircon</code> dependency to 0.3</li>
<li>Fix broken links in docs (to unblock compiler docs testing CI)</li>
</ul>
<h2>[0.3.18] - 2017-11-06</h2>
<h3>Changed</h3>
<ul>
<li><code>thread_rng</code> is seeded from the system time if <code>OsRng</code> fails</li>
<li><code>weak_rng</code> now uses <code>thread_rng</code> internally</li>
</ul>
<h2>[0.3.17] - 2017-10-07</h2>
<h3>Changed</h3>
<ul>
<li>Fuchsia: Magenta was renamed Zircon</li>
</ul>
<h2>[0.3.16] - 2017-07-27</h2>
<h3>Added</h3>
<ul>
<li>Implement Debug for mote non-public types</li>
<li>implement <code>Rand</code> for (i|u)i128</li>
<li>Support for Fuchsia</li>
</ul>
<h3>Changed</h3>
<ul>
<li>Add inline attribute to SampleRange::construct_range.
This improves the benchmark for sample in 11% and for shuffle in 16%.</li>
<li>Use <code>RtlGenRandom</code> instead of <code>CryptGenRandom</code></li>
</ul>
<h2>[0.3.15] - 2016-11-26</h2>
<h3>Added</h3>
<ul>
<li>Add <code>Rng</code> trait method <code>choose_mut</code></li>
<li>Redox support</li>
</ul>
<h3>Changed</h3>
<ul>
<li>Use <code>arc4rand</code> for <code>OsRng</code> on FreeBSD.</li>
<li>Use <code>arc4random(3)</code> for <code>OsRng</code> on OpenBSD.</li>
</ul>
<h3>Fixed</h3>
<ul>
<li>Fix filling buffers 4 GiB or larger with <code>OsRng::fill_bytes</code> on Windows</li>
</ul>
<h2>[0.3.14] - 2016-02-13</h2>
<h3>Fixed</h3>
<ul>
<li>Inline definitions from winapi/advapi32, which decreases build times</li>
</ul>
<h2>[0.3.13] - 2016-01-09</h2>
<h3>Fixed</h3>
<ul>
<li>Compatible with Rust 1.7.0-nightly (needed some extra type annotations)</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="98a0339f99"><code>98a0339</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/rust-random/rand/issues/1135">#1135</a> from dhardy/work</li>
<li><a href="a7f8fb72d7"><code>a7f8fb7</code></a> Prepare rand_chacha v0.3.1 release</li>
<li><a href="09d3df3119"><code>09d3df3</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/rust-random/rand/issues/1130">#1130</a> from dhardy/work</li>
<li><a href="d167dd25d2"><code>d167dd2</code></a> Deprecate ReadRng</li>
<li><a href="e3bc4a1357"><code>e3bc4a1</code></a> Do not impl serde for ReadRng or ReseedingRng</li>
<li><a href="66b163632e"><code>66b1636</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/rust-random/rand/issues/1132">#1132</a> from rust-random/readme-wasm-note</li>
<li><a href="d9c6a76048"><code>d9c6a76</code></a> README: add note regarding wasm32-unknown-unknown</li>
<li><a href="4726d328d6"><code>4726d32</code></a> Update minimum version of packed_simd_2</li>
<li><a href="f6bbfcfa89"><code>f6bbfcf</code></a> serde for BlockRng, ReseedingRng and ReadRng</li>
<li><a href="2732f2d6a8"><code>2732f2d</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/rust-random/rand/issues/1116">#1116</a> from vks/criterion</li>
<li>Additional commits viewable in <a href="https://github.com/rust-random/rand/compare/rand_chacha-0.3.0...rand_chacha-0.3.1">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
You can trigger a rebase of this PR 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>
568: Bump bdk from 0.7.0 to 0.8.0 r=thomaseizinger a=dependabot[bot]
Bumps [bdk](https://github.com/bitcoindevkit/bdk) from 0.7.0 to 0.8.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="33b45ebe82"><code>33b45eb</code></a> Bump version to 0.8.0</li>
<li><a href="2faed425ed"><code>2faed42</code></a> Update CHANGELOG</li>
<li><a href="2cc05c07a5"><code>2cc05c0</code></a> Bump version in <code>src/lib.rs</code></li>
<li><a href="9205295332"><code>9205295</code></a> Merge commit 'refs/pull/365/head' of github.com:bitcoindevkit/bdk into releas...</li>
<li><a href="3b446c9e14"><code>3b446c9</code></a> Use no_run instead of ignore</li>
<li><a href="378167efca"><code>378167e</code></a> Remove explicit <code>feature(external_doc)</code></li>
<li><a href="224be27aa8"><code>224be27</code></a> Fix example/doctests format</li>
<li><a href="4a23070cc8"><code>4a23070</code></a> [ci] Check fmt for examples/doctests</li>
<li><a href="f8117c0f9f"><code>f8117c0</code></a> Bump version to 0.8.0-rc.1</li>
<li><a href="0ec064ef13"><code>0ec064e</code></a> Use AddressInfo in private methods</li>
<li>Additional commits viewable in <a href="https://github.com/bitcoindevkit/bdk/compare/v0.7.0...v0.8.0">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
You can trigger a rebase of this PR 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>
Instead of splitting up the transports into capabilities, we compose
them directly for each application. This allows us to remove the
websocket transport for the CLI which is really only needed for the
ASB to allow retrieval of quotes via the browser.
Libp2p's transports are meant to be composed. Hence, any form of
fallback should be implemented by emitting `MultiaddrNotSupported`
from the `listen` and `dial` functions.
This allows us to completely remove the tcp transport from the tor
transport.
515: Make it easier to create a bitcoin::Wallet for testing r=thomaseizinger a=thomaseizinger
Forcing the user to create an implementation of `EstimateFeeRate`
every time they want to create a wallet for testing is tedious and
leads to duplicated code.
The implementation for tests is rarely dynamic and thus can be
simplified to static arguments.
This also allows us to provide convenience constructors to make tests
that don't care about fees less distracting by reducing the number of
constants that are floating around.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
531: Bump thiserror from 1.0.24 to 1.0.25 r=thomaseizinger a=dependabot[bot]
Bumps [thiserror](https://github.com/dtolnay/thiserror) from 1.0.24 to 1.0.25.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/dtolnay/thiserror/releases">thiserror's releases</a>.</em></p>
<blockquote>
<h2>1.0.25</h2>
<ul>
<li>Support <code>error(transparent)</code> on errors containing a non-<code>'static</code> inner error (<a href="https://github-redirect.dependabot.com/dtolnay/thiserror/issues/113">#113</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="19cb5cee4b"><code>19cb5ce</code></a> Release 1.0.25</li>
<li><a href="e49c10f2ba"><code>e49c10f</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/dtolnay/thiserror/issues/134">#134</a> from dtolnay/nonstatic</li>
<li><a href="1ed8751081"><code>1ed8751</code></a> Support non-static AsDynError lifetimes</li>
<li><a href="51a1ff6593"><code>51a1ff6</code></a> Add regression test for issue 113</li>
<li><a href="ee2a47d3af"><code>ee2a47d</code></a> Adjust macro hygiene test formatting</li>
<li><a href="c610d97267"><code>c610d97</code></a> Update ui test suite to nightly-2021-05-14</li>
<li><a href="c10adbc25e"><code>c10adbc</code></a> Ignore manual_map clippy lint</li>
<li>See full diff in <a href="https://github.com/dtolnay/thiserror/compare/1.0.24...1.0.25">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>
535: Bitcoin network check when building PSBT r=da-kami a=da-kami
This ensures that funds are not sent to an address on the wrong network.
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Daniel Karzel <daniel@comit.network>
Forcing the user to create an implementation of `EstimateFeeRate`
every time they want to create a wallet for testing is tedious and
leads to duplicated code.
The implementation for tests is rarely dynamic and thus can be
simplified to static arguments.
This also allows us to provide convenience constructors to make tests
that don't care about fees less distracting by reducing the number of
constants that are floating around.
Adds the ping behaviour to both ASB and CLI behaviour that periodically pings a connected party to ensure that the underlying network connection is still alive.
This fixes problems with long-running connections that become dead without a connection closure being reported back to the swarm.
This will allow us to compile on stable Rust.
The latest version of `secp256kfun` uses `curve25519-dalek-ng` instead
of the original curve25519-dalek crate. Instead of converting back and
forth, we simply switch to this crate as well. Judging from the README
it is just a fork because there was trouble between the maintainers of
the original crate.
It appears to be more stable.
Encountered issues with the previous setup, `monero-wallet-rpc` logs:
```
2021-05-24 04:23:54.852 E !r. THROW EXCEPTION: tools::error::no_connection_to_daemon
2021-05-24 04:23:54.857 E Exception at while refreshing, what=no connection to daemon
```
525: Bitcoin transaction published state r=da-kami a=da-kami
This improves the error handling on the ASB.
Once the Bitcoin redeem transaction is seen in mempool, the state machine cannot transition to a cancel scenario anymore because at that point the CLI will have redeemed the Monero.
The additional state then waits for transaction finality and prevents re-publishing the transaction.
Co-authored-by: Daniel Karzel <daniel@comit.network>
This improves the error handling on the ASB.
Once the Bitcoin redeem transaction is seen in mempool, the state machine cannot transition to a cancel scenario anymore because at that point the CLI will have redeemed the Monero.
The additional state then waits for transaction finality.
520: Cli json logging r=da-kami a=da-kami
Combining `--json` with the debug file logger was a pita, so I stopped and went for a simpler approach:
If `--json` is given we just log to terminal - **no** logfiles will be created in `{data-dir}/logs`.
The `--debug` flag applies to `--json` (i.e. if not given it will just print json on info level). We could change that to automatically fallback to debug - could add a `required_if` dependency via strucopt/clap but I did not want to invest more time into thinking about this.
Note on extending binary functionality:
As discussed with @thomaseizinger recently, we will have to think about multiple binaries soon, i.e. a binary that focuses to be used to building on top of it (that always logs json) and potientially keeping a simple CLI that is more user friendly. This also goes towards more clearly separating the application code from re-usable protocol / network code.
Co-authored-by: Daniel Karzel <daniel@comit.network>
519: Avoid application error upon `--help` r=da-kami a=da-kami
Our `preview` release is currently broken because of this issue.
The way we use clap's `get_matches_from_safe` caused parsing errors upon `--help` and `--version` to be bubbled up to the application - which causes the application to exit with an error when running `--help` and `--version`.
This is solved by using `get_matches_from` instead of `get_matches_from_safe` which handles these known clap commands internally and exits early.
Added smoke tests to CI so we catch such kind of problems in the future. Smoke testing by calling `--help` is cheap and should be OK in CI.
Co-authored-by: Daniel Karzel <daniel@comit.network>
Since we introduced our own parsing function for command line arguments, we have to make sure that clap's behaviour is handled correctly.
Clap's `get_matches_from_safe` returns an error of a certain kind, of which `ErrorKind::HelpDisplayed` and `ErrorKind::VersionDisplayed ` have to be handled to properly print the help/version and exit the program.
The clap error includes the message, so we print help/version in main now and ensure the program exits with `0` afterwards.
490: Mainnet switch r=da-kami a=da-kami
Fixes #446Fixes#360Fixes#506Fixes#478
To be precise: It is actually a testnet switch, because I think mainnet should be default.
I took several assumptions on the way (e.g. network support, ...).
At this stage any feedback welcome :)
TODO:
- [ ] successful mainnet swap with this code base before merging :)
Co-authored-by: Daniel Karzel <daniel@comit.network>
It is currently not expected that ASB and CLI are used for swaps > 10_000$ equivalent to XMR/BTC, thus the finality confirmations were reduced to an equivalent of 20 mins of work (2 blocks for Bitcoin, 10 for Monero).
Monero enforces 10 unlocking blocks until the balance is spendable, so the finality confirmations cannot be set lower than 10.
We subscribe to transactions upon broadcast, where we use output index `0` for the subscription.
In order to ensure that this subscription is guaranteed to be for the locking script (and not a change output) we now ensure that the locking script output is always at index `0` of the outputs of the transaction.
We chose this solution because otherwise we would have to add more information to broadcasting a transaction.
This solution is less intrusive, because the order of transaction outputs should not have any side effects and ensuring index `0` makes the whole behaviour more deterministic.
The Electrum block-header subscription did not provide us with block headers, because upon the connection being closed by a node the subscription would end.
Re-newing the the subscription upon re-connect is not easily achievable, that's why we opted for a polling mode for now, where we start a block header subscription on every update iteration, that is only used once (when the subscription is made).
There is no `--mainnet` flag.
Since we cannot just pass an empty string to `.arg()` we use the `.args()` method to pass nothing for mainnet and the respective flags for stagenet and testnet.
By default the finality confirmations of the network's `env::Config` will be applied and no finality confirmations will be persisted on disk in the config file.
It is however possible to set finality confirmations in the config file for bitcoin and monero for power users at their own risk.
If set the defaults will be overwritten with the parameter from the config file upon startup.
To run the ASB on testnet, one actively has to provide the `--testnet` flag.
Mainnet and testnet data and config are separated into sub-folders, i.e. `{data/config-dir}/asb/testnet` and `{data-dir}/asb/mainnet`.
The initial setup is also per network. If (default) config for the network cannot be found the initial setup is triggered.
Startup includes network check to ensure the bitcoin/monero network in config file is the same as the one in the `env::Config`.
Note: Wallet initialization is done with the network set in the `env::Config`, the network saved in the config file is just to indicate what network the config file is for.
This includes testing CLI commandline args
Clap's `default_value_with` actually did not work on `Subcommand`s because the parent's flags were not picked up.
This was fixed by changing parameters dependent on testnet/mainnet to options.
This problem should have been detected by tests, that's why the command line parameter tests were finally (re-)added.
Thanks to @rishflab for some pre-work for this.
In order to allow people to plug into public nodes / be more flexible with their own setup we now enforce specifying the monero daemon port to be used by the `monero-wallet-rpc`.
In the past we had problems with flags/parameter changes several times, where on instance was changed, buy another one was missed. This should mitigate this problem.
This patch introduces structs for all duplicated parameters and uses flatten to only have one point for changes.
Additionally removes all mentions of `alice` from the commands / variables. This code is on an application level and should not be concerned with swap protocol roles.
We need to check two things:
- balance to be higher than dust amount (546).
- balance to be higher than min-relay fee.
Additionally, the tx_builder might fail if not enough funds are in the wallet to pay for the overall transaction fees.
Introduces a minimum buy Bitcoin amount similar to the maximum amount already present.
For the CLI the minimum amount is enforced by waiting until at least the minimum is available as max-giveable amount.
Max-buy and spread is not something that one would configure on every run.
More convenient to keep this in the config.
The max-buy Bitcoin value was adapted to `0.02` which is more reasonable for mainnet.
Activated feature `serde-float` to serialize the spread (Decimal) as float instead of string.
```
...
[maker]
max_buy_btc = 0.02
ask_spread = 0.02
```
Weights fluctuate because of the length of the signatures. Valid ecdsa signatures can have 68, 69, 70, 71, or 72 bytes. Since most of our transactions have 2 signatures the weight can be up to 8 bytes less than the static weight (4 bytes per signature).
Adds `cancel`, `refund`, `punish`, `redeem` and `safely-abort` commands to the ASB that can be used to trigger the specific scenario for the swap by ID.
`asb --help` :
(...)
SUBCOMMANDS:
balance Prints the Bitcoin and Monero balance. Requires the monero-wallet-rpc to be running.
help Prints this message or the help of the given subcommand(s)
history Prints swap-id and the state of each swap ever made.
start Main command to run the ASB.
withdraw-btc Allows withdrawing BTC from the internal Bitcoin wallet.
In the production code it is a weird indirection that we load the state and then pass in the state and the database.
In the tests we have one additional load by doing it inside the command, but loading from the db is not expensive.
Each test spawns swarm for Alice and Bob that only contains the spot_price behaviours and uses a memory transport.
Tests cover happy path (i.e. expected price is returned) and error scenarios.
Implementation of `TestRate` on `LatestRate` allows testing rate fetch error and quote calculation error behaviour.
Thanks to @thomaseizinger for ramping up the test framework for comit-rs in the past!
Instead of handling all errors on the inside spot_price errors are bubbled up (as `SwapRequestDeclined`).
This allows us to test both Alice's and Bob's behaviour for all scenarios.
What goes over the wire should not be coupled to the errors being printed.
For the CLI and ASB we introduce a separate error enum that is used for logging.
When sending over the wire the errors are mapped to and from the `network::spot_price::Error`.
As part of Bob-specific spot_price code was moved from the network into bob.
Clearly separation of the network API from bob/alice.
Move Alice's spot price logic into a dedicated network behaviour that handles all the logic.
The new behaviour encapsulates the complete state necessary for spot price request decision making.
The network behaviour cannot handle asynchronous calls, thus the balance is managed inside the spot price and has to updated regularly from the outside to ensure the spot price balance check has up to date data.
At the moment the balance is updated upon an incoming quote requests.
Code that is relevant for both ASB and CLI remains in the `network::spot_price` module (e.g. `network::spot_price::Error`).
When a CLI requests a spot price have some errors that are expected, where we can provide a proper error message for the CLI:
- Balance of ASB too low
- Buy amount sent by CLI exceeds maximum buy amount accepted by ASB
- ASB is running in maintenance mode and does not accept incoming swap requests
All of these errors returns a proper error to the CLI and prints a warning in the ASB logs.
Any other unexpected error will result in closing the channel with the CLI and printing an error in the ASB logs.
Resume-only is a maintenance mode where no swaps are accepted but unfinished swaps are resumed.
This is achieve by ignoring incoming spot-price requests (that would lead to execution setup) in the event-loop.
Fees are hard to compute and it is too easy to get wrong and lose a lot of money. Hence, a hardcoded maximum of 100,000 satoshi for a single transaction is in place.
Electrum has an estimate-fee feature which takes as input the block you want a tx to be included.
The result is a recommendation of BTC/vbyte.
Using this recommendation and the knowledge about the size of our transactions we compute an appropriate fee.
The size of the transactions were taken from real transactions as published on bitcoin testnet.
Note: in reality these sizes might fluctuate a bit but not for much.
Alice chooses the fee for TxPunish because she is the one that cares.
Bob chooses the fee for TxRefund because he is the one that cares.
Note must be taken here because if the fee is too low (e.g. < min tx fee) then she might not be able to publish TxRedeem at all.
Alice chooses the fee for TxRedeem because she is the one that cares. Note must be taken here because if the fee is too low (e.g. < min tx fee) then she might not be able to publish TxRedeem at all.
434: Introduce monero-wallet crate r=thomaseizinger a=thomaseizinger
This PR:
1. ~Introduce a crate for the epee binary serialization as a serde format~: Released here: https://github.com/comit-network/monero-epee-bin-serde
2. Extends the MoneroRPC client with two binary calls
3. Introduces a `monero-wallet` crate that for now just provides functionality for choosing random key offsets. Together with the the ability to produce bulletproofs and ring signatures, this should be enough for signing Monero transactions locally.
(1) and (2) are a prerequisite for (3).
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
460: Different default directories for CLI and ASB r=da-kami a=da-kami
Fixes#437
Using the same default directory as data-/config-dir has caused unwanted side effects when running both applications on the same machine.
Use these directory names:
- ASB: `xmr-btc-swap-asb`
- CLI: `xmr-btc-swap-cli`
Since the functionality is now application specific the respective functions were moved into the appropriate module of the application.
Co-authored-by: Daniel Karzel <daniel@comit.network>
459: Use dprint for formatting Cargo.toml files r=thomaseizinger a=thomaseizinger
Invoking cargo tomlfmt on all files is a PITA and as we can see from
the CI scripts, it is often forgotten to as new crates are added to
the workspace.
Using dprint for toml files fixes this.
Unfortunately, we can't use dprint for Rust code yet because there
hasn't been a release of rustfmt in quite a while but we are already
using features from a newer rustfmt via rustup.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Using the same default directory as data-/config-dir has caused unwanted side effects when running both applications on the same machine.
Use these directory names:
- ASB: xmr-btc-swap/asb
- CLI: xmr-btc-swap/cli
Since the functionality is now application specific the respective functions were moved into the appropriate module of the application.
Using the same default directory as data-/config-dir has caused unwanted side effects when running both applications on the same machine.
Use these directory names:
- ASB: xmr-btc-swap-asb
- CLI: xmr-btc-swap-cli
Since the functionality is now application specific the respective functions were moved into the appropriate module of the application.
Bob validates that incoming transfer proof messages are coming from the peer-id of Alice.
Currently Bob will ignore any transfer proof message that is not coming from the counterparty peer-id associated to the current swap in execution.
Once we add support for trying to save received transfer proofs for swaps that are currently not in execution we can also adapy allowing this for different counterparty peer-ids. This requires access to the database in Bob's event loop.
Alice validates that incoming encsig messages are coming from the peer-id that is associated with the swap.
Encsig message from a peer-id different to the one associated with the swap are ignored.
Invoking cargo tomlfmt on all files is a PITA and as we can see from
the CI scripts, it is often forgotten to as new crates are added to
the workspace.
Using dprint for toml files fixes this.
Unfortunately, we can't use dprint for Rust code yet because there
hasn't been a release of rustfmt in quite a while but we are already
using features from a newer rustfmt via rustup.
This PR does a few things.
* It adds a TorTransport which either dials through Tor's socks5 proxy or via clearnet.
* It enables ASB to register hidden services for each network it is listening on. We assume that we only care about different ports and re-use the same onion-address for all of them. The ASB requires to have access to Tor's control port.
* It adds support to dial through a local Tor socks5 proxy. We assume that Tor is always available on localhost. Swap cli only requires Tor to be running so that it can send messages via Tor's socks5 proxy.
* It adds a new e2e test which swaps through Tor. For this we assume that Tor is currently running on localhost. All other tests are running via clear net.
442: Minor cleanups towards implementing a Monero wallet for local signing r=thomaseizinger a=thomaseizinger
Extracted out of #434.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
1. Split up image::Monero into Monerod and MoneroWalletRpc
2. Don't use `bash` to run the internal command. Instead we disable
the entrypoint script as per https://github.com/XMRto/monero#raw-commands
3. Remove the start up delay by listening for the correct log message.
To make this more resilient, we make the log level NOT configurable and
instead always log verbosely.
A `RequestResponseCodec` for pull-based protocols where the response is encoded using JSON.
This was added to more properly express the behavior of the quote protocol, where the dialer
doesn't send any message and expects the listener to directly send the response.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
- Listen on both tcp and websockets as default
- Listening addresses in config as array
- Configure fallback transport using `or_transport` - if listening on a given address fails on WS, we fall back to TCP.
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.
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
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>
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>
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.
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.
389: Bump bdk-testutils from 0.3.0 to 0.4.0 r=thomaseizinger a=dependabot[bot]
Bumps [bdk-testutils](https://github.com/bitcoindevkit/bdk) from 0.3.0 to 0.4.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/bitcoindevkit/bdk/releases">bdk-testutils's releases</a>.</em></p>
<blockquote>
<h2>v0.4.0</h2>
<p>The v0.4.0 release brings updated dependencies, more sanity checks and an overhauled API to build transactions.</p>
<p>You can find the full v0.4.0 changelog on GitHub.</p>
<p>As always, thanks to everybody who contributed to this release!</p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/bitcoindevkit/bdk/blob/master/CHANGELOG.md">bdk-testutils's changelog</a>.</em></p>
<blockquote>
<h2>[v0.5.0] - [v0.4.0]</h2>
<h3>Misc</h3>
<h4>Changed</h4>
<ul>
<li>Updated <code>electrum-client</code> to version <code>0.7</code></li>
</ul>
<h3>Wallet</h3>
<h4>Changed</h4>
<ul>
<li><code>FeeRate</code> constructors <code>from_sat_per_vb</code> and <code>default_min_relay_fee</code> are now <code>const</code> functions</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="e3f893dbd1"><code>e3f893d</code></a> Bump version to 0.4.0</li>
<li><a href="3f5513a2d6"><code>3f5513a</code></a> Update 'bdk-macros', 'bdk-testutils', 'bdk-testutils-macros' dep versions</li>
<li><a href="fcf5e971a6"><code>fcf5e97</code></a> Bump 'bdk-macros' version to 0.3.0</li>
<li><a href="cdf7b33104"><code>cdf7b33</code></a> Bump 'bdk-testutils' version to 0.3.0</li>
<li><a href="7bbff79d4b"><code>7bbff79</code></a> Bump 'bdk-testutils-macros' version to 0.3.0</li>
<li><a href="3a2b8bdb85"><code>3a2b8bd</code></a> Small CHANGELOG cleanup</li>
<li><a href="7843732e17"><code>7843732</code></a> [descriptor] Perform additional checks before using a descriptor</li>
<li><a href="6092c6e789"><code>6092c6e</code></a> Don't fix tokio minor version</li>
<li><a href="b61427c07b"><code>b61427c</code></a> [policy] Allow specifying a policy path for <code>Multisig</code></li>
<li><a href="fa2610538f"><code>fa26105</code></a> [policy] Remove the <code>TooManyItemsSelected</code> error</li>
<li>Additional commits viewable in <a href="https://github.com/bitcoindevkit/bdk/compare/v0.3.0...v0.4.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>
In order for the re-construction of TxLock to be meaningful, we limit
`Message2` to the PSBT instead of the full struct. This is a breaking
change in the network layer.
The PSBT is valid if:
- It has at most two outputs (we allow a change output)
- One of the outputs pays the agreed upon amount to a shared output script
Resolves#260.
This allows us to construct instances of bitcoin::Wallet for test
purposes that use a different blockchain and database implementation.
We also parameterize the electrum-client to make it possible to
construct a bitcoin::Wallet for tests that doesn't have one. This
is necessary because the client validates the connection as it is
constructed and we don't want to provide an Electrum backend for
unit tests.
This allows us to remove all visibility modifiers from the message
fields because child modules (in this case {alice,bob}::state) can
always access private fields of structs.
It also moves the messages into a more natural place. Previously,
they were defined within the network layer even though they are
independent of the libp2p implementation.
To achieve this, we need to add some pure helpers to the state structs.
This has the added benefit that we can reduce the amount of code within
the swap function.
If TxLock does not confirm in a reasonable amount of time, Alice should
give up on the swap rather than waiting forever. Watching for TxLock in
the mempool is not required and it causes unnecessary complexity. What
if Alice does not see the transaction in mempool but it is already
confirmed? She will abort the swap for no reason.
Instead of watching for status changes directly on bitcoin::Wallet,
we return a Subscription object back to the caller. This subscription
object can be re-used multiple times.
Among other things, this now allows callers of `broadcast` to decide
on what to wait for given the returned Subscription object.
The new API is also more concise which allows us to remove some of
the functions on the actor states in favor of simple inline calls.
Co-authored-by: rishflab <rishflab@hotmail.com>
Sometimes, a single sync is not enough because we are still waiting
for the block to be mined.
We introduce an abstraction that loops on fetching the latest balance
with a certain timeout for asserting the balance.
By using `test_writer`, cargo can automatically scope the output
of the test to the relevant thread and will also only output it
if the test fails or is run with `--nocapture`.
This also formats `log` events more nicely. Instead of
```
Mar 29 09:46:16.775 INFO log: Found message after comparing 82 lines log.target="testcontainers::core::wait_for_message" log.module_path="testcontainers::core::wait_for_message" log.file="/home/thomas/.cargo/registry/src/github.com-1ecc6299db9ec823/testcontainers-0.12.0/src/core/wait_for_message.rs" log.line=35
```
We now have
```
Mar 29 09:57:15.860 INFO testcontainers::core::wait_for_message: Found message after comparing 81 lines
```
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.
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>
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.
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.
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.
Instead of calling this function in all the branches, we can simply
make the whole match statement evaluate to the new state and perform
this functionality at the very end.
This allows us to move critical crypto logic onto `State3` which
holds all the necessary data which consequently allows us to get
rid of `lock_xmr` altogether by inlining it into the swap function.
The reduced indirection improves readability.
