We already have a Label field in the embedded SwapContract
field for loop in swaps. This commit removes an erroneously
added Label field in LoopInContract which may be a cause of
ambiguity when referencing this field.
Add an implementation of our swap interface which can be used for
loop in, and fee estimation. For fee estimation, we always want to
calculate worst case loop in fees, so that autoloop never goes over
its budget. However, for loop in we can't estimate how much a
timeout would cost, because we must sweep the output (can't set
a limit like loop out), and fee estimation in a few hundred blocks
(when we'd sweep the timeout) is totally unreliable.
Instead, we use a high fee rate as our best-effort fee rate for
the future. We can also be confident that that loop in swaps will
succeed, since once the htlc is locked in, all that is required
is for the server to sweep.
In preparation of supporting multiple swap types, we move our swap
builder into a single place, so that we can check our `maySwap`
restriction per-swap (since we'll now have different checks for
different swap types.
To save ourselves from making multiple calls to the loop server for
the restrictions placed on each swap type, we still pass a single
set of restrictions in.
In preparation for adding loop in swaps, we relate liquidity rules
to a specific type of swap that we want to dispatch. This allows us
to use a single rule format for multiple swap types.
The current wording in this function is very specific to loop out.
In this commit, we refactor to use `target` and `reserve` rather
than inbound and outbound so that it can be used more generically.
To allow code with more up-to-date dependencies to import loop, we
bump our lndclient version. The minimum loop version remains 11.1
since we're not using any new apis.
This commit adds a peer listing function to our generic swap
interface, which we will use to set reasons for swaps that are
specified by peer pubkey rather than channel.
We add 'peer-level' rules to allow assessment of liquidity on a per-peer
level, rather than on an individual channel basis. No overlap is allowed
with the existing set of channel rules because this could lead to
contradictory rules.
This commit switches up our eligible channels logic to rather return
a struct containing information about our current swap traffic. This
change is made in preparation for returning reasons indicating why we
did not perform a swap for a specific channel - when we only return
eligible swaps, we lose the information about why all the excluded
channels weren't used.
In practice, this restriction has proven to be too strict. Autoloop will
now only hold off on a swap for a channel if a manual swap is
specifically using that channel.
In an effort to surface more information about why autoloop is not
executing, we add an error when suggest swaps is called with no rules.
In other cases we can surface a reason enum with each rule that is set,
but in the case where we have no rules, there are no results to
accompany with reasons.
To itest our autolooper, we need to be able to trigger dispatch on
demand. This functionality is included in a separate rpc server behind
a dev flag. Since it is unlikely that we need to split loop into
multiple rpc servers, this commit simply adds an additional debug server
rather than opting for a full subserver setup.
Add a dated fee budget to our swap suggestions. This budget only applies
to automatically dispatched swaps (which will be added in later
commits). We choose to apply the fee budget to our suggestions so that
they perfectly replicate what the autolooper would do. The budget has a
start date so that it can be refreshed once it has been used up over a
period (rather than having to endlessly increase it).
As we add more parameters in this PR, we wil want to test values
beyond our default values. This commit updates the suggest swaps test
helper to take a full setup struct, and adds a default set of channels
and rules which will be used in the absense of this setup struct.
To decide whether we event want to attempt a swap, we add a fee limit
that we check against our estimate for the current number of
confirmations we want our sweep to confirm in. If fees are higher than
this limit, we do not suggest swaps.
