As per the proposed changed in the sequence diagram.
The aim is to have a unique terminology per message instead of having
the same name for 2 consequent messages that share the same behaviour.
Note that the aim is to remove the shared `RequestResponse` behaviours.
154: Clean up `lib.rs` r=D4nte a=D4nte
Do not remove it just yet as there are still issues with the CI but proceed with some clean up.
Merging this now to avoid further merge conflicts.
Co-authored-by: Franck Royer <franck@coblox.tech>
155: Bob saves lock proof after received so he can resume swap r=da-kami a=da-kami
Introducing a new state was too much so I added the additional required information to the enum state rather than adding another struct.
As discussed earlier we should cleanup the state machine (enum states vs data structs) at some point :)
Co-authored-by: Daniel Karzel <daniel@comit.network>
153: Remove newlines from import statements to avoid problems r=da-kami a=da-kami
Rust fmt automatically groups the imports (from top to bottom) as `pub use` `use crate` and `use`.
There is no need to introduce sections which cause annoyance when auto importing using the IDE.
Co-authored-by: Daniel Karzel <daniel@comit.network>
Rust fmt automatically groups the imports (from top to bottom) as `pub use` `use crate` and `use`.
There is no need to introduce sections which cause annoyance when auto importing using the IDE.
149: Fix Alice redeem scenario r=da-kami a=da-kami
Follow up of #144, partial fix of https://github.com/comit-network/xmr-btc-swap/issues/137
Fix Alice redeem scenario
- Properly check the timelocks before trying to redeem
- Distinguish different failure scenarios and reactions to it.
- if we fail to construct the redeem transaction: wait for cancel.
- if we fail to publish the redeem transaction: wait for cancel but let the user know that restarting the application will result in retrying to publish the tx.
- if we succeed to publish the tx but then fail when waiting for finality, print error to the user (secreat already leaked, the user has to check manually if the tx was included)
Co-authored-by: Daniel Karzel <daniel@comit.network>
142: Rename Swap amounts to Swap req/res r=D4nte a=D4nte
As per #140
Question: Do we prefer `Negotiation Request/Response` to `Swap Request/Response`?
Co-authored-by: Franck Royer <franck@coblox.tech>
- Properly check the timelocks before trying to redeem
- Distinguish different failure scenarios and reactions to it.
- if we fail to construct the redeem transaction: wait for cancel.
- if we fail to publish the redeem transaction: wait for cancel but let the user know that restarting the application will result in retrying to publish the tx.
- if we succeed to publish the tx but then fail when waiting for finality, print error to the user (secreat already leaked, the user has to check manually if the tx was included)
This is not really a factory as a factory design pattern is about
producing several instances.
In the current usage, we are only interested in one swap instance. Once
the swap instance is created, the factory becomes useless. Hence, it is
more of a builder pattern.
147: Refactor prod code after test refactoring r=da-kami a=da-kami
Follow up of https://github.com/comit-network/xmr-btc-swap/pull/144
Took a bit more than expected, but this is really neat now!
The commits should be well-contained for reviewing, but 00835baa15 is quite big.
I changed the abstraction on the way - out methods are finally named `run` and `run_until` which both take a swap - which makes way more sense I think :)
Also had to change the abstraction layers in `testutils` and introduced `Test` which specifies the swap amounts (that would usually come from the commandline and should not live in the factory as they are irrelevant for resumed swaps).
Co-authored-by: Daniel Karzel <daniel@comit.network>
Currently this code is actually not reachable, but that is semantically applied by the program's flow (the resume command includes the swap direction).
It is still preferred to have an error message rather than an unreachable statement.
