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>
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`.
