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.
119: Remember the block-height before XMR lock for generated monero wallet r=da-kami a=da-kami
The first approach https://github.com/comit-network/xmr-btc-swap/pull/121 was using `get_transfer_by_txid` that allows extrancting the exact tx-lock 1st confirmation block height.
But that introduced an additional error scenario, and I actually ran into that error scenario (`transaction not found`) once I ran it on `stagenet`. Might be that `get_transfer_by_txid` requires running the node in a specific way (like `txindex` on bitcoin).
I am not sure at this stage and don't want to invest more time.
Long story short:
I opted for just recording the height before watching for XMR locked. This means that we record a height right after sending the Bitcoin lock tx. (Because we start watching for XMR lock right after that.)
Bob's new wallet unnecessarily scans an additional 7+ blocks (assuming inclusion in the next Bitcoin block and one confirmation for Monero lock) every time which is a matter of milliseconds. Not worth optimising this further at this stage. This solution is more resilient as well, because it does not add another error scenario.
Co-authored-by: Daniel Karzel <daniel@comit.network>
127: Deterministic peer id for alice and bob r=da-kami a=da-kami
The first commit introduces a seed file similar to Nectar. Note, that the parameter --database was changed to --data-dir where the database is stored in the sub-folder database inside that data directory. This is breaking change, run commands will have to be adapted.
I opted for keeping the structure of generating an overall seed and then deriving the network seed from it (as in Nectar, where we use the seed for wallet creation as well). I feel this is cleaner than just using the seed for the network only.
The second commit applies the deterministic peer id to Bob as well. We don't have to do this because in the current setup Bob can have a new identity every time. I would still harmonize this to avoid confusion in the future. I don't see a reason why Bob's setup should be different from Alice here.
Co-authored-by: Daniel Karzel <daniel@comit.network>
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
118: Add minimum monero confirmations to config use it for Bob r=da-kami a=da-kami
After discussion with @bonomat about enforced `10` confirmations until a tx is spendable on Monero I gave it a try with only `1` confirmation on regtest happy-path-test and `5` for `stagenet` and did not encounter problems. Both swaps passed without problems so I am proposing to merge these changes.
One additional change crept in: Changed the average blocktime for `stagenet` to `4` mins, because the blocktime fluctuates a lot. See: https://monero-stagenet.exan.tech/
Co-authored-by: Daniel Karzel <daniel@comit.network>
115: Monero wallet network, Testnet r=da-kami a=da-kami
Add network for monero and switch application to run on Bitcoin `testnet3` and Monero `stagenet`.
Co-authored-by: Daniel Karzel <daniel@comit.network>
