Add type loopOutSweepFeerateProvider which determines confTarget based on
distance to swap expiration, then determines feerate and fee using. Fee rate
is plugged into sweepbatcher using WithCustomFeeRate. Option WithPublishDelay
is used to make sure fee-rate is updated by loopout.go before the value is used
by sweepbatcher.
When determining confTarget, there are few adjustments over raw distance to
cltv_expiry:
- make sure confTarget is positive (if the swap has expired, raw distance is
negative)
- If confTarget is less than or equal to DefaultSweepConfTargetDelta (10),
cap it with urgentSweepConfTarget and apply fee factor (1.1x).
Also, if feerate is less than floor (1 sat/vbyte), then the floor is used.
DefaultSweepConfTargetDelta was decreased from 18 to 10.
Every block 100 sats/kw fee bump is disabled. Sweepbatcher re-targets feerate
every block according to current mempool conditions and the number of blocks
until expiry.
Added tests for loopOutSweepFeerateProvider simulating various conditions.
There are some numeric constants that used to be defined as vars complicating
their usage. They were turned into constants: MinLoopOutPreimageRevealDelta,
DefaultSweepConfTarget, DefaultHtlcConfTarget, DefaultSweepConfTargetDelta.
Also make liquidity.defaultHtlcConfTarget a constant, not a var.
This commit changes the way we fetch the l402 tokens for the
notification stream. Instead of fetching them from the server and
paying an invoice, we now look into our local store for the token.
This means that a loop client will not autofetch a token.
This commit updates the instantout package to use the new fsm context
instead of the old fsm context. This is only a first step in the process
of migrating the instantout package to the new fsm context. The next
step should be to remove the stored context in the instantout manager.
This commit updates the reservation package to use the new fsm context
instead of the old fsm context. This is only a first step in the process
of migrating the reservation package to the new fsm context. The next
step should be to remove the stored context in the reservation manager.
Previous behaviour was to overwrite batch's feerate with minFeeRate of
its primary sweep, which could be lower that previus batch's feerate or
lower that feerate of some other sweep.
Instead, batch's feerate only grows and never declines and is at least as high
as the highest feerate of its sweeps.
Added a test to verify this.
This commit refactors the proto definitions of the
reservation notifications to use a more generic
mechanism that can be used for other types of
notifications as well.
Previously we defaulted to fetching 1000 payments at a time when running
the cost migration however due to slowness on LND side this may prevent
the migration from completing due to RPC timeout kicking in. This commit
adds a new config value to give more control to the user by setting the
batch size as needed.
