476: Bump dprint/check from v1.3 to v1.4 r=thomaseizinger a=dependabot[bot]
Bumps [dprint/check](https://github.com/dprint/check) from v1.3 to v1.4.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/dprint/check/releases">dprint/check's releases</a>.</em></p>
<blockquote>
<h2>v1.4</h2>
<p>Upgrade to dprint 0.13.1</p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="a3ed4347fe"><code>a3ed434</code></a> fix: Update to dprint 0.13.1</li>
<li>See full diff in <a href="https://github.com/dprint/check/compare/v1.3...a3ed4347fef5b3b2bf68cc38b44885d9df913253">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>
477: Bump sha2 from 0.9.3 to 0.9.4 r=thomaseizinger a=dependabot[bot]
Bumps [sha2](https://github.com/RustCrypto/hashes) from 0.9.3 to 0.9.4.
<details>
<summary>Commits</summary>
<ul>
<li><a href="c1ed4b1cbc"><code>c1ed4b1</code></a> sha2 v0.9.4 (<a href="https://github-redirect.dependabot.com/RustCrypto/hashes/issues/265">#265</a>)</li>
<li><a href="1bf768865d"><code>1bf7688</code></a> sha-1 v0.9.5 (<a href="https://github-redirect.dependabot.com/RustCrypto/hashes/issues/264">#264</a>)</li>
<li><a href="bf761edb53"><code>bf761ed</code></a> sha1+sha2: switch from <code>cpuid-bool</code> to <code>cpufeatures</code> (<a href="https://github-redirect.dependabot.com/RustCrypto/hashes/issues/263">#263</a>)</li>
<li><a href="1e775edda2"><code>1e775ed</code></a> sha2: bump <code>sha2-asm</code> to v0.6.1 release (<a href="https://github-redirect.dependabot.com/RustCrypto/hashes/issues/262">#262</a>)</li>
<li><a href="e8b3abe442"><code>e8b3abe</code></a> feat(sha2): use latest sha2-asm and enable M1 (<a href="https://github-redirect.dependabot.com/RustCrypto/hashes/issues/261">#261</a>)</li>
<li><a href="ee361ed25f"><code>ee361ed</code></a> build(deps): bump libc from 0.2.88 to 0.2.93 (<a href="https://github-redirect.dependabot.com/RustCrypto/hashes/issues/254">#254</a>)</li>
<li><a href="0bf77b52b1"><code>0bf77b5</code></a> build(deps): bump byteorder from 1.4.2 to 1.4.3 (<a href="https://github-redirect.dependabot.com/RustCrypto/hashes/issues/245">#245</a>)</li>
<li><a href="dd9086ad8c"><code>dd9086a</code></a> sha1: add multiplatform tests (<a href="https://github-redirect.dependabot.com/RustCrypto/hashes/issues/252">#252</a>)</li>
<li><a href="1c1182c8b8"><code>1c1182c</code></a> rustfmt (<a href="https://github-redirect.dependabot.com/RustCrypto/hashes/issues/253">#253</a>)</li>
<li><a href="ad19dffcbe"><code>ad19dff</code></a> build(deps): bump libc from 0.2.86 to 0.2.88 (<a href="https://github-redirect.dependabot.com/RustCrypto/hashes/issues/244">#244</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/RustCrypto/hashes/compare/sha2-v0.9.3...sha2-v0.9.4">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>
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.
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.
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.
- 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.
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.
This allows us to completely skip the "Install Rust" step in CI
because the rust-toolchain file completely describes what we need.
The first invocation of cargo will simply install all the required
components.
Additionally, we make all caches dependant on the version of Rust
that we require.
Usually, we can follow the rolling major tag (@v2) of actions.
However the recent release (2.1.4) is not yet included. See
https://github.com/actions/cache/issues/528 for more details.
We do want to depend on 2.1.4 because it contains a fix that allows
us to use the cache action MacOS. v2 also features better compression
and allows for multiple paths to be specified.
Building binaries and building tests results in different artifacts
inside the `target` directory. If we use distinct caches for these
commands, the caches are more useful because less code has to be
re-built.
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.
Created network, storage and protocol modules. Organised
files into the modules where the belong.
xmr_btc crate moved into isolated modulein swap crate.
Remove the xmr_btc module and integrate into swap crate.
Consolidate message related code
Reorganise imports
Remove unused parent Message enum
Remove unused parent State enum
Remove unused dependencies from Cargo.toml
Default is 8MB. As we start both Alice and bob in test, it is fine to
double the stack size but still assume it does not impact the
normal execution of the binary.
Use reusable test init functions for happy path test
Extract tracing setup to reusable function
Move test initialization to seperate functions
Increase stack size in CI
Fix monero max finality time
Force Bob swarm polling to send message 2
Run Bob state to xmr_locked in punish test to force the sending of
message2. Previously Bob state was run until btc_locked. Although
this was the right thing to do, message2 was not being sent as the
swarm was not polled in btc_locked. Alice punish test passes.
Add info logging to executor
Making build times considerably faster.
On my machine, after running `cargo clean`, `cargo build -p swap`
takes 2min 19s.
The updated dependency also comes with a critical fix to the `Scalar`
type, which originally wrongly assumed that secp256k1 and ed25519
scalars had the same endianness. For this reason, we now have to
reverse the bytes of recovered scalars if we are to use them on a
different chain.
Finally, there is no need to append `RUST_MIN_STACK=100000000` to
avoid stack overflows in tests and when running the binary.
There is some sort of timing issue when spinning up the monero containers on
github CI. I do not know exactly what is the cause but we have a configurable
'additional sleep time' already available for `testcontainers` that can resolve
this issue.
Use the environment variable MONERO_ADDITIONAL_SLEEP_PERIOD to tell
`testcontainers` to wait an additional 60 while bringing up the monero
container.
