For transitioning to state4 we either go into a redeem or a cancellation scenario.
The function name state4 is misleading, because it is only used for cancellation scenarios.
This TDOO is misleading, because - to our current knowledge - it is impossible for
Bob to retrieve the exact inclusion block-height of the lock transaction (send by Alice).
The wallet RPC is only capable of retrieving the inclusion block height of a transaction
through `get_payments` and `get_bulk_payments` which requires the `payment_id`.
The `payment_id` can be retrieved through `get_transfer_by_txid` which states
"Show information about a transfer to/from this address." - however the address that the
transfer goes to is not part of Bob's wallet yet! Thus, it is impossible for Bob to use
`get_transfer_by_txid` which in turn means Bob is unable to use `get_payments`.
The only possible way for Bob to know the exact inclusion block/height of the lock transaction
would be if Alice sends it over to Bob. But for that Alice would have to extract it she would have
to wait for confirmation - which she currently does not and might never do. Even if she does await
the first confirmation before sending the transfer proof the solution for retrieving the inclusion
block-height is not fleshed out on her side yet.
In order to ensure that we can atomically generate_from_keys and then reload a wallet,
we have to wrap the client of the monero wallet RPC inside a mutex.
When introducing the Mutex I noticed that several inner RPC calls were leaking to the
swap crate monero wallet. As this is a violation of boundaries I introduced the traits
`GetAddress`, `WalletBlockHeight` and `Refresh`.
Note that the monero wallet could potentially know its own public view key and
public spend key. If we refactor the wallet to include this information upon wallet
creation we can also generate addresses using `monero::Address::standard`.
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.
- 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>
144: Test refactor r=da-kami a=da-kami
This PR is pure refactoring, keeping the logic of the tests we had before. No production code is touched besides re-exports in early commits (no logic changes).
In the follow ups improvements will be introduced, that touch the production code as well.
All remaining tasks actioned since Friday:
- [x] `happy_path_bob _restart` (trivial)
- [x] add refund assertions to harnesses (trivial)
- [x] convert all refund scenarios currently being tested (trivial)
- [x] remove dead test init code once all old tests are converted
- [ ] ~~(optional) move alice and bob harness code into separate files~~ -> might action this once re-using test code in production.
Out of scope, follow up:
- [x] https://github.com/comit-network/xmr-btc-swap/pull/145 - 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.
- [ ] update the production code to use the `Alice` and `Bob` structs to bundle the params - update tests to use the production struct.
- [ ] Re-use test swap setup in production (i.e. `Alice-/BobHarness::new`) to setup the swap.
- [ ] add additional tests
- [ ] re-try moving the tests from `test` to `src` (if the peer_id was the only problem this should be trivial now - but should be done after the refactor is finished)
- [ ] creating new wallets upon restart
- [ ] aborting the old event loop after restart
Co-authored-by: rishflab <rishflab@hotmail.com>
Co-authored-by: Daniel Karzel <daniel@comit.network>
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
