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>
