338: Timeout improvements r=rishflab a=rishflab
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 no longer required and 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.
Co-authored-by: rishflab <rishflab@hotmail.com>
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.
361: Introduce a more flexible transaction subscription system r=rishflab a=thomaseizinger
TODO:
- [x] Make sure we unsubscribe once all receivers are gone. How do we handle repeated subscriptions?
Will squash the last 4 or 5 commits once approved
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
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
```
366: Asb docs r=da-kami a=da-kami
Note:
There is currently quite a lot ongoing to make the ASB better, so the documentation will naturally get outdated.
Knowing that, I opted for linking to ongoing issues that will improve ASB setup / execution so that users can refer to them to see the progress.
We need documentation to make ASB setup / exec understandable. Let's see to get this in so we have something to iterate on :)
Co-authored-by: Daniel Karzel <daniel@comit.network>
- Component diagram showcasing both ASB and CLI using public blockchain nodes
- Component diagram showcasing ASB using self hosted blockchain nodes and CLI public
379: Use language agnostic heuristic to check if monero_wallet_rpc is ready r=rishflab a=rishflab
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.
NOTE: will squash after approved
Co-authored-by: rishflab <rishflab@hotmail.com>
Our strategy of searching for a english string to determine if
monero_wallet_rpc is ready is not compatible with languages other than
english. Instead we assume the monero rpc is ready if it has stopped
writing to stdout. We make a json rpc request to confirm this. A better
solution would have been to configure the monero_wallet_rpc to always
output in english but there is not command line argument to configure
the language.
Closes#353.
Whenever a release branch - that is a branch starting with `release/` -
is merged into master, we create a new GitHub release based on the
version number in the branch name.
Similarly to the preview release, we extract the relevant section of
the changelog and make it the release body.
Drafting a new release can be quite involved. One has to update the
changelog correctly, bump the versions in the manifest files, commit
everything and raise a PR.
This workflow does all of that for you at the click of a button!
359: Bump bdk from 0.4.0 to 0.5.0 r=thomaseizinger a=dependabot[bot]
Bumps [bdk](https://github.com/bitcoindevkit/bdk) from 0.4.0 to 0.5.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/bitcoindevkit/bdk/blob/master/CHANGELOG.md">bdk's changelog</a>.</em></p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="f7944e871b"><code>f7944e8</code></a> Bump version to 0.5.0</li>
<li><a href="2fea1761c1"><code>2fea176</code></a> Bump deps version</li>
<li><a href="fa27ae210f"><code>fa27ae2</code></a> Update version in lib.rs</li>
<li><a href="46fa41470e"><code>46fa414</code></a> Update CHANGELOG with the new release tag</li>
<li><a href="8ebe7f0ea5"><code>8ebe7f0</code></a> Merge commit 'refs/pull/308/head' of github.com:bitcoindevkit/bdk into releas...</li>
<li><a href="eb85390846"><code>eb85390</code></a> Merge commit 'refs/pull/309/head' of github.com:bitcoindevkit/bdk into releas...</li>
<li><a href="dc83db273a"><code>dc83db2</code></a> better derivation path building</li>
<li><a href="201bd6ee02"><code>201bd6e</code></a> better derivation path building</li>
<li><a href="396ffb42f9"><code>396ffb4</code></a> handle descriptor xkey origin</li>
<li><a href="9cf62ce874"><code>9cf62ce</code></a> [ci] Manually install libclang-common-10-dev to 'check-wasm' job</li>
<li>Additional commits viewable in <a href="https://github.com/bitcoindevkit/bdk/compare/v0.4.0...v0.5.0">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
370: No Bitcoin deposit for Alice r=da-kami a=da-kami
The message to deposit Bitcoin only applies to Bob, not Alice.
Alice does not require any initial Bitcoin.
Co-authored-by: Daniel Karzel <daniel@comit.network>
340: Remove connection handling from swap execution and cleanup network protocol implementations r=thomaseizinger a=thomaseizinger
TODO:
- [x] Re-establish connection on Bob's side if it is dropped.
- [x] Make sure Alice buffers messages if there isn't currently a connection
- [x] Do a testnet swap to make sure it works
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
The request-response behaviour that is used for sending the transfer
proof actually has a functionality for buffering a message if we
are currently not connected. However, the request-response behaviour
also emits a dial attempt and **drops** all buffered messages if this
dial attempt fails. For us, the dial attempt will very likely always
fail because Bob is very likely behind NAT and we have to wait for
him to reconnect to us.
To mitigate this, we build our own buffer within the EventLoop and
send transfer proofs as soon as we are connected again.
Resolves#348.
The swap should not be concerned with connection handling. This is
the responsibility of the overall application.
All but the execution-setup NetworkBehaviour are `request-response`
behaviours. These have built-in functionality to automatically emit
a dial attempt in case we are not connected at the time we want to
send a message. We remove all of the manual dialling code from the
swap in favor of this behaviour.
Additionally, we make sure to establish a connection as soon as the
EventLoop gets started. In case we ever loose the connection to Alice,
we try to re-establish it.
