Alice was attempting to create a new event loop using the same listen addr as the old one which was still running. This commit aborts the event loop before creating a new one.
Upgrade bitcoin harness dependency to latest commit
Upgrade backoff to fix failing tests. The previous version of backoff had a broken version of the retry function. Upgraded to a newer comit which fixes this problem.
Upgrade hyper to 0.14 as the 0.13 was bringing in tokio 0.2.24
Upgraded bitcoin harness to version that uses tokio 1.0 and reqwest 0.11
Upgrade reqwest to 0.11. Reqwest 0.11 uses tokio 1.0
Upgrade libp2p to 0.34 in preparation for tokio 1.0 upgrade
159: Introduce "one shots" r=D4nte a=D4nte
Instead of Alice sending messages to Bob by replying on a `RequestResponse` channel, she just acks reception on the channel and open her own channel to send messages to Bob.
This means we do not need to carry the channel around anymore and instead carry Bob's peer id.
We take this opportunity to rename messages as per the sequence diagram.
At this stage we only touch message 4 & 5 as they are the one shots messages of the protocol.
Decoupling message 4 from message 3 (still current called 2) will allow the introduction of an await/async behaviour that handles message 1, 2, 3.
To introduce message 1, 2, 3 we will introduced the async/await behaviour using https://github.com/comit-network/rust-libp2p-async-await
First, we need to upgrade tokio and libp2p.
Please note that thanks to this change, Alice now uses Bob's peer id to send message meaning that recovery is improved (as before we could not save the channel to the db).
Co-authored-by: Franck Royer <franck@coblox.tech>
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.
