In this commit, we modify our gossip broadcast logic to ensure that we
always will send out our own gossip messages regardless of the
filtering/feature policies of the peer.
Before this commit, it was possible that when we went to broadcast an
announcement, none of our peers actually had us as a syncer peer (lnd
terminology). In this case, the FilterGossipMsg function wouldn't do
anything, as they don't have an active timestamp filter set. When we go
to them merge the syncer map, we'd add all these peers we didn't send
to, meaning we would skip them when it came to broadcast time.
In this commit, we now split things into two phases: we'll broadcast
_our_ own announcements to all our peers, but then do the normal
filtering and chunking for the announcements we got from a remote peer.
Fixes https://github.com/lightningnetwork/lnd/issues/6531
Fixes https://github.com/lightningnetwork/lnd/issues/7223
Fixes https://github.com/lightningnetwork/lnd/issues/7073
This commit makes the `handleChanAnnouncement` always returning `true`
for messages processed but ignored by router, even when the extracted
announcements are empty.
Previously we'd return false when the announcements are empty, which
could cause `ChannelUpdate`s being ignored since the validation barrier
will signal deny for the jobs. This can easily be trigger using
following setup,
1. Alice connects to Bob and open a channel.
2. Alice connects to Carol, Bob connects to Carol.
3. Once the channel is open, Alice and Bob will both announce it to Carol.
At some point, we'd have the following messages in Carol's node,
- Alice's ChannelAnnouncement
- Alice's ChannelUpdates, for both directions
- Bob's ChannelAnnouncement
- Bob's ChannelUpdates, for both directions
And a bug could happen, if,
- Alice's ChannelAnnouncement is processed by router, hence added to db,
but not reporting back to gossiper yet, so the validation barrier
hasn't sent signal allow.
- Bob's ChannelAnnouncement is processed by router, and returned
`ErrIgnored` as the edge info is already in db, and reported back to
gossiper, the validation barrier will signal deny to all the
ChannelUpdates jobs.
- Depending on how fast Alice's ChannelAnnouncement is processed, we may
get zero to four denies to the above ChannelUpdates, causing a channel
edge policy never being updated.
This commit moves the `shouldBroadcast` logic closer to the execution
logic of deciding whether we want to broadcast the announcements. This
is a pure code refactor and should make no difference in announcing
message unless the `d.syncMgr.IsGraphSynced()` gives different results
inside the goroutine.
An OptionalMsgField has been added that allows outside subsystems
to provide a short channel id we should insert into a ChannelUpdate
that we then sign and send to our peer.
When the gossiper receives a ChannelUpdate, it will query the
alias manager by the passed-in FindBaseByAlias function to determine
if the short channel id in the ChannelUpdate points to a known
channel. If this lookup returns an error, we'll fallback to using
the original id in the ChannelUpdate when querying the router.
The lookup and potential fallback must occur in order to properly
lock the multimutex, query the correct router channels, and rate
limit the correct short channel id. An unfortunate side effect of
receiving ChannelUpdates from our peer that reference on of our
aliases rather than the real SCID is that we must store this policy.
Yet it is not broadcast-able. Care has been taken to ensure the
gossiper does not broadcast *any* ChannelUpdate with an alias SCID.
The cachedNetworkMsg uses the new processedNetworkMsg struct. This
is necessary so that delete-and-reinsert in the funding manager
doesn't process a ChannelUpdate twice and end up in a deadlock since
the err chan is no longer being used.
This commit was previously split into the following parts to ease
review:
- 2d746f68: replace imports
- 4008f0fd: use ecdsa.Signature
- 849e33d1: remove btcec.S256()
- b8f6ebbd: use v2 library correctly
- fa80bca9: bump go modules
This commit adds a method to resend premature when new blocks arrive.
Previously when a message has specified a block+delta in the future, we
would ignore the message and never process it again, causing an open
channel never being broadcast under fast blocks generation. This commit
fixes it by saving the future messages and resending them once the
required block height is reached.
This commit moves syncing blocks into a dedicated goroutine to avoid the
race condition where several go channels are ready and the block height
update is pushed after a network message is processed.
Turns out we need it right now to handle some low latency race
conditions in our integration tests, so we'll opt to simply cap the size
of it to a low amount. We use a basic LRU caching mechainsm.
Fixes https://github.com/lightningnetwork/lnd/issues/5076
To simplify the message signing API even further, we refactor the
lnwallet.MessageSigner interface to use a key locator instead of the
public key to identify which key should be signed with.
Adds an optional tx parameter to ForAllOutgoingChannels and FetchChannel
so that data can be queried within the context of an existing database
transaction.
This log can be "spammy" while nodes throughout the network have yet to
upgrade to v0.13.0-beta, which includes several enhancements to prevent
the broadcast of zombie edges/updates.
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
In order to be consistent with other sub systems an error is now
returned from the Stop functions.
This also allows writing a generic cleanup mechanism to stop all
sub systems in case of a failure.
Previously, we would always allow dependent jobs to be processed,
regardless of the result of its parent job's validation. This isn't
correct, as a parent job contains actions necessary to successfully
process a dependent job. A prime example of this can be found within the
AuthenticatedGossiper, where an incoming channel announcement and update
are both processed, but if the channel announcement job fails to
complete, then the gossiper is unable to properly validate the update.
This commit aims to address this by preventing the dependent jobs to
run.
The recently added gossip throttling was shown to be too aggressive,
especially with our auto channel enable/disable signaling. We switch to
a token bucket based system instead as it's based on time, rather than a
block height which isn't constantly updated at a given rate.
Since the batch interval can potentially be long, adding local updates
to the graph could be slow. This would slow down operations like adding
our own channel update and announcements during the funding process, and
updating edge policies for local channels.
Now we instead check whether the update is remote or not, and only for
remote updates use the SchedulerOption to lazily add them to the graph.
We do this instead of using the source of the AnnounceSignatures
message, as we filter out the source when broadcasting any
announcements, leading to the remote node not receiving our channel
update. Note that this is done more for the sake of correctness and to
address a flake within the integration tests, as channel updates are
sent directly and reliably to channel counterparts.
A pinned syncer is an ActiveSyncer that is configured to always remain
active for the lifetime of the connection. Pinned syncers do not count
towards the total NumActiveSyncer count, which are rotated periodically.
This features allows nodes to more tightly synchronize their routing
tables by ensuring they are always receiving gossip from distinguished
subset of peers.
