1. `monero-rpc` is not in the position to decide about the TLS backend
an application should use.
2. We don't use TLS encrypted communication to my knowledge so we don't
have to activate this feature anywhere else.
210: Change monitoring to default wallet r=da-kami a=da-kami
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.
Additionally there is a check for the balance - if the balance is zero an address is printed for depositing funds.
Co-authored-by: Daniel Karzel <daniel@comit.network>
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.
215: Debug log level in monero harness tests to see RPC responses r=da-kami a=da-kami
CI keeps failing when generating blocks, but response is only printed on debug level.
To investigate what is the problem change monero-harness log levels to debug.
Example failure:
https://github.com/comit-network/xmr-btc-swap/runs/1938109584
The failure happened when generating blocks, but without seeing the response error it is impossible to know what happened. Could not reproduce this problem locally.
Co-authored-by: Daniel Karzel <daniel@comit.network>
CI keeps failing when generating blocks, but response is only printed on debug level.
To investigate what is the problem change monero-harness log levels to debug.
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>
213: Properly calculate the confirmations for Bitcoin tx r=da-kami a=da-kami
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).
I could not think of a more elegant solution - if you have one please comment :)
Co-authored-by: Daniel Karzel <daniel@comit.network>
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)
205: Optimize GitHub workflow file r=thomaseizinger a=thomaseizinger
See commit messages for further details.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
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.
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>
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.
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>
