The previous behavior would allow updates to be overwritten in some
scenarios. Upon restart, this would lead to a missing settle/fail in
the update logs.
In this commit, we update the existing zombie resurrection test to
ensure that if we prune an edge and another pubkey is marked as nil,
that we only accept a resurrection channel update from the node the we
originally pruned if the pruning decision was one sided.
In this commit we add a new flag that controls if lnd will do strict
zombie pruning or not. If true, then this will cause lnd to maintain a
tighter graph as it wants both edges to always be live. We enable this by
default for neutrino as without this, it's possible that a node never
sees both edges begin disabled, so those edges are never actually pruned
from the graph.
In this commit, we add strict zombie pruning as a config level param.
This allow us to add the option for those that want a tighter graph, and
not change the default composition of the channel graph for most users
over night.
In addition, we expand the test case slightly by testing that the self
node won't be pruned, but also that if there's a node with only a single
known stale edge, then both variants will prune that edge.
In this commit, we upgrade to the latest version of `btcwallet` that
fixes an alignment issue with usage of atomics that can cause a panic on
certain systems.
Fixes#5196.
In this commit, we make a change to always add chan announcements to the
reject cache if we didn't reject them for already existing. Without
this change, if we end up rejecting a channel announcement say because
the channel is already spent or the funding transaction doesn't exist,
then we'll end up continually re-validating the same set of channels we
know will fail, when they're sent to us by peers.
Fixes#5191
A stray version of lnd was pushed out waaaay back in 2016 that can trip
up `pkg.go.dev` and things like `go get`. Using the new Go 1.16 feature,
we can now "retract" this version, which marks it as being unavailable.
Without this check, it's possible to send a probe HTLC w/ a valid
payment address but invalid payment hash that gets settled. Because
there was no assertion that the HTLC's payment hash matches the
invoice, the link would fail when it receives an invalid preimage for
the HTLC on its commitment.
Add a dust-limit to `CoinSelect` and let the fee estimation consider if a change output is needed or not, assuring that if the change is below the dust-limit it will go towards the fee instead.
