182: Segregate CLI specific modules r=D4nte a=D4nte
To prepare for the introduction of nectar modules.
Co-authored-by: Franck Royer <franck@coblox.tech>
Hence, reducing complexity of the codebase. Note that the seed will be
used by both nectar and the cli whereas the config mod will be different
so this changes helps with the next step of having a dedicated config
module for each binary.
177: Nectar r=D4nte a=D4nte
Re-work Alice do be the Service Provider (nectar).
This means that Alice's event loop runs all the time and processes swap requests.
- We currently use a hardcoded fixed rate
- The binary for nectar is to be done in follow-up PR
- We removed the message acknowledgement feature as it created issues with other work and some work would have been needed to link a ack to the correct swap on Alice side.
- Because we removed the acks, we had to remove a number of restart tests. This can be re-introduced at a later stage once a decision on how to best test the restarts can be done
- We remove the punish test as it is a nectar (alice) feature and current focus is on the CLI (bob).
Co-authored-by: Franck Royer <franck@coblox.tech>
The punish test needs re-work due to the fact that Alice runs continuously
Currently focusing on the CLI (Bob), so we can re-introduce this test
once we want to ensure that nectar (Alice) punishes.
The test do not work without acks as we stop the event loop as soon
as a message is considered as "sent" when actually the event loop
and swarm may not have yet sent the message.
The ack allow to avoid this issue as the message was considered "sent"
only once the other party sent a response. However, the ack brings
other issue so a review needs to be done to select the appropriate
solution.
We are aware of issues of timeouts when waiting for acknowledgements.
Also, to properly supports acks in a multiple swap context, we need to
revert to doing event processing on the behaviour so that we can link
leverage the `RequestResponse` libp2p behaviour and link the messages
requests ids to swap ids when receiving an ack or response.
Acks are usefully for specific scenarios where we queue a message on the
behaviour to be sent, save as sent in the DB but crash before the
message is actually sent. With acks we are able to resume the swap,
without ack, the swap will abort (refund).
`alice::swap::run_until` will be called once the execution setup is
done. The steps before are directly handled by the event loop,
hence no channels are needed for said steps: connection established,
swap request/response & execution setup.
The `EventLoop` will use the `Builder` interface to instantiate a
`Swap` upon receiving a `SwapRequest` and successfully doing an
execution setup.
Before this change, the `EventLoop` would have to hold the path to the
db and re-open the db everytime it wants to construct a swap.
With this change, we can open the DB once and then hold a
`Arc<Database>` in the `EventLoop` and pass it to new `Swap`s structs.
179: Watch only tmp monero wallet r=da-kami a=da-kami
When initializing Monero wallet, try to open temporary wallet, if opening errors then try to create it. If creating errors then fail with message asking the user to configure the wallet RPC.
If opening / creation succeeds get the block_height to verify that connection to wallet works, then proceed to swap.
Note: RPC error handling is hacky, but I don't see the value of investing time into that at this point. The problem is, that we don't deal with the json rpc errors properly for calls were we don't serialize the result into an object (because the response is empty). Eventually we should switch to using https://github.com/thomaseizinger/rust-jsonrpc-client but that does not support parameters `by-name` yet, see: https://github.com/thomaseizinger/rust-jsonrpc-client/issues/20
Co-authored-by: Daniel Karzel <daniel@comit.network>
170: Cancel and refund commands r=da-kami a=da-kami
I plugged the cancel and refund logic into the current state/state-machine logic of the swap.
## Follow ups (out of scope)
We might want to record issues to be tackled later, since we are on a tight time budget :)
Please let me know what you think @D4nte @rishflab
### Problems with `ack` after sending a message
Alice was waiting forever when awaiting the `ack` from bob when sending the lock proof in case she runs into a dial error. It seems the `acks` can cause the program to hang. This is a severe problem that we most probably will encountered in production at some point. For this PR I wrapped the `ack` of Alice upon sending the `encsig` in a timeout to work around this problem, see 7463081f88 - but **we might want to consider to remove all `ack` message. I don't see much value in them if we don't have a resilient retry strategy.**
### Do not require Monero wallet for cancel/refund
The cancel/refund commands don't require a monero wallet.
In this PR we re-uses the builder which requires the monero wallet as well - and we check for the monero balance upon wallet initialization, so the command will fail if no monero wallet is started.
### Save Alice connection info in Bob DB
Save Alice's peer-id/address in DB: It's cumbersome for the user to lookup those details again.
Co-authored-by: Daniel Karzel <daniel@comit.network>
This was introduced due to a CI run, where Bob included tx_refund, but Alice had waited until T2 had expired,
and then went for punishing Bob instead of refunding.
Weirdly, Alice's punich transaction did not fail in that scenario.
If dialing Bob fails Alice waits for the acknowledgement of the transfer proof indefinitely.
The timout prevents her execution from hanging.
Added a ToDo to re-visit the ack receivers. They don't add value at the moment and should be removed.
