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.
327: Bump actions/setup-python from v1 to v2.2.1 r=thomaseizinger a=dependabot[bot]
Bumps [actions/setup-python](https://github.com/actions/setup-python) from v1 to v2.2.1.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/actions/setup-python/releases">actions/setup-python's releases</a>.</em></p>
<blockquote>
<h2>v2.2.1</h2>
<ul>
<li>Fix PyPy3 issues with Windows</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="3105fb18c0"><code>3105fb1</code></a> fix is_windows (<a href="https://github.com/actions/setup-python/issues/172">#172</a>)</li>
<li><a href="8c5ea631b2"><code>8c5ea63</code></a> Adding support for more PyPy versions and installing them on-flight (<a href="https://github.com/actions/setup-python/issues/168">#168</a>)</li>
<li><a href="2831efe49a"><code>2831efe</code></a> Improve find-python to add "Scripts" folder to PATH on Windows machines (<a href="https://github.com/actions/setup-python/issues/169">#169</a>)</li>
<li><a href="3b3f2de1b1"><code>3b3f2de</code></a> update pypy3 to point to 3.6 (<a href="https://github.com/actions/setup-python/issues/164">#164</a>)</li>
<li><a href="723e46dad7"><code>723e46d</code></a> CODEOWNERS needs the org name for teams</li>
<li><a href="195f5c388b"><code>195f5c3</code></a> Create CODEOWNERS</li>
<li><a href="41b7212b16"><code>41b7212</code></a> Update README.md (<a href="https://github.com/actions/setup-python/issues/145">#145</a>)</li>
<li><a href="878156f1de"><code>878156f</code></a> Inject LD_LIBRARY_PATH library path into Python manifest install and setup (#...</li>
<li><a href="c181ffa198"><code>c181ffa</code></a> Add Environment Files (<a href="https://github.com/actions/setup-python/issues/138">#138</a>)</li>
<li><a href="1ce870e10f"><code>1ce870e</code></a> Fix links in documentation (<a href="https://github.com/actions/setup-python/issues/135">#135</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/actions/setup-python/compare/v1...3105fb18c05ddd93efea5f9e0bef7a03a6e9e7df">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>
330: Bump dialoguer from 0.7.1 to 0.8.0 r=thomaseizinger a=dependabot[bot]
Bumps [dialoguer](https://github.com/mitsuhiko/dialoguer) from 0.7.1 to 0.8.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/mitsuhiko/dialoguer/blob/master/CHANGELOG.md">dialoguer's changelog</a>.</em></p>
<blockquote>
<h2>0.8.0</h2>
<h3>Enhancements</h3>
<ul>
<li><code>Input::validate_with</code> can take a <code>FnMut</code> (allowing multiple references)</li>
</ul>
<h3>Breaking</h3>
<ul>
<li><code>Input::interact*</code> methods take <code>&mut self</code> instead of <code>&self</code></li>
</ul>
<h2>0.7.0</h2>
<h3>Enhancements</h3>
<ul>
<li>Added <code>wait_for_newline</code> to <code>Confirm</code></li>
<li>More secure password prompt</li>
<li>More documentation</li>
<li>Added <code>interact_text</code> method for input prompt</li>
<li>Added <code>inline_selections</code> to <code>ColorfulTheme</code></li>
</ul>
<h3>Breaking</h3>
<ul>
<li>Removed <code>theme::CustomPromptCharacterTheme</code></li>
<li><code>Input</code> validators now take the input type <code>T</code> as arg</li>
<li><code>Confirm</code> has no <code>default</code> value by default now</li>
</ul>
<h2>0.6.2</h2>
<h3>Enhancements</h3>
<ul>
<li>Updating some docs</li>
</ul>
<h2>0.6.1</h2>
<h3>Bugfixes</h3>
<ul>
<li><code>theme::ColorfulTheme</code> default styles are for stderr</li>
</ul>
<h2>0.6.0</h2>
<h3>Breaking</h3>
<ul>
<li>Removed <code>theme::SelectionStyle</code> enum</li>
<li>Allowed more customization for <code>theme::Theme</code> trait by changing methods</li>
<li>Allowed more customization for <code>theme::ColorfulTheme</code> by changing members</li>
<li>Renamed prompt <code>Confirmation</code> to <code>Confirm</code></li>
<li>Renamed prompt <code>PasswordInput</code> to <code>Password</code></li>
<li>Renamed prompt <code>OrderList</code> to <code>Sort</code></li>
<li>Renamed prompt <code>Checkboxes</code> to <code>MultiSelect</code></li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="2c3fe6b646"><code>2c3fe6b</code></a> Release 0.8.0</li>
<li><a href="64f5f9c6f5"><code>64f5f9c</code></a> Allow confirm with no choice (<a href="https://github.com/mitsuhiko/dialoguer/issues/101">#101</a>)</li>
<li><a href="0250090f95"><code>0250090</code></a> Update some docs in confirm prompt</li>
<li><a href="a76fb72c54"><code>a76fb72</code></a> Merge pull request <a href="https://github.com/mitsuhiko/dialoguer/issues/102">#102</a> from spenserblack/typo-fix</li>
<li><a href="3dd93bb75a"><code>3dd93bb</code></a> Fix typo: ereased -> erased</li>
<li><a href="7ea6275caa"><code>7ea6275</code></a> Update CI for i686 ubuntu</li>
<li><a href="af664807da"><code>af66480</code></a> Allow FnMut for validate (<a href="https://github.com/mitsuhiko/dialoguer/issues/96">#96</a>)</li>
<li><a href="2b5722d0f5"><code>2b5722d</code></a> Update README.md</li>
<li><a href="2df3a705eb"><code>2df3a70</code></a> Update ci.yml</li>
<li><a href="8cebf522b3"><code>8cebf52</code></a> Merge pull request <a href="https://github.com/mitsuhiko/dialoguer/issues/94">#94</a> from mitsuhiko/remove-travis</li>
<li>Additional commits viewable in <a href="https://github.com/mitsuhiko/dialoguer/compare/0.7.1...0.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)
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>
331: Bump tokio from 1.0.2 to 1.3.0 r=thomaseizinger a=dependabot[bot]
Bumps [tokio](https://github.com/tokio-rs/tokio) from 1.0.2 to 1.3.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/tokio-rs/tokio/releases">tokio's releases</a>.</em></p>
<blockquote>
<h2>Tokio v1.3.0</h2>
<h3>Added</h3>
<ul>
<li>coop: expose an <code>unconstrained()</code> opt-out (<a href="https://github.com/tokio-rs/tokio/issues/3547">#3547</a>)</li>
<li>net: add <code>into_std</code> for net types without it (<a href="https://github.com/tokio-rs/tokio/issues/3509">#3509</a>)</li>
<li>sync: add <code>same_channel</code> method to <code>mpsc::Sender</code> (<a href="https://github.com/tokio-rs/tokio/issues/3532">#3532</a>)</li>
<li>sync: add <code>{try_,}acquire_many_owned</code> to <code>Semaphore</code> (<a href="https://github.com/tokio-rs/tokio/issues/3535">#3535</a>)</li>
<li>sync: add back <code>RwLockWriteGuard::map</code> and <code>RwLockWriteGuard::try_map</code> (<a href="https://github.com/tokio-rs/tokio/issues/3348">#3348</a>)</li>
</ul>
<h3>Fixed</h3>
<ul>
<li>sync: allow <code>oneshot::Receiver::close</code> after successful <code>try_recv</code> (<a href="https://github.com/tokio-rs/tokio/issues/3552">#3552</a>)</li>
<li>time: do not panic on <code>timeout(Duration::MAX)</code> (<a href="https://github.com/tokio-rs/tokio/issues/3551">#3551</a>)</li>
</ul>
<h3>Documented</h3>
<ul>
<li>doc: doc aliases for pre-1.0 function names (<a href="https://github.com/tokio-rs/tokio/issues/3523">#3523</a>)</li>
<li>io: fix typos (<a href="https://github.com/tokio-rs/tokio/issues/3541">#3541</a>)</li>
<li>io: note the EOF behaviour of <code>read_until</code> (<a href="https://github.com/tokio-rs/tokio/issues/3536">#3536</a>)</li>
<li>io: update <code>AsyncRead::poll_read</code> doc (<a href="https://github.com/tokio-rs/tokio/issues/3557">#3557</a>)</li>
<li>net: update <code>UdpSocket</code> splitting doc (<a href="https://github.com/tokio-rs/tokio/issues/3517">#3517</a>)</li>
<li>runtime: add link to <code>LocalSet</code> on <code>new_current_thread</code> (<a href="https://github.com/tokio-rs/tokio/issues/3508">#3508</a>)</li>
<li>runtime: update documentation of thread limits (<a href="https://github.com/tokio-rs/tokio/issues/3527">#3527</a>)</li>
<li>sync: do not recommend <code>join_all</code> for <code>Barrier</code> (<a href="https://github.com/tokio-rs/tokio/issues/3514">#3514</a>)</li>
<li>sync: documentation for <code>oneshot</code> (<a href="https://github.com/tokio-rs/tokio/issues/3592">#3592</a>)</li>
<li>sync: rename <code>notify</code> to <code>notify_one</code> (<a href="https://github.com/tokio-rs/tokio/issues/3526">#3526</a>)</li>
<li>time: fix typo in <code>Sleep</code> doc (<a href="https://github.com/tokio-rs/tokio/issues/3515">#3515</a>)</li>
<li>time: sync <code>interval.rs</code> and <code>time/mod.rs</code> docs (<a href="https://github.com/tokio-rs/tokio/issues/3533">#3533</a>)</li>
</ul>
<h2>Tokio v1.2.0</h2>
<h3>Added</h3>
<ul>
<li>signal: make <code>Signal::poll_recv</code> method public (<a href="https://github.com/tokio-rs/tokio/issues/3383">#3383</a>)</li>
</ul>
<h3>Fixed</h3>
<ul>
<li>time: make <code>test-util</code> paused time fully deterministic (<a href="https://github.com/tokio-rs/tokio/issues/3492">#3492</a>)</li>
</ul>
<h3>Documented</h3>
<ul>
<li>sync: link to new broadcast and watch wrappers (<a href="https://github.com/tokio-rs/tokio/issues/3504">#3504</a>)</li>
</ul>
<h2>Tokio v1.1.1</h2>
<p>Forward ports 1.0.3 fix.</p>
<h3>Fixed</h3>
<ul>
<li>io: memory leak during shutdown (<a href="https://github.com/tokio-rs/tokio/issues/3477">#3477</a>).</li>
</ul>
<h2>Tokio v1.1.0</h2>
<h3>Added</h3>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="d0e4dd1d7b"><code>d0e4dd1</code></a> chore: prepare Tokio v1.3.0 (<a href="https://github.com/tokio-rs/tokio/issues/3597">#3597</a>)</li>
<li><a href="872bc09e83"><code>872bc09</code></a> examples: update chat example (<a href="https://github.com/tokio-rs/tokio/issues/3587">#3587</a>)</li>
<li><a href="db1d90453c"><code>db1d904</code></a> util: fuse PollSemaphore (<a href="https://github.com/tokio-rs/tokio/issues/3578">#3578</a>)</li>
<li><a href="05eeea570e"><code>05eeea5</code></a> coop: expose an unconstrained() opt-out (<a href="https://github.com/tokio-rs/tokio/issues/3547">#3547</a>)</li>
<li><a href="f70b9b84f7"><code>f70b9b8</code></a> sync: documenation for oneshot (<a href="https://github.com/tokio-rs/tokio/issues/3592">#3592</a>)</li>
<li><a href="704de8c01b"><code>704de8c</code></a> stream: remove duplicate <code>doc(test(..))</code> & <code>cfg_attr</code> declarations (<a href="https://github.com/tokio-rs/tokio/issues/3571">#3571</a>)</li>
<li><a href="47be928444"><code>47be928</code></a> sync: yield initial value in WatchStream (<a href="https://github.com/tokio-rs/tokio/issues/3576">#3576</a>)</li>
<li><a href="e06b257e09"><code>e06b257</code></a> sync: add same_channel method to mpsc Senders (<a href="https://github.com/tokio-rs/tokio/issues/3532">#3532</a>)</li>
<li><a href="0867a6fc03"><code>0867a6f</code></a> util: add pollable mpsc::Sender (<a href="https://github.com/tokio-rs/tokio/issues/3490">#3490</a>)</li>
<li><a href="0d838bf5ad"><code>0d838bf</code></a> io: fix link to std src in util (<a href="https://github.com/tokio-rs/tokio/issues/3568">#3568</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/tokio-rs/tokio/compare/tokio-1.0.2...tokio-1.3.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>
332: Bump base64 from 0.12.3 to 0.13.0 r=thomaseizinger a=dependabot[bot]
Bumps [base64](https://github.com/marshallpierce/rust-base64) from 0.12.3 to 0.13.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/marshallpierce/rust-base64/blob/master/RELEASE-NOTES.md">base64's changelog</a>.</em></p>
<blockquote>
<h1>0.13.0</h1>
<ul>
<li>Config methods are const</li>
<li>Added <code>EncoderStringWriter</code> to allow encoding directly to a String</li>
<li><code>EncoderWriter</code> now owns its delegate writer rather than keeping a reference to it (though refs still work)
<ul>
<li>As a consequence, it is now possible to extract the delegate writer from an <code>EncoderWriter</code> via <code>finish()</code>, which returns <code>Result<W></code> instead of <code>Result<()></code>. If you were calling <code>finish()</code> explicitly, you will now need to use <code>let _ = foo.finish()</code> instead of just <code>foo.finish()</code> to avoid a warning about the unused value.</li>
</ul>
</li>
<li>When decoding input that has both an invalid length and an invalid symbol as the last byte, <code>InvalidByte</code> will be emitted instead of <code>InvalidLength</code> to make the problem more obvious.</li>
</ul>
<h1>0.12.2</h1>
<ul>
<li>Add <code>BinHex</code> alphabet</li>
</ul>
<h1>0.12.1</h1>
<ul>
<li>Add <code>Bcrypt</code> alphabet</li>
</ul>
<h1>0.12.0</h1>
<ul>
<li>A <code>Read</code> implementation (<code>DecoderReader</code>) to let users transparently decoded data from a b64 input source</li>
<li>IMAP's modified b64 alphabet</li>
<li>Relaxed type restrictions to just <code>AsRef<[ut8]></code> for main <code>encode*</code>/<code>decode*</code> functions</li>
<li>A minor performance improvement in encoding</li>
</ul>
<h1>0.11.0</h1>
<ul>
<li>Minimum rust version 1.34.0</li>
<li><code>no_std</code> is now supported via the two new features <code>alloc</code> and <code>std</code>.</li>
</ul>
<h1>0.10.1</h1>
<ul>
<li>Minimum rust version 1.27.2</li>
<li>Fix bug in streaming encoding (<a href="https://github.com/marshallpierce/rust-base64/pull/90">#90</a>): if the underlying writer didn't write all the bytes given to it, the remaining bytes would not be retried later. See the docs on <code>EncoderWriter::write</code>.</li>
<li>Make it configurable whether or not to return an error when decoding detects excess trailing bits.</li>
</ul>
<h1>0.10.0</h1>
<ul>
<li>Remove line wrapping. Line wrapping was never a great conceptual fit in this library, and other features (streaming encoding, etc) either couldn't support it or could support only special cases of it with a great increase in complexity. Line wrapping has been pulled out into a <a href="https://crates.io/crates/line-wrap">line-wrap</a> crate, so it's still available if you need it.
<ul>
<li><code>Base64Display</code> creation no longer uses a <code>Result</code> because it can't fail, which means its helper methods for common
configs that <code>unwrap()</code> for you are no longer needed</li>
</ul>
</li>
<li>Add a streaming encoder <code>Write</code> impl to transparently base64 as you write.</li>
<li>Remove the remaining <code>unsafe</code> code.</li>
<li>Remove whitespace stripping to simplify <code>no_std</code> support. No out of the box configs use it, and it's trivial to do yourself if needed: <code>filter(|b| !b" \n\t\r\x0b\x0c".contains(b)</code>.</li>
<li>Detect invalid trailing symbols when decoding and return an error rather than silently ignoring them.</li>
</ul>
<h1>0.9.3</h1>
<ul>
<li>Update safemem</li>
</ul>
<h1>0.9.2</h1>
<ul>
<li>Derive <code>Clone</code> for <code>DecodeError</code>.</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="b4fc91325e"><code>b4fc913</code></a> v0.13.0</li>
<li><a href="bba4c5d11e"><code>bba4c5d</code></a> Merge pull request <a href="https://github.com/marshallpierce/rust-base64/issues/145">#145</a> from marshallpierce/mp/cleanup</li>
<li><a href="42967320b3"><code>4296732</code></a> Add docs and other cleanup</li>
<li><a href="6bb3556633"><code>6bb3556</code></a> Merge pull request <a href="https://github.com/marshallpierce/rust-base64/issues/144">#144</a> from untitaker/invalid-bytes-not-length</li>
<li><a href="5b40e0c04e"><code>5b40e0c</code></a> Merge pull request <a href="https://github.com/marshallpierce/rust-base64/issues/142">#142</a> from marshallpierce/mp/string-writer</li>
<li><a href="8b1ae22bab"><code>8b1ae22</code></a> Rename StrWrite to StrConsumer</li>
<li><a href="27ccb6591e"><code>27ccb65</code></a> fix tests</li>
<li><a href="d15cd384e1"><code>d15cd38</code></a> Give better error messages when decoding data with trailing newlines</li>
<li><a href="5a56885c65"><code>5a56885</code></a> Introduce StrWriter to allow ESW to wrap both a String and a &mut String</li>
<li><a href="2dc0296d2a"><code>2dc0296</code></a> Merge pull request <a href="https://github.com/marshallpierce/rust-base64/issues/143">#143</a> from marshallpierce/mp/invalid-length-doc</li>
<li>Additional commits viewable in <a href="https://github.com/marshallpierce/rust-base64/compare/v0.12.3...v0.13.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>
321: Properly handle concurrent messages to and from peers r=thomaseizinger a=thomaseizinger
Previously, we were forwarding incoming messages from peers to all
swaps that were currently running. That is obviously wrong. The new
design scopes an `EventLoopHandle` to a specific PeerId to avoid
this problem.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
322: Refactor `ExecutionParams` and harmonize sync intervals of wallets r=thomaseizinger a=thomaseizinger
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Previously, we were forwarding incoming messages from peers to all
swaps that were currently running. That is obviously wrong. The new
design scopes an `EventLoopHandle` to a specific PeerId to avoid
this problem.
We define the sync interval as 1/10th of the blocktime. For the
special case of our tests, we however check at max once per second.
The tests have a super fast blocktime. As such we shouldn't hammer
the nodes with a request every 100ms.
Bob does not care whether tx lock is confirmed. That is alice's problem.
This wait was introduced to remedy a bug in status_of_script() which was
failing when called on a transaction with no confirmations.
320: Fix env filter for asb r=thomaseizinger a=thomaseizinger
1. The asb didn't log any if the statements within main.rs
2. We were initializing unnecessary filters that don't make any sense
for the asb. warp and http are not used and the harness-es are for
test only.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
317: Fix monero refresh interval r=thomaseizinger a=thomaseizinger
The comparison should be the MAXIMUM of the two values, not the
minimum, otherwise we always refresh at an interval of 1 second.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
A non-interactive terminal is likely something along the lines of
journalctl which captures a timestamp by itself. In theory, it could
also be just a logfile but we rather accept this limitation and keep
the configuration surface simple rather than exposing another config
switch.
1. The asb didn't log any if the statements within main.rs
2. We were initializing unnecessary filters that don't make any sense
for the asb. warp and http are not used and the harness-es are for
test only.
We have a repeated pattern where we construct one of our
Tx{Cancel,Redeem,Punish,Refund,Lock} transactions and wait until
the status of this transaction changes. We can make this more
ergonomic by creating and implementing a `Watchable` trait that
gives access to the TxId and relevant script for this transaction.
This allows us to remove a parameter from the `watch_until_status`
function.
Additionally, there is a 2nd pattern: "Completing" one of these
transaction and waiting until they are confirmed with the configured
number of blocks for finality. We can make this more ergonomic by
returning a future from `broadcast` that callers can await in case
they want to wait for the broadcasted transaction to reach finality.
The execution params don't change throughout the lifetime of the
program. They can be set in the wallet at the very beginning.
This simplifies the interface of the wallet functions.
We achieve our optimizations in three ways:
1. Batching calls instead of making them individually.
To get access to the batch calls, we replace all our
calls to the HTTP interface with RPC calls.
2. Never directly make network calls based on function
calls on the wallet.
Instead, inquiring about the status of a script always
just returns information based on local data. With every
call, we check when we last refreshed the local data and
do so if the data is considered to be too old. This
interval is configurable.
3. Use electrum's notification feature to get updated
with the latest blockheight.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Rishab Sharma <rishflab@hotmail.com>
We reduce indirection by constructing TxPunish directly based off
`State3` and make the type itself more powerful by moving the logic
of completing it with a signature onto it.
Instead of spawning the swap inside the event loop we send the swap back
to the caller to be spawned. This means we no longer need the remote handle
that was only used in the tests.
This now properly logs the swap results in production.
It also gives us more control over Alice's swap in the tests.
This allows us to have access to RedeemTx from within the scope
of the state transition which we are going to need for more
efficient watching of what happens to this TX on the blockchain.
314: Remove CLI config file in favour of parameters r=thomaseizinger a=da-kami
Fixes#282
The CLI has sensible default values for all parameters,
thus a config file is not really an advantage but just
keeps getting in our way, so re remove it.
Trait impls on `Data` needed for structopt, see https://docs.rs/structopt/0.3.21/structopt/#default-values
Co-authored-by: Daniel Karzel <daniel@comit.network>
The CLI has sensible default values for all parameters,
thus a config file is not really an advantage but just
keeps getting in our way, so re remove it.
306: Fix logging and retrying of Monero transaction watching r=thomaseizinger a=thomaseizinger
Hopefully, this should also reduce the load because I am not asking the node every second.
Related: https://github.com/comit-network/xmr-btc-swap/issues/202
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Daniel Karzel <daniel@comit.network>
Instead, we use a regular loop and extract everything into a function
that can be independently tested.
`backoff` would be useful to retry the actual call to the node.
This config setting makes backoff stop retrying if we didn't get an
error within this timeframe.
For us, this results in backoff not actually doing anything.
The connection to kraken is very long-running. It might be active
for hours without failing. However, the default value for
`max_elapsed_time` is set to 15 minutes. As such, once the connection
fails any time after that, backoff doesn't actually retry the operation
but just gives up.
Fixes#303.
In order to be able to re-connect on certain errors, we model
connection errors separately from parsing errors. We also change
the API of the whole module to no longer forward all errors to
the subscribers but instead, only update the subscribers with
either a latest rate or a permanent failure in case we exhausted
all our options to re-connect the websocket.
To model all of this properly, we introduce to sub-modules so that
each submodule can have their own `Error` type.
Resolves#297.
First, we tell the user that we are now waiting for Alice to lock
the monero. Additionally, we tell them once we received the
transfer proof which will lead directly into the
"waiting for confirmations" function.
The type hints are generated from the field names. This has the
unfortunate consequence of the config field becoming file_path which
does not really make sense people working on the codebase.
The bitcoin::Wallet::sync_wallet function doesn't do anything else
other than delegating. As such, we have just as much information
about what went wrong inside this function as we have outside.
By moving the .context call into the function, we can avoid repeating
us on every call-site.
288: Switch to public stagenet node that works r=rishflab a=rishflab
The xmr.to node has been unreliable lately. The exan.tech node seems to
working.
@da-kami is following up with making this configurable. Lets get this in so we can get a release on Friday.
Co-authored-by: rishflab <rishflab@hotmail.com>
Instead of leaking the tokio::sync:⌚:Receiver type in our
return value, we create a newtype that implements the desired
interface. This allows us to get rid of the `RateService` structs
and instead implement `LatestRate` directly on top of this struct.
Given that `LatestRate` is only used within the event_loop module,
we move the definition of this type into there.
271: Bob can verify that the XMR lock tx was published r=da-kami a=da-kami
The Monero `txhash` log was removed. I feel the user should have the possibility to verify that the transaction was actually published so I added the tx-hash to the confirmation output.
We could potentially print the tx-hash when receiving the transfer proof already, but that might not add much value compared to printing it with the confirmations.
Additionally we should allow the user to at least know when the XMR can be expected in the user's wallet, otherwise the swap ends like this:
```
2021-03-04 13:49:19 INFO Monero lock tx received 5 out of 5 confirmations
```
This is just not very informative - yes, the final transaction is an implementation detail, but I don't think we should hide the transactions from the user. By printing the tx-hash for spending from the lock-tx into the user wallet we ensure the user knows that the XMR can now be expected in the user wallet.
---
To add context, here the complete log (with debug enabled) **before** this change:
```
2021-03-04 13:30:46 DEBUG Database and seed will be stored in /Users/dakami/Library/Application Support/xmr-btc-swap
2021-03-04 13:30:46 DEBUG Starting monero-wallet-rpc on port 56145
2021-03-04 13:30:51 DEBUG Requesting quote
2021-03-04 13:30:51 INFO Received quote: 1 XMR = 0.00433500 BTC
2021-03-04 13:30:51 INFO Still got 0.01018746 BTC left in wallet, swapping ...
2021-03-04 13:30:51 INFO Spot price for 0.00500000 BTC is 1.153402537485 XMR
2021-03-04 13:30:52 DEBUG Starting execution setup with 12D3KooWCdMKjesXMJz1SiZ7HgotrxuqhQJbP5sgBm2BwP1cqThi
2021-03-04 13:30:55 INFO Published Bitcoin 3a6690a962191529892318819fb20e7f1ac4625400e64ee734056a9b2a17ad8f transaction as lock
2021-03-04 13:41:13 DEBUG Received Transfer Proof from 12D3KooWCdMKjesXMJz1SiZ7HgotrxuqhQJbP5sgBm2BwP1cqThi
2021-03-04 13:42:11 INFO Monero lock tx received 1 out of 5 confirmations
2021-03-04 13:45:33 INFO Monero lock tx received 2 out of 5 confirmations
2021-03-04 13:47:49 INFO Monero lock tx received 3 out of 5 confirmations
2021-03-04 13:48:56 INFO Monero lock tx received 4 out of 5 confirmations
2021-03-04 13:49:19 INFO Monero lock tx received 5 out of 5 confirmations
2021-03-04 13:49:19 DEBUG Encrypted signature sent
2021-03-04 13:49:19 DEBUG Alice acknowledged encrypted signature
2021-03-04 13:49:19 DEBUG watching for tx: e5569d3f0bcccac95252dffaebe74ead0360c09b76bc762de890aaa0e51afbcf
2021-03-04 13:49:20 DEBUG Received protocol error "missing transaction" from Electrum, retrying...
2021-03-04 13:49:22 DEBUG Received protocol error "missing transaction" from Electrum, retrying...
```
Co-authored-by: Daniel Karzel <daniel@comit.network>
Print tx-hashes for monero transactions to allow Bob to look the transaction up in block explorer.
The story of Bab:
Our famous actor Bob has a brother named Bab.
In school they were often mixed up, because their names were so similar.
Eventually Bab renamed himself into Barbara, but that was even more confusing for now he
carried a female name even though he was not female. Bob wanted to help his brother and told him he
could just go for Bub. But that did not solve anything. Fun fact: Bub is actually married to Alice.
Previously, the user neither knew the price nor the maximum quantity
they could trade. We now request a quote from the user and display
it to them.
Fixes#255.
This reduces the overall amount of LoC that imports take up in our
codebase by almost 100.
It also makes merge-conflicts less likely because there is less
grouping together of imports that may lead to layout changes which
in turn can cause merge conflicts.
265: Replace quote with spot-price protocol r=thomaseizinger a=thomaseizinger
This is essentially functionally equivalent but includes some
cleanups by removing a layer of abstraction: `spot_price::Behaviour`
is now just a type-alias for a request-response behaviour.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
261: Sweep xmr funds from generated temp wallet r=da-kami a=da-kami
Fixes#252
Please review by commit :)
Did a few cleanups before actually doing the feature.
Please note the comment that influenced this solution: https://github.com/comit-network/xmr-btc-swap/issues/252#issuecomment-789387074
Co-authored-by: Daniel Karzel <daniel@comit.network>
This is essentially functionally equivalent but includes some
cleanups by removing a layer of abstraction: `spot_price::Behaviour`
is now just a type-alias for a request-response behaviour.
Container initialization and wallet initialization have to ensure to use the same wallet name.
In order to avoid problems constants are introduced to ensure we use the same wallet name.
Prefixing docker-containers and -networks is a necessity to be able to spin up multiple containers and networks.
However, there is no reason to prefix the wallet names that live inside a container. One cannot add a wallet with
the same name twice, so the prefixing of wallets does not bring any advantage. When re-opening a wallet by name
the wallet name prefix is cumbersome and was thus removed.
The wallet is an instance of a wallet that has a name.
When we use `CreateWalletForOutputThenReloadWallet` we actually unload the wallet.
It would be cleaner to create a new instance that does that swap, but I did not go that far.
Instead of instantiating the `EventLoop` within the builder, we only
pass in the necessary arguments (which is the `EventLoopHandle`) to
the Builder upon `new`.
This is work towards #255 which will require us to perform network
communication (which implies having the `EventLoop`) before starting
a swap.
If our expression directly evaluates to a future, we don't need to
create an async block.
This requires us to have `EventLoopRun::run` consume the instance
instead of just taking a mutable reference (otherwise we run into
lifetime issues). However, that is better anyway because `run` is
an endless loop so you never get to use the handle afterwards
anyway.
Previously we were ignoring if the monero wallet rpc was not found and
unpacked from archive leading to a failure down the line when trying to
run a non-existent executable. Bail when the executable is no found in
the archive.
1. We can generalize the signing interface by passing a PSBT in
instead of the `TxLock` transaction.
2. Knowing the transaction ID of a transaction that we are about
to sign is not very useful. Instead, it is much more useful to know
what failed. Hence we add a `.context` to the call of `sign_and_finalize`.
3. In case the signing succeeds, we will immediately broadcast it
afterwards. The new broadcasting interface will tell us that we broadcasted
the "lock" transaction.
We eliminate unnecessary layers of indirection for broadcasting logic
and force our callers to provide us with the `kind` of transaction
that we are publishing.
Eventually, we can replace this string with some type-system magic
we can derive the name from the actual transaction. For now, we just
require the caller to duplicate this information because it is faster
and good enough TM.
This struct is a wallet. The only thing it can meaningfully broadcast
are transactions. The fact that they have to be signed for that is
implied. You cannot broadcast unsigned transactions.
Abstracting over the individual bits of functionality of the wallet
does have its place, especially if one wants to keep a separation
of an abstract protocol library that other people can use with their
own wallets.
However, at the moment, the traits only cause unnecessary friction.
We can always add such abstraction layers again once we need them.
If the user doesn't pass `--debug`, we only show `INFO` logs but
without time and level to make it clearer that it is meant to be
read by the user.
Without `--debug`, the user sees:
Still got 0.00009235 BTC left in wallet, swapping ...
With `--debug`, they see:
2021-03-01 12:21:07 DEBUG Database and seed will be stored in /home/thomas/.local/share/xmr-btc-swap
2021-03-01 12:21:07 DEBUG Starting monero-wallet-rpc on port 40779
2021-03-01 12:21:11 INFO Still got 0.00009235 BTC left in wallet, swapping ...
2021-03-01 12:21:11 DEBUG Dialing alice at 12D3KooWCdMKjesXMJz1SiZ7HgotrxuqhQJbP5sgBm2BwP1cqThi
2021-03-01 12:21:12 DEBUG Requesting quote for 0.00008795 BTC
Previously, the time was formatted as ISO8601 timestamps which is
barely readable by humans. Activating the `chrono` feature allows
us to format with a different format string. The output now looks
like this:
2021-03-01 11:59:52 DEBUG Database and seed will be stored in /home/thomas/.local/share/xmr-btc-swap
2021-03-01 11:59:52 DEBUG Starting monero-wallet-rpc on port 40673
2021-03-01 11:59:59 DEBUG Still got 0.00009235 BTC left in wallet, swapping ...
2021-03-01 11:59:59 DEBUG Dialing alice at 12D3KooWCdMKjesXMJz1SiZ7HgotrxuqhQJbP5sgBm2BwP1cqThi
2021-03-01 11:59:59 DEBUG Requesting quote for 0.00008795 BTC
There is a double space after the time which is already fixed in
tracing-subscriber but not yet released.
See https://github.com/tokio-rs/tracing/issues/1271.
Log messages are ideally as close to the functionality they are talking about, otherwise we might end up repeating ourselves on several callsites or the log messages gets outdated if the behaviour changes.
These intermediate structs were creating unnecessary noise. The peer id
and multiaddr fields are going to be removed in the future further
reducing the need to have seperate structs for cancel, resume and
refund.
If communication with the other party fails the program should stop and the user should see the respective error.
Communication errors are handled in the event-loop. Upon a communication error the event loop is stopped.
Since the event loop is only stopped upon error the Result returned from the event loop is Infallible.
If one of the two futures, event loop and swap, finishes (success/failure) the other future should be stopped as well.
We use tokio::selec! to stop either future if the other stops.
Failure does not express what the error represents. It is only used for communication
errors for quote requests, receiving the XMR transfer proof and sending the encryption signature.
If the current balance is 0, we wait until the user deposits money
to the given address. After that, we simply swap the full balance.
Not only does this simplify the interface by removing a parameter,
but it also integrates the `deposit` command into the `buy-xmr`
command.
Syncing a wallet that is backed by electrum includes transactions
that are part of the mempool when computing the balance.
As such, waiting for a deposit is a very quick action because it
allows us to build our lock transaction on top of the yet to be
confirmed deposit transactions.
This patch introduces another function to the `bitcoin::Wallet` that
relies on the currently statically encoded fee rate. To make sure
future developers don't forget to adjust both, we extract a function
that "selects" a fee rate and return the constant from there.
Fixes#196.
These traits were only used once within the `TxLock` constructor.
Looking at the rest of the codebase, we don't really seem to follow
any abstractions here where the protocol shouldn't know about the
exact types that is being passed in.
As such, these types are just noise and might as well be removed in
favor of simplicity.
The only reason we need this argument is because we need to access
the output descriptor. We can save that one ahead of time at when
we construct the type.
BDK already has a log line for the sync that we could enable if we
wanted such a log.
Additionally, _we_ are not actually syncing the wallet, bdk is so our
log line was lying. It should have said "calling bdk to sync wallet".
231: Error only on close message when fetching the rate r=thomaseizinger a=da-kami
Ping/Pong messages disturb the rate requests quite frequently resulting in failed swap setup because there is no rate available.
As a result messages Ping, Pong and Binary are now ignored and not reported as error.
Co-authored-by: Daniel Karzel <daniel@comit.network>
If the monero wallet rpc has not already been downloaded we download the monero cli package and extract the wallet rpc. The unneeded files are cleaned up. The monero wallet rpc is started on a random port which is provided to the swap cli.
We added a fork of tokio-tar via a git subtree because we needed a tokio-tar version that was compatible with tokio 1.0. Remove this subtree in favor of a regular cargo dependency when this PR merges: https://github.com/vorot93/tokio-tar/pull/3.
For transitioning to state4 we either go into a redeem or a cancellation scenario.
The function name state4 is misleading, because it is only used for cancellation scenarios.
This TDOO is misleading, because - to our current knowledge - it is impossible for
Bob to retrieve the exact inclusion block-height of the lock transaction (send by Alice).
The wallet RPC is only capable of retrieving the inclusion block height of a transaction
through `get_payments` and `get_bulk_payments` which requires the `payment_id`.
The `payment_id` can be retrieved through `get_transfer_by_txid` which states
"Show information about a transfer to/from this address." - however the address that the
transfer goes to is not part of Bob's wallet yet! Thus, it is impossible for Bob to use
`get_transfer_by_txid` which in turn means Bob is unable to use `get_payments`.
The only possible way for Bob to know the exact inclusion block/height of the lock transaction
would be if Alice sends it over to Bob. But for that Alice would have to extract it she would have
to wait for confirmation - which she currently does not and might never do. Even if she does await
the first confirmation before sending the transfer proof the solution for retrieving the inclusion
block-height is not fleshed out on her side yet.
In order to ensure that we can atomically generate_from_keys and then reload a wallet,
we have to wrap the client of the monero wallet RPC inside a mutex.
When introducing the Mutex I noticed that several inner RPC calls were leaking to the
swap crate monero wallet. As this is a violation of boundaries I introduced the traits
`GetAddress`, `WalletBlockHeight` and `Refresh`.
Note that the monero wallet could potentially know its own public view key and
public spend key. If we refactor the wallet to include this information upon wallet
creation we can also generate addresses using `monero::Address::standard`.
By updating `tracing_log`, we can access the re-export. That we need
to initialize the `tracing_log` adaptor.
The usage of `log::LevelFilter` for the `init_tracing` function was
conceptually incorrect. We should be using a type from the `tracing`
library here.
The automated swap backend (asb) requires Monero funds, because Alice is selling Monero.
We use a hardcoded default wallet named asb-wallet. This wallet is opened upon startup.
If the default wallet does not exist it will be created.
This allows us to use .context instead of .map_err when calling
`latest_rate()`. For the static rate module, we simply fill in
`Infallible` which is actually better suited because it describes
that we are never using this error.
Note that because we are using `watch` channel, only a reference to the
channel value can be returned.
Hence, using custom Error that can be cloned to be able to
pass `Result` through the channel.
209: Upgrade to bdk 0.4 r=thomaseizinger a=thomaseizinger
Effectively, this also means:
- Upgrading to rust-bitcoin 0.26
- Upgrading to miniscript 5
- Upgrading monero to 0.10
- Upgrading curve25519-dalek to 3
- Upgrading bitcoin-harness to rust-bitcoin 0.26 (https://github.com/coblox/bitcoin-harness-rs/pull/21)
- Upgrade `ecdsa_fun` to latest version
- Replace `cross_curve_dleq` with `sigma_fun` (to avoid an upgrade dance on that library)
I refrained from specifying `rev`s in the Cargo.toml because we have a lock-file anyway. This should allow us to update those dependencies easier in the future by just running `cargo update -p <dependency>`.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Once the transaction was included into a block it has one confirmation - before inclusion it has zero.
current-block-height - transaction-block-height = zero; but that means one confirmation.
Hence, the confirmation calculation was adapted to: Current-block-height - (transaction-block-height - 1).
To achieve this we also:
- upgrade rust-bitcoin to 0.26
- upgrade bitcoin-harness to latest version (which also depends bitcoin 0.26)
- upgrade to latest edcsa-fun
- replace cross_curve_dleq proof with sigma_fun (to avoid an upgrade dance over there)
200: Wait for refund if insufficient Monero is locked up r=da-kami a=da-kami
In a scenario where Alice does not lock up sufficient funds Bob should properly transition to refunds. At the moment the CLI just panics.
I noticed this when Alice accidentally had a different amount set than Bob. In the future this should not happen, because Alice provides the amount for Bob. However, in case Alice is malicious Bob should still transition correctly.
Co-authored-by: Daniel Karzel <daniel@comit.network>
206: Remove misplaced wallet sync call r=rishflab a=rishflab
These bdk wallet sync calls must of gotten lost during a rebase. Removed the call in build TxLock and added one when nectar starts up
Co-authored-by: rishflab <rishflab@hotmail.com>
The bitcoind wallet required the user to run a bitcoind node. It was replaced with a bdk wallet which allows the user to connect to an electrum instance hosted remotely. An electrum and bitcoind testcontainer were created to the test the bdk wallet. The electrum container reads the blockdata from the bitcoind testcontainer through a shared volume. bitcoind-harness was removed as bitcoind initialisation code was moved into test_utils. The bdk wallet differs from the bitcoind wallet in that it needs to be manually synced with an electrum node. We synchronise the wallet once upon initialisation to prevent a potentially long running blocking task from interrupting protocol execution. The electrum HTTP API was used to get the latest block height and the transaction block height as this functionality was not present in the bdk wallet API or it required the bdk wallet to be re-synced to get an up to date value.
190: Do not pass Monero amount to the CLI r=D4nte a=D4nte
The CLI user only pass the Bitcoin amount they want to sell.
The CLI then do a quote request to nectar which provides the Monero amount the taker can get.
Co-authored-by: Franck Royer <franck@coblox.tech>
188: Tor cleanup r=da-kami a=da-kami
We never removed Tor install from CI. I don't think it should be necessary given that Tor was removed in code.
Co-authored-by: Daniel Karzel <daniel@comit.network>
To allow the related timelock to be defined with the
transaction that uses it. This will allow the access to the
timelock's struct inner field with defining `From` impl.
Hence, reducing complexity of the codebase. Note that the seed will be
used by both nectar and the cli whereas the config mod will be different
so this changes helps with the next step of having a dedicated config
module for each binary.
The punish test needs re-work due to the fact that Alice runs continuously
Currently focusing on the CLI (Bob), so we can re-introduce this test
once we want to ensure that nectar (Alice) punishes.
The test do not work without acks as we stop the event loop as soon
as a message is considered as "sent" when actually the event loop
and swarm may not have yet sent the message.
The ack allow to avoid this issue as the message was considered "sent"
only once the other party sent a response. However, the ack brings
other issue so a review needs to be done to select the appropriate
solution.
We are aware of issues of timeouts when waiting for acknowledgements.
Also, to properly supports acks in a multiple swap context, we need to
revert to doing event processing on the behaviour so that we can link
leverage the `RequestResponse` libp2p behaviour and link the messages
requests ids to swap ids when receiving an ack or response.
Acks are usefully for specific scenarios where we queue a message on the
behaviour to be sent, save as sent in the DB but crash before the
message is actually sent. With acks we are able to resume the swap,
without ack, the swap will abort (refund).
`alice::swap::run_until` will be called once the execution setup is
done. The steps before are directly handled by the event loop,
hence no channels are needed for said steps: connection established,
swap request/response & execution setup.
The `EventLoop` will use the `Builder` interface to instantiate a
`Swap` upon receiving a `SwapRequest` and successfully doing an
execution setup.
Before this change, the `EventLoop` would have to hold the path to the
db and re-open the db everytime it wants to construct a swap.
With this change, we can open the DB once and then hold a
`Arc<Database>` in the `EventLoop` and pass it to new `Swap`s structs.
This was introduced due to a CI run, where Bob included tx_refund, but Alice had waited until T2 had expired,
and then went for punishing Bob instead of refunding.
Weirdly, Alice's punich transaction did not fail in that scenario.
If dialing Bob fails Alice waits for the acknowledgement of the transfer proof indefinitely.
The timout prevents her execution from hanging.
Added a ToDo to re-visit the ack receivers. They don't add value at the moment and should be removed.
Alice was attempting to create a new event loop using the same listen addr as the old one which was still running. This commit aborts the event loop before creating a new one.
Upgrade bitcoin harness dependency to latest commit
Upgrade backoff to fix failing tests. The previous version of backoff had a broken version of the retry function. Upgraded to a newer comit which fixes this problem.
Upgrade hyper to 0.14 as the 0.13 was bringing in tokio 0.2.24
Upgraded bitcoin harness to version that uses tokio 1.0 and reqwest 0.11
Upgrade reqwest to 0.11. Reqwest 0.11 uses tokio 1.0
Upgrade libp2p to 0.34 in preparation for tokio 1.0 upgrade
As per the proposed changed in the sequence diagram.
The aim is to have a unique terminology per message instead of having
the same name for 2 consequent messages that share the same behaviour.
Note that the aim is to remove the shared `RequestResponse` behaviours.
Rust fmt automatically groups the imports (from top to bottom) as `pub use` `use crate` and `use`.
There is no need to introduce sections which cause annoyance when auto importing using the IDE.
149: Fix Alice redeem scenario r=da-kami a=da-kami
Follow up of #144, partial fix of https://github.com/comit-network/xmr-btc-swap/issues/137
Fix Alice redeem scenario
- Properly check the timelocks before trying to redeem
- Distinguish different failure scenarios and reactions to it.
- if we fail to construct the redeem transaction: wait for cancel.
- if we fail to publish the redeem transaction: wait for cancel but let the user know that restarting the application will result in retrying to publish the tx.
- if we succeed to publish the tx but then fail when waiting for finality, print error to the user (secreat already leaked, the user has to check manually if the tx was included)
Co-authored-by: Daniel Karzel <daniel@comit.network>
- Properly check the timelocks before trying to redeem
- Distinguish different failure scenarios and reactions to it.
- if we fail to construct the redeem transaction: wait for cancel.
- if we fail to publish the redeem transaction: wait for cancel but let the user know that restarting the application will result in retrying to publish the tx.
- if we succeed to publish the tx but then fail when waiting for finality, print error to the user (secreat already leaked, the user has to check manually if the tx was included)
This is not really a factory as a factory design pattern is about
producing several instances.
In the current usage, we are only interested in one swap instance. Once
the swap instance is created, the factory becomes useless. Hence, it is
more of a builder pattern.
Currently this code is actually not reachable, but that is semantically applied by the program's flow (the resume command includes the swap direction).
It is still preferred to have an error message rather than an unreachable statement.
- Introduce Test abstraction instead of tow harnesses, move test specific data into Test
- Change the abstraction from actors to swap, because we are creating swaps, not actors
- rename actor::swap to run, because we are running a swap
145: Make lock-tx id available in redeem/punish state to be able to assert exact fees r=da-kami a=da-kami
We can do exact assertions for Bob's redeem as well, but have to store Bob's tx_lock id in the respective final state. Make tx_lock available in BtcRedeemed and BtcPunished to have better assertions / harmonize test behaviour.
Storing this information is strictly speaking not needed for the production environment. But it is static information that can be seen as additional information that can be handy for a user. We could potentially extract it inside the tests as well (for redeem without restart would be a bit tricky), but I think this solution is more elegant.
Co-authored-by: Daniel Karzel <daniel@comit.network>
Co-authored-by: Franck Royer <franck@coblox.tech>
Co-authored-by: bors[bot] <26634292+bors[bot]@users.noreply.github.com>
144: Test refactor r=da-kami a=da-kami
This PR is pure refactoring, keeping the logic of the tests we had before. No production code is touched besides re-exports in early commits (no logic changes).
In the follow ups improvements will be introduced, that touch the production code as well.
All remaining tasks actioned since Friday:
- [x] `happy_path_bob _restart` (trivial)
- [x] add refund assertions to harnesses (trivial)
- [x] convert all refund scenarios currently being tested (trivial)
- [x] remove dead test init code once all old tests are converted
- [ ] ~~(optional) move alice and bob harness code into separate files~~ -> might action this once re-using test code in production.
Out of scope, follow up:
- [x] https://github.com/comit-network/xmr-btc-swap/pull/145 - We can do exact assertions for Bob's redeem as well, but have to store Bob's `tx_lock` id in the respective final state. Make `tx_lock` available in `BtcRedeemed` and `BtcPunished` to have better assertions / harmonize test behaviour.
- [ ] update the production code to use the `Alice` and `Bob` structs to bundle the params - update tests to use the production struct.
- [ ] Re-use test swap setup in production (i.e. `Alice-/BobHarness::new`) to setup the swap.
- [ ] add additional tests
- [ ] re-try moving the tests from `test` to `src` (if the peer_id was the only problem this should be trivial now - but should be done after the refactor is finished)
- [ ] creating new wallets upon restart
- [ ] aborting the old event loop after restart
Co-authored-by: rishflab <rishflab@hotmail.com>
Co-authored-by: Daniel Karzel <daniel@comit.network>
136: Testnet resume fixes r=da-kami a=da-kami
Add a few log statements on Bob's side to make the user experience better.
Update / remove ToDos.
I set the log level to `Info` in main again, `Debug` heavily clutters the output. In order to make `Debug` more usable we might want to review printing all those `rpc` messages. But this goes beyond the scope of this PR.
Co-authored-by: Daniel Karzel <daniel@comit.network>
This makes the redeem assertion reusable for all tests with a redeem scenario.
Since the factory was not a clean factory before and is now doing even more it was renamed to harness.
If we wait for lock transaction confirmations immediately after sending the transaction without saving this state to the DB this might cause locking the money twice.
An additional state is needed for such a scenario.
