We retry to lock the Monero wallet until we succeed or until the cancel timelock expires.
This is necessary because the monero-wallet-rpc can sometimes error out due to various reasons, such as
- no connection to the daemon
- "failed to get output distribution"
See https://github.com/comit-network/xmr-btc-swap/issues/1726
allow --change-address to be omitted and default to internal wallet address (#1709)
Co-authored-by: binarybaron <86064887+binarybaron@users.noreply.github.com>
Co-authored-by: Byron Hambly <byron@hambly.dev>
This PR changes the following behaviour in the refresh functionality of the monero wallet
- Allows for multiple retries because in some cases users have experienced an issue where the wallet rpc returns `no connection to daemon` even though the daemon is available. I'm not 100% sure why this happens but retrying often fixes the issue
- Print the current sync height after each failed attempt at syncing to see how far we've come
- The `monero-wallet-rpc` is started with the `--no-initial-sync` flag which ensures that as soon as it's started, it's ready to respond to requests
- The `monero-wallet-rpc` was upgraded to `v0.18.3.1` because this PR https://github.com/monero-project/monero/pull/8941 has improved some of the issues mentioned above
This PR is part of a larger effort to fix this issue https://github.com/comit-network/xmr-btc-swap/issues/1432
* ci: add cargo check on rust stable
* refactor: upgrade secp256kfun and fix resulting issues
* build(deps): update sigma_fun and ecdsa_fun to a52142cf7f
#1520#1521
* chore: fix clippy issue
* update to 91112f80b24
* bump to 294de1721add
* chore(deps): remove spectral
spectral fails to compile on rust stable 1.76 due to dep on deprecated
rustc-serialize
* secp256kfun: update to 7da9d277 and set rev in manifest
* update to 6fdc5d8
* switch to crates.io versions of ecdsa_fun and sigma_fun
* ci: update toolchain to 1.74 and fix draft action
* clippy fixes
---------
Co-authored-by: binarybaron <86064887+binarybaron@users.noreply.github.com>
* Upgrade monero-wallet-rpc to `v0.18.3.1`
* Give feedback to user about state of monero refresh and retry if fails
This commit changes the following behaviour in the refresh functionality of the monero wallet
- Allows for multiple retries because in some cases users have experienced an issue where the wallet rpc returns `no connection to daemon` even though the daemon is available. I'm not 100% sure why this happens but retrying often fixes the issue
- Attempt to print the current sync height while the wallet is syncing. This only works to some degree because the `monero-wallet-rpc` stops responding (or takes a long time to respond) while it's refreshing
- The `monero-wallet-rpc` is started with the `--no-initial-sync` flag which ensures that as soon as it's started, it's ready to respond to requests
---------
Co-authored-by: Byron Hambly <bhambly@blockstream.com>
Co-authored-by: Byron Hambly <byron@hambly.dev>
- swap cli will check its wallet rpc version and delete the binary if
its version does not match on "Fluorine Fermi". it will then download
the newer version.
- adds download progress for wallet rpc
In testing, ASB panicked in `max_bitcoin_for_price` when the Monero
balance x Bitcoin price was enough to overflow `u64`.
This commit changes the function to do the piconero offset division
first, and then to use `checked_mul` to return None if the calculation
would overflow. This required changing the function return
signature to an `Option`. Additional tests for the function were also added.
MONERO_FEE was changed from 0.000030 to 0.000016, which is still
double the current median transaction fee listed at
https://www.monero.how/monero-transaction-fees as of 2022-07-28.
On Linux and macOS, no program output was being observed.
This is referenced in the [LocalTime] docs for `tracing-subscriber`,
which links to this [unsoundness issue] in the time crate.
Rather than introducing a possible vector for undefined behaviour and
segfaults, I have just changed the logging to use UTC time instead.
When running the ASB as a systemd service, one would generally use the
`--disable-timestamps` flag anyway as systemd adds its own timestamps
which can be local to the server.
If the situation with `tracing-subscriber` and the time crate is fixed
then this can be updated.
This commit also updates the `tracing-subscriber` and `tracing-appender`
dependencies, closing #987.
[LocalTime]: https://docs.rs/tracing-subscriber/latest/tracing_subscriber/fmt/time/struct.LocalTime.html
[unsoundness issue]: https://github.com/time-rs/time/issues/293#issuecomment-748151025
