This commit extends our healtcheck with an optional leader check. This
is to ensure that given network partition or other cluster wide failure
we act as soon as possible to avoid a split-brain situation where a new
leader is elected but we still hold onto our etcd client.
Previously our RPC calls to etcd would hang even in the case of properly
set dial timeouts and even if there was a network partition. To ensure
liveness we need to make sure that calls fail correctly in case of
system failure. To fix this we add a default timeout of 30 seconds to
each etcd RPC call.
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.
Continue adding some complexity behind the BlindedPaymentPathSet. What
we do here is add a new IntroNodeOnlyPath method. The assumption we
make here is: If multiple blinded paths are provided to us in an invoice
but one of those paths only includes an intro node, then there is no
point in looking at any other path since we know that the intro node is
the destination node. So in such a case, we would have discarded any
other path in the `NewBlindedPaymentPathSet` constructor. So then we
would only have a single blinded path made up of an introduction node
only. In this specific case, in the `newRoute` function, no edge passed
to the function would have a blindedPayment associated with it (since
there are no blinded hops in this case). So we will have a case where
`blindedPathSet` passed to `newRoute` is not nil but `blindedPayment` is
nil since nonce was extacted from any edge. If this happens then we can
assume that this is the Intro-Node-Only situation described above. And
so we grabe the associated payment from the path set.
Instead of needing to remember how to handle the FinalCLTV value of a
blinded payment path at various points in the code base, we hide the
logic behind a unified FinalCLTVDelta method on the blinded path.
If multiple blinded paths are provided, they will each have a different
pub key for the destination node. This makes using our existing
pathfinding logic tricky since it depends on having a single destination
node (characterised by a single pub key). We want to re-use this logic.
So what we do is swap out the pub keys of the destinaion hop with a
pseudo target pub key. This will then be used during pathfinding. Later
on once a path is found, we will swap the real destination keys back in
so that onion creation can be done.
This commit introduces a new type, `BlindedPaymentPathSet`. For now, it
holds only a single `BlindedPayment` but eventually it will hold and
manage a set of blinded payments provided for a specific payment. To
make the PR easier to follow though, we start off just letting it hold a
single one and do some basic replacements.
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.
