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.
178: Replace bitcoind wallet with bdk wallet r=rishflab a=da-kami
Create and pair bitcoind and electrs testcontainers using the same docker network and volume.
Follow-up to be fixed on top:
- [ ] Remove bitcoin-harness dependency and directly depend on https://github.com/thomaseizinger/rust-jsonrpc-client for the RPC client.
Co-authored-by: rishflab <rishflab@hotmail.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
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.
191: Use Remote handle to access ongoing swaps on Alice r=rishflab a=D4nte
This helps stabilizing the test as sometimes we were checking Alice state (in the DB) too early.
Co-authored-by: Franck Royer <franck@coblox.tech>
182: Segregate CLI specific modules r=D4nte a=D4nte
To prepare for the introduction of nectar modules.
Co-authored-by: Franck Royer <franck@coblox.tech>
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.
177: Nectar r=D4nte a=D4nte
Re-work Alice do be the Service Provider (nectar).
This means that Alice's event loop runs all the time and processes swap requests.
- We currently use a hardcoded fixed rate
- The binary for nectar is to be done in follow-up PR
- We removed the message acknowledgement feature as it created issues with other work and some work would have been needed to link a ack to the correct swap on Alice side.
- Because we removed the acks, we had to remove a number of restart tests. This can be re-introduced at a later stage once a decision on how to best test the restarts can be done
- We remove the punish test as it is a nectar (alice) feature and current focus is on the CLI (bob).
Co-authored-by: Franck Royer <franck@coblox.tech>
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.
