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>
136: Testnet resume fixes r=da-kami a=da-kami
Add a few log statements on Bob's side to make the user experience better.
Update / remove ToDos.
I set the log level to `Info` in main again, `Debug` heavily clutters the output. In order to make `Debug` more usable we might want to review printing all those `rpc` messages. But this goes beyond the scope of this PR.
Co-authored-by: Daniel Karzel <daniel@comit.network>
This makes the redeem assertion reusable for all tests with a redeem scenario.
Since the factory was not a clean factory before and is now doing even more it was renamed to harness.
- Bob initiate swap with BTC Amount
- Alice acks with approx. xmr amount
- Rework terminology, make a difference between negotiations and
execution setup
- Remove request response channels in favor of one shots
- Give exact amount to Bob once assets are locked
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>
