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.
- Introduce Test abstraction instead of tow harnesses, move test specific data into Test
- Change the abstraction from actors to swap, because we are creating swaps, not actors
- rename actor::swap to run, because we are running a swap
145: Make lock-tx id available in redeem/punish state to be able to assert exact fees r=da-kami a=da-kami
We can do exact assertions for Bob's redeem as well, but have to store Bob's tx_lock id in the respective final state. Make tx_lock available in BtcRedeemed and BtcPunished to have better assertions / harmonize test behaviour.
Storing this information is strictly speaking not needed for the production environment. But it is static information that can be seen as additional information that can be handy for a user. We could potentially extract it inside the tests as well (for redeem without restart would be a bit tricky), but I think this solution is more elegant.
Co-authored-by: Daniel Karzel <daniel@comit.network>
Co-authored-by: Franck Royer <franck@coblox.tech>
Co-authored-by: bors[bot] <26634292+bors[bot]@users.noreply.github.com>
