If the current balance is 0, we wait until the user deposits money
to the given address. After that, we simply swap the full balance.
Not only does this simplify the interface by removing a parameter,
but it also integrates the `deposit` command into the `buy-xmr`
command.
Syncing a wallet that is backed by electrum includes transactions
that are part of the mempool when computing the balance.
As such, waiting for a deposit is a very quick action because it
allows us to build our lock transaction on top of the yet to be
confirmed deposit transactions.
This patch introduces another function to the `bitcoin::Wallet` that
relies on the currently statically encoded fee rate. To make sure
future developers don't forget to adjust both, we extract a function
that "selects" a fee rate and return the constant from there.
Fixes#196.
These traits were only used once within the `TxLock` constructor.
Looking at the rest of the codebase, we don't really seem to follow
any abstractions here where the protocol shouldn't know about the
exact types that is being passed in.
As such, these types are just noise and might as well be removed in
favor of simplicity.
The only reason we need this argument is because we need to access
the output descriptor. We can save that one ahead of time at when
we construct the type.
BDK already has a log line for the sync that we could enable if we
wanted such a log.
Additionally, _we_ are not actually syncing the wallet, bdk is so our
log line was lying. It should have said "calling bdk to sync wallet".
If the monero wallet rpc has not already been downloaded we download the monero cli package and extract the wallet rpc. The unneeded files are cleaned up. The monero wallet rpc is started on a random port which is provided to the swap cli.
We added a fork of tokio-tar via a git subtree because we needed a tokio-tar version that was compatible with tokio 1.0. Remove this subtree in favor of a regular cargo dependency when this PR merges: https://github.com/vorot93/tokio-tar/pull/3.
225: Asb refund reload main wallet r=da-kami a=da-kami
Fixes#211
Please review by commit and read the commit messages.
Co-authored-by: Daniel Karzel <daniel@comit.network>
For transitioning to state4 we either go into a redeem or a cancellation scenario.
The function name state4 is misleading, because it is only used for cancellation scenarios.
This TDOO is misleading, because - to our current knowledge - it is impossible for
Bob to retrieve the exact inclusion block-height of the lock transaction (send by Alice).
The wallet RPC is only capable of retrieving the inclusion block height of a transaction
through `get_payments` and `get_bulk_payments` which requires the `payment_id`.
The `payment_id` can be retrieved through `get_transfer_by_txid` which states
"Show information about a transfer to/from this address." - however the address that the
transfer goes to is not part of Bob's wallet yet! Thus, it is impossible for Bob to use
`get_transfer_by_txid` which in turn means Bob is unable to use `get_payments`.
The only possible way for Bob to know the exact inclusion block/height of the lock transaction
would be if Alice sends it over to Bob. But for that Alice would have to extract it she would have
to wait for confirmation - which she currently does not and might never do. Even if she does await
the first confirmation before sending the transfer proof the solution for retrieving the inclusion
block-height is not fleshed out on her side yet.
In order to ensure that we can atomically generate_from_keys and then reload a wallet,
we have to wrap the client of the monero wallet RPC inside a mutex.
When introducing the Mutex I noticed that several inner RPC calls were leaking to the
swap crate monero wallet. As this is a violation of boundaries I introduced the traits
`GetAddress`, `WalletBlockHeight` and `Refresh`.
Note that the monero wallet could potentially know its own public view key and
public spend key. If we refactor the wallet to include this information upon wallet
creation we can also generate addresses using `monero::Address::standard`.
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.
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.
