253: Monero rpc installer for windows r=rishflab a=rishflab
I could not find an async zip archive extractor. The download is still async. One potential follow up could be to spawn the extraction of the zip in the windows path.
Closes#228
Co-authored-by: rishflab <rishflab@hotmail.com>
Previously we were ignoring if the monero wallet rpc was not found and
unpacked from archive leading to a failure down the line when trying to
run a non-existent executable. Bail when the executable is no found in
the archive.
248: Wait for wallet to catch up instead of block generation r=thomaseizinger a=da-kami
The monero harness wallet always starts a miner that mines new blocks every second.
This can conflict with additionally triggering block generation and cause this error:
```
monero_rpc::rpc::monerod: generate blocks response: {
"error": {
"code": -7,
"message": "Block not accepted"
},
"id": "1",
"jsonrpc": "2.0"
}
```
See error in CI run here: https://github.com/comit-network/xmr-btc-swap/runs/2001131193
Since the miner is generating blocks anyway we can wait for the wallet to catch up.
Refresh is done upon querying the balance, thus the refresh calls were removed.
---
Note: we could also opt for starting the miner optionally. This would make this test more efficient, but is a more intrusive change, thus I opted for this fix for now.
Co-authored-by: Daniel Karzel <daniel@comit.network>
243: Some cleanup + improve logging of the `swap_cli` r=thomaseizinger a=thomaseizinger
Please see commit messages for details. I've also included a few minor cleanups that I noticed on the way.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
254: Smoke test the binary in the release workflow + create 'latest' release r=thomaseizinger a=thomaseizinger
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
1. We can generalize the signing interface by passing a PSBT in
instead of the `TxLock` transaction.
2. Knowing the transaction ID of a transaction that we are about
to sign is not very useful. Instead, it is much more useful to know
what failed. Hence we add a `.context` to the call of `sign_and_finalize`.
3. In case the signing succeeds, we will immediately broadcast it
afterwards. The new broadcasting interface will tell us that we broadcasted
the "lock" transaction.
We eliminate unnecessary layers of indirection for broadcasting logic
and force our callers to provide us with the `kind` of transaction
that we are publishing.
Eventually, we can replace this string with some type-system magic
we can derive the name from the actual transaction. For now, we just
require the caller to duplicate this information because it is faster
and good enough TM.
This struct is a wallet. The only thing it can meaningfully broadcast
are transactions. The fact that they have to be signed for that is
implied. You cannot broadcast unsigned transactions.
Abstracting over the individual bits of functionality of the wallet
does have its place, especially if one wants to keep a separation
of an abstract protocol library that other people can use with their
own wallets.
However, at the moment, the traits only cause unnecessary friction.
We can always add such abstraction layers again once we need them.
If the user doesn't pass `--debug`, we only show `INFO` logs but
without time and level to make it clearer that it is meant to be
read by the user.
Without `--debug`, the user sees:
Still got 0.00009235 BTC left in wallet, swapping ...
With `--debug`, they see:
2021-03-01 12:21:07 DEBUG Database and seed will be stored in /home/thomas/.local/share/xmr-btc-swap
2021-03-01 12:21:07 DEBUG Starting monero-wallet-rpc on port 40779
2021-03-01 12:21:11 INFO Still got 0.00009235 BTC left in wallet, swapping ...
2021-03-01 12:21:11 DEBUG Dialing alice at 12D3KooWCdMKjesXMJz1SiZ7HgotrxuqhQJbP5sgBm2BwP1cqThi
2021-03-01 12:21:12 DEBUG Requesting quote for 0.00008795 BTC
Previously, the time was formatted as ISO8601 timestamps which is
barely readable by humans. Activating the `chrono` feature allows
us to format with a different format string. The output now looks
like this:
2021-03-01 11:59:52 DEBUG Database and seed will be stored in /home/thomas/.local/share/xmr-btc-swap
2021-03-01 11:59:52 DEBUG Starting monero-wallet-rpc on port 40673
2021-03-01 11:59:59 DEBUG Still got 0.00009235 BTC left in wallet, swapping ...
2021-03-01 11:59:59 DEBUG Dialing alice at 12D3KooWCdMKjesXMJz1SiZ7HgotrxuqhQJbP5sgBm2BwP1cqThi
2021-03-01 11:59:59 DEBUG Requesting quote for 0.00008795 BTC
There is a double space after the time which is already fixed in
tracing-subscriber but not yet released.
See https://github.com/tokio-rs/tracing/issues/1271.
Log messages are ideally as close to the functionality they are talking about, otherwise we might end up repeating ourselves on several callsites or the log messages gets outdated if the behaviour changes.
The monero harness wallet always starts a miner that mines new blocks every second.
This can conflict with additionally triggering block generation and cause this error:
```
monero_rpc::rpc::monerod: generate blocks response: {
"error": {
"code": -7,
"message": "Block not accepted"
},
"id": "1",
"jsonrpc": "2.0"
}
```
Since the miner is generating blocks anyway we can wait for the wallet to catch up.
Refresh is done upon querying the balance, thus the refresh calls were removed.
246: Change anyhow! to bail! in error scenarios r=da-kami a=da-kami
Unfortunately I handled the two failure scenarios in the ASB wrong - I thought that was fixed already, but that was different logic in a different PR.
😬😬😬
Co-authored-by: Daniel Karzel <daniel@comit.network>
237: Swap CLI buys xmr by default if no subcommand given r=rishflab a=rishflab
- [x] Needs watch for deposit functionality from #236Closes#234
Co-authored-by: rishflab <rishflab@hotmail.com>
These intermediate structs were creating unnecessary noise. The peer id
and multiaddr fields are going to be removed in the future further
reducing the need to have seperate structs for cancel, resume and
refund.
239: Remove windows from the release r=da-kami a=da-kami
At the moment windows fails to build. This has to be fixed before it is re-added to the release.
Co-authored-by: Daniel Karzel <daniel@comit.network>
If communication with the other party fails the program should stop and the user should see the respective error.
Communication errors are handled in the event-loop. Upon a communication error the event loop is stopped.
Since the event loop is only stopped upon error the Result returned from the event loop is Infallible.
If one of the two futures, event loop and swap, finishes (success/failure) the other future should be stopped as well.
We use tokio::selec! to stop either future if the other stops.
Failure does not express what the error represents. It is only used for communication
errors for quote requests, receiving the XMR transfer proof and sending the encryption signature.
235: monero-rpc debug log for moner-harness tests r=thomaseizinger a=da-kami
This allows us to see the response from the monerod client on debug.
When the monero-harness was split up into harness and rpc this was overlooked.
We need the debug logs to investigate the monero harness CI fail bug.
Co-authored-by: Daniel Karzel <daniel@comit.network>
