This commit breaks the ChannelConstraints structure into two
sub-structures that reflect the fundamental differences in how
these parameters are used. On its face it may not seem necessary,
however the distinction introduced here is relevant for how we
will be implementing the Dynamic Commitments proposal.
This commit introduces a ChannelParty type to LND. It is useful for
consolidating all references to the duality between the local and
remote nodes. This is currently handled by having named struct rows
or named boolean parameters, named either "local" or "remote". This
change alleviates the programmer from having to decide which node
should be bound to `true` or `false`. In an upcoming commit we will
change callsites to use this.
In this commit we opt to make the internal response channel fully
private and instead expose methods for doing resolution. This
prevents internal implementation details from leaking a little bit
better than the previous iteration.
It is common throughout the codebase to send data to a remote
goroutine for processing. Typically, along with the data we are
processing, we also send a one-shot channel where we intend to
listen for the response. This type encapsulates that pattern.
Even if no HTLCs are at stake we are going to register the anchor
outputs with the sweeper subsystem with a default high deadline.
We need to do this, because otherwise we are not able to bump the
fee of the closing transaction manually.
The time lock weight for a hop is supposed to be proportional to the
amount that is sent/locked, but in a previous change we switched to the
net amount, where inbound fees aren't yet applied. This is corrected in
this commit.
When iterating edges, pathfinding checks early whether using an edge
would violate the requested total fee limit for a route. This check is
done on the net amount (an amount the inbound fee is calculated with).
However, a possible next hop's fee discount leads to a reduction in fees
and as such using the net amount leads to assuming a higher cumulative
fee than the route really has, excluding the path erroneously. We
perform the fee limit check on the amount to send, which includes both
inbound and outbound fees. This should be possible as the first hop's
outbound fee is zero and therefore doesn't have to be checked in the
end.
Add the missing SERVER_ACTIVE state to the readiness probe. Without
this, a node that is ready to accept RPC calls would be incorrectly
considered not ready.
This commit expands the definition of the dust limit to take into
account commitment fees as well as dust HTLCs. The dust limit is now
known as a fee exposure threshold. Dust HTLCs are fees anyways so it
makes sense to account for commitment fees as well. The link has
been modified slightly to calculate dust. In the future, the switch
dust calculations can be removed.
This commit introduces more sophisticated code for selecting dummy hop
policy values for dummy hops in blinded paths.
For the case where the path does contain real hops, the dummy hop policy
values are derived by taking the average of those hop polices. For the
case where there are no real hops (in other words, we are the
introduction node), we use the default policy values used for normal
ChannelUpdates but then for the MaxHTLC value, we take the average of
all our open channel capacities.
Setting default values for the channel opening fee rate is already
done elsewhere therefore we remove on of those checks and return
an error if no fee rate is specified.
Add an itest that tests the addition of dummy hops to a blinded path. By
testing that invoices containing such a path can be paid, it also tests
the peeling of dummy hops by the receiver.
Make various sender side adjustments so that a sender is able to send an
MP payment to a single blinded path without actually including an MPP
record in the payment.
Update one of the route blinding itests to do a full end-to-end test
where the recipient generates and invoice with a blinded path and the
sender just provides that invoice to SendPayment.
The tests also covers the edge case where the recipient is the
introduction node.
