Use each channel's local balance minus its reserve when simulating Loop
Out payment bandwidth, clamping the result at zero. This prevents swaps
from starting when the gross balance covers the amount and routing fee
but the spendable balance does not.
Add one-sat boundary tests and a bug-fix release note. Leave a TODO for
server-fee and prepay capacity because enforcing their maximum fee caps
could reject viable swaps whose actual routing fees are lower.
Record replayed server risk decisions through the loop-in store,
recover accepted payment-deadline timers using the persisted decision
time, and handle persisted rejections on restart. This lets recovered
static loop-ins keep pending confirmation-risk state instead of
restarting payment timing from scratch.
Build list and summary responses from tracked deposit records instead
of raw wallet UTXOs so RPC clients see the manager availability state.
Split unconfirmed value from confirmed deposited value in summaries,
and reject manual loop-in quotes for selected deposits that are not
currently Deposited.
Static-address loop-ins in autoloop are still experimental. Reject
loop_in_source=static-address at the RPC boundary unless loopd was started
with --experimental, and pass the same opt-in into the liquidity manager so
persisted params cannot bypass the gate after restart.
The existing static swap accounting remains wired through the manager; the
gate only controls accepting and planning new static-address autoloops.
Static autoloop testing surfaced a SuggestSwaps failure when the
planner disqualified a custom asset channel.
Add the missing AutoReason enum value and handle ReasonCustomChannelData.
Extend the public rpc surface for static autoloop integration
without turning the planner on yet. SuggestSwaps responses can
now carry static-address loop-in requests and the new planner
reason for missing static candidates is mapped over rpc.
Move static loop-in label validation to the rpc boundary and
remove the same check from the internal manager path.
This keeps external requests aligned with the existing swap rpc
surface while allowing internal autoloop callers to keep using
reserved labels for automated swaps. The tests cover both sides of
that contract: rpc requests still reject reserved labels, and the
manager path accepts them.
The Parameters struct describes the keys, expiry and pkScript that
define the static address script, so its natural home is the script
package. Moving it there lets staticutil drop its dependency on the
address package and lets callers reuse a single type alongside
script.StaticAddress and script.NewStaticAddress.
No behavior change.
Closes#1056
Loop now guards all static-address managers against zero block heights: each
constructor returns an error when invoked with a non-positive current height,
and `loopd` validates the height from `GetInfo` before instantiating them.
Tests and helper code were updated accordingly so we fail fast instead of
registering chain notifications with invalid hints.
If a quote request contains an amount and flag
SelectDeposits set to true the quoting coin-
selects the required deposits to meet the
swap amount in order to quote for the number
of deposits.
This commit adds verification to the loop out request to ensure that the
formatting of the specified destination address matches the network that
lnd is running on.
This commit moves loop out request validation for labels and
confirmation targets into its own function for the purpose of easy
testing and also to make the additions of future request validation easy
to add and test.
Update validate function to return default target for zero value
confirmation targets, as indicated by the comment. This change
introduces a behaviour change for direct rpc calls to loopd (ie,
those not made by the loop cli tool). Previously, these calls
would fail and indicate that the conf target must be > 2, now
they will succeed with the default conf target. The loop cli
tool is unaffected because we already set the default value.
When clients upgrade from a previous version of loopd which did
not have this check, preexisting loops will be unaffected, because
loop ins had the default of 6 confirmations set, and loop outs with
<2 conf target would not have been created.
