since deposits have been normalized in the db in the
context of a static address swap this commit now
retrieves the deposit information as part of
GetLoopInByHash and GetStaticAddressLoopInSwapsByStates.
- ensurePresigned: use passed minRelayFeeRate instead of chainfee.FeePerKwFloor
- presign: use minRelayFeeRate for start and minRelayFee
- presign: make sure minRelayFeeRate is set
- add tests for presign to test this new behavior; make sure the number of
transactions is lower if minRelayFeeRate is higher
- update error message in constructUnsignedTx: use <, not <= (more accurate)
- use utils.DustLimitForPkScript instead of lnwallet.DustLimitForSize in tests
- in tests adjust amounts to edge values, add controls
Presigning sweeps takes change outputs into account.
Each primary deposit id of a sweep group points to
an optional change output.
sweepbatcher.presign scans all passed sweeps for
change outputs and passes them to constructUnsignedTx.
Optional change of a swap is encoded in its sweeps
as a pointer to the same change output. This change
is taken into account when constructing the unsigned
batch transaction when it comes to tx weight and
outputs.
AddSweep may not be called after getting the first confirmation, but feerate
updates are still needed in case of reorg.
Update test TestFeeRateGrows not to call AddSweep again and make sure feerate
is updated itself.
The reorg channel is now passed to RegisterSpendNtfn, and waiting for spend
notifications remains active even after the transaction receives its first
confirmation. The dedicated goroutine previously used to wait for the spend
is no longer needed, as we now handle both spend and potential reorg events
in the main event loop while the batch is running.
Following this change, RegisterConfirmationsNtfn runs without a reorg channel,
as it would only detect deep reorgs that undo the final confirmation - something
we can't handle anyway. We can't track fully confirmed swaps indefinitely to
guard against such rare reorgs; instead, we can mitigate the risk by increasing
the required confirmation depth.
Since bb837a4aec AddSweep loads sweeps so
one of possible errors is sql.ErrTxDone. Full error that is fixed:
> fetchSweeps failed: failed to load sweep 0000000000000000000101:1:
> failed to fetch sweep data for 010101000000:
> failed to fetch loop out for 010101000000:
> sql: transaction has already been committed or rolled back
previously upon recovery, a withdrawing deposit was
first transitioned into the Deposited state by the
deposit manager, and then again into the Withdrawing
state by the withdrawal manager. The first transition
is unnecessary, so we just remain in the Withdrawing
state upon recovery.
For presigned possible remaining groups, the destination address of the current
batch was used instead of the destination address of an expected future batch.
TODO: reproduce in unit test "purged". For this, each swap should have a
separate destination address.
