If we wait for lock transaction confirmations immediately after sending the transaction without saving this state to the DB this might cause locking the money twice.
An additional state is needed for such a scenario.
This includes the introduction of the --data-dir parameter instead of the --database.
Both the seed file and the database are stored in the data-dir, the database in sub-folder `database`.
We already select waiting for this message with the cancellation expiry,
we do not need add another guard that tries to guess how long it would
for the Monero transaction to be finalised.
Created network, storage and protocol modules. Organised
files into the modules where the belong.
xmr_btc crate moved into isolated modulein swap crate.
Remove the xmr_btc module and integrate into swap crate.
Consolidate message related code
Reorganise imports
Remove unused parent Message enum
Remove unused parent State enum
Remove unused dependencies from Cargo.toml
We have overridden a number of clippy warnings such as
"large enum variant".
Considering that we have a number of issues
with the stack size in CI, it is more prudent to follow clippy's advice
and box larger items so that the enum does not take larger space.
Do note that an instance of the enum always takes as much space as its
largest variant.
There are no refund timelock, only a cancellation timelock and punish
timelock.
Refund can be done as soon as the cancellation transaction is published.
107: Ensure that Bob can cancel correctly if T1 expired and Alice did not … r=da-kami a=da-kami
Bob has to check for the possibility to cancel in every state after he locked the BTC.
Otherwise Bob will try to perform actions that don't have any point and it might be impossible to use the `resume` command because it will always fail in trying to go on with Alice even though that might not be possible.
Co-authored-by: Daniel Karzel <daniel@comit.network>
