Skip to content

discovery: don't reply with historical updates to gossip filters#3315

Closed
cfromknecht wants to merge 3 commits intolightningnetwork:masterfrom
cfromknecht:no-historical-gossip-filter
Closed

discovery: don't reply with historical updates to gossip filters#3315
cfromknecht wants to merge 3 commits intolightningnetwork:masterfrom
cfromknecht:no-historical-gossip-filter

Conversation

@cfromknecht
Copy link
Contributor

This PR removes the existing behavior that responds with all known
updates when a remote peer sends a gossip_timestamp_filter. When a peer
sets this with a very old start timestamp, this can cause the local node
to dump the entire graph to the peer, which is functionally equivalent
to the original intitial_routing_sync feature. That feature was
deprecated because it is expensive and can force a node to use a
disproportionate amount of resources, especially on flapping
connections. Now, the filter is only applied to new gossip messages when
deciding whether or not to forward them to a particular peer.

@cfromknecht
Copy link
Contributor Author

This is an example of the changes proposed in lightning/bolts#641

@cfromknecht cfromknecht force-pushed the no-historical-gossip-filter branch 2 times, most recently from 84d4755 to a65fb18 Compare July 16, 2019 03:35
@cfromknecht
Copy link
Contributor Author

cfromknecht commented Jul 16, 2019

we may also be able to remove channeldb/channel_cache.go as its primary purpose is to reply to ChanUpdatesInHorizon, or possibly start using it to speed up the router.

This commit removes the existing behavior that responds with all known
updates when a remote peer sends a gossip_timestamp_filter. When a peer
sets this with a very old start timestamp, this can cause the local node
to dump the entire graph to the peer, which is functionally equivalent
to the original `intitial_routing_sync` feature. That feature was
deprecated because it is expensive and can force a node to use a
disproportionate amount of resources, especially on flapping
connections. Now, the filter is only applied to new gossip messages when
deciding whether or not to forward them to a particular peer.
This method can no longer fail since it doesn't interact with the db.
@cfromknecht cfromknecht force-pushed the no-historical-gossip-filter branch from a65fb18 to d31b6c7 Compare July 24, 2019 23:50
@wpaulino wpaulino added this to the 0.8.0 milestone Jul 25, 2019
@Roasbeef Roasbeef added dos/hardening Related to the resilience of LND against denial of service or other related attacks optimization P3 might get fixed, nice to have v0.8 discovery Peer and route discovery / whisper protocol related issues/PRs labels Jul 29, 2019
@wpaulino wpaulino removed the v0.8.0 label Jul 31, 2019
@wpaulino wpaulino removed this from the 0.8.0 milestone Jul 31, 2019
@cfromknecht cfromknecht added this to the 0.9 milestone Jul 31, 2019
@cfromknecht
Copy link
Contributor Author

parking this until 0.9 cycle, will be superceded by #3359 in the meantime

@wpaulino wpaulino removed request for halseth and wpaulino August 2, 2019 08:38
@joostjager joostjager removed the v0.9.0 label Oct 9, 2019
@joostjager joostjager removed this from the 0.9 milestone Oct 9, 2019
@Roasbeef
Copy link
Member

#3359 has been since merged, so I think this is no longer relevant?

@saubyk
Copy link
Collaborator

saubyk commented Sep 18, 2025

Closing due to inactivity.

@saubyk saubyk closed this Sep 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

discovery Peer and route discovery / whisper protocol related issues/PRs dos/hardening Related to the resilience of LND against denial of service or other related attacks optimization P3 might get fixed, nice to have

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants