Gossip filtration fix #3390

arik-so · 2024-10-31T05:10:48Z

Previously, upon receipt of a GossipTimestampFilter message, we would immediately start unloading the entire network graph on our unsuspecting peer.

This PR modifies our behavior to only do so if the timestamp of the filter message is at least an hour old. Otherwise, we only send updated sync data as it comes in.

TheBlueMatt · 2024-10-31T15:59:18Z

lightning/src/ln/peer_handler.rs

+								(f.first_timestamp, f.first_timestamp.saturating_add(f.timestamp_range))
+							});
+
+							if msg.contents.timestamp >= min && msg.contents.timestamp <= max {


You'll need to apply the same in NodesSyncing handling below.

TheBlueMatt · 2024-10-31T16:04:01Z

lightning/src/ln/peer_handler.rs

+							});
+
+							if msg.contents.timestamp >= min && msg.contents.timestamp <= max {
+								self.enqueue_message(peer, &msg);


Hmm, this now results in us sending node_announcements for nodes for which we didn't send the requisite channel_announcements :/. Maybe its fine, but I'm kinda inclined to just skip all historical state for a peer that sends us a time more recent than now - an hour and otherwise give them a full dump.

the delivery order notwithstanding, don't you think the update timestamps are typically more likely to be higher than their corresponding node announcements' timestamps, meaning that it would be less likely to see a node announcement without a channel announcement than vice versa?

I'm also a bit reluctant to continue bombarding peers with gossip when they're explicitly requesting not to

don't you think the update timestamps are typically more likely to be higher than their corresponding node announcements' timestamps, meaning that it would be less likely to see a node announcement without a channel announcement than vice versa?

Not particularly? Both are generally on a timer, they may be independent timers.

I'm also a bit reluctant to continue bombarding peers with gossip when they're explicitly requesting not to

I don't think I suggested that. Rather, I suggested just skipping historical state sync entirely if we're gonna filter a material number of channels.

Per this suggestion, I replaced all changes with one additional check upon receipt of the timestamp filter message, determining if the requested range started more than an hour ago. Based on that, it flips between either a full sync or new gossip relay only.

Just resurfacing this in case it went under @TheBlueMatt. All other comments should be obsolete if we simply go with the modified behavior of checking whether the requested filter's timestamp was more than an hour ago.

Based on that, it flips between either a full sync or new gossip relay only.

Reading the following comment to try to understand how gossip_timestamp_filter works.

rust-lightning/lightning/src/routing/gossip.rs

Lines 650 to 663 in 0c31021

// Once you opt into "gossip queries" the only way to receive any gossip updates that a

// peer receives after you connect, you must send a `gossip_timestamp_filter` message. This

// message, as the name implies, tells the peer to not forward any gossip messages with a

// timestamp older than a given value (not the time the peer received the filter, but the

// timestamp in the update message, which is often hours behind when the peer received the

// message).

//

// Obnoxiously, `gossip_timestamp_filter` isn't *just* a filter, but its also a request for

// your peer to send you the full routing graph (subject to the filter). Thus, in order to

// tell a peer to send you any updates as it sees them, you have to also ask for the full

// routing graph to be synced. If you set a timestamp filter near the current time, peers

// will simply not forward any new updates they see to you which were generated some time

// ago (which is not uncommon). If you instead set a timestamp filter near 0 (or two weeks

// ago), you will always get the full routing graph from all your peers.

IIUC, it seems with this PR we either send the full dump or not based on the timestamp. And if the newly added check doesn't pass, we won't send any gossip. It doesn't seem to be the case that we'd even relay new gossip. This is because should_forward_channel_announcement and should_forward_node_announcement will return false when sent_gossip_timestamp_filter is false.

jkczyz · 2024-10-31T19:50:20Z

lightning/src/ln/peer_handler.rs

 							if let Some(update_a) = update_a_option {
-								self.enqueue_message(peer, &update_a);
+								if update_a.contents.timestamp >= min && update_a.contents.timestamp <= max {
+									if !has_enqueued_announcement {


Won't this always evaluate to true?

Because has_enqueued_announcement is initialized to false and never modified before reaching this line. The variable is actually only used to prevent enqueuing the announcement more than once. The reason given in the comment above is really covered by the let if let Some(update_a|b) checks.

ah, I thought you were referring to the timestamp range. Yes, good point

jkczyz · 2024-10-31T19:53:18Z

lightning/src/ln/peer_handler.rs

 							if let Some(update_a) = update_a_option {
-								self.enqueue_message(peer, &update_a);
+								if update_a.contents.timestamp >= min && update_a.contents.timestamp <= max {


Should be < max according to BOLT7. Likewise below.

codecov · 2024-11-07T15:40:31Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.45%. Comparing base (8da30df) to head (e5f9a11).
Report is 16 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3390      +/-   ##
==========================================
+ Coverage   89.61%   90.45%   +0.84%     
==========================================
  Files         129      130       +1     
  Lines      105506   113427    +7921     
  Branches   105506   113427    +7921     
==========================================
+ Hits        94544   102596    +8052     
+ Misses       8208     8110      -98     
+ Partials     2754     2721      -33

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚨 Try these New Features:

Flaky Tests Detection - Detect and resolve failed and flaky tests

lightning/src/ln/peer_handler.rs

jkczyz · 2024-11-20T23:33:40Z

lightning/src/ln/peer_handler.rs

+							});
+
+							if msg.contents.timestamp >= min && msg.contents.timestamp <= max {
+								self.enqueue_message(peer, &msg);


Based on that, it flips between either a full sync or new gossip relay only.

Reading the following comment to try to understand how gossip_timestamp_filter works.

rust-lightning/lightning/src/routing/gossip.rs

Lines 650 to 663 in 0c31021

// Once you opt into "gossip queries" the only way to receive any gossip updates that a

// peer receives after you connect, you must send a `gossip_timestamp_filter` message. This

// message, as the name implies, tells the peer to not forward any gossip messages with a

// timestamp older than a given value (not the time the peer received the filter, but the

// timestamp in the update message, which is often hours behind when the peer received the

// message).

//

// Obnoxiously, `gossip_timestamp_filter` isn't *just* a filter, but its also a request for

// your peer to send you the full routing graph (subject to the filter). Thus, in order to

// tell a peer to send you any updates as it sees them, you have to also ask for the full

// routing graph to be synced. If you set a timestamp filter near the current time, peers

// will simply not forward any new updates they see to you which were generated some time

// ago (which is not uncommon). If you instead set a timestamp filter near 0 (or two weeks

// ago), you will always get the full routing graph from all your peers.

IIUC, it seems with this PR we either send the full dump or not based on the timestamp. And if the newly added check doesn't pass, we won't send any gossip. It doesn't seem to be the case that we'd even relay new gossip. This is because should_forward_channel_announcement and should_forward_node_announcement will return false when sent_gossip_timestamp_filter is false.

arik-so · 2024-11-21T17:23:28Z

And if the newly added check doesn't pass, we won't send any gossip.

I have split the check in two to address that, @jkczyz.

jkczyz

LGTM. May want to add a test as mentioned offline. Also, would be good to document InitSyncTracker as otherwise you need to read the code to figure out the behavior.

TheBlueMatt reviewed Oct 31, 2024

View reviewed changes

jkczyz reviewed Oct 31, 2024

View reviewed changes

Trigger full sync on old GossipTimestampFilter

3854be0

arik-so force-pushed the gossip-filtration-fix branch from 268ecea to 3854be0 Compare November 15, 2024 21:41

jkczyz reviewed Nov 20, 2024

View reviewed changes

f: Move threshold check inside filter verification check

e5f9a11

arik-so force-pushed the gossip-filtration-fix branch from 47f4228 to e5f9a11 Compare November 21, 2024 16:25

jkczyz reviewed Nov 22, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Gossip filtration fix #3390

Gossip filtration fix #3390

arik-so commented Oct 31, 2024 •

edited

Loading

TheBlueMatt Oct 31, 2024

TheBlueMatt Oct 31, 2024

arik-so Oct 31, 2024

arik-so Oct 31, 2024

TheBlueMatt Nov 7, 2024

arik-so Nov 16, 2024

arik-so Nov 19, 2024

jkczyz Nov 20, 2024

jkczyz Oct 31, 2024

arik-so Oct 31, 2024

jkczyz Oct 31, 2024 •

edited

Loading

arik-so Oct 31, 2024

jkczyz Oct 31, 2024

codecov bot commented Nov 7, 2024 •

edited

Loading

jkczyz Nov 20, 2024

arik-so commented Nov 21, 2024

jkczyz left a comment

	// Once you opt into "gossip queries" the only way to receive any gossip updates that a
	// peer receives after you connect, you must send a `gossip_timestamp_filter` message. This
	// message, as the name implies, tells the peer to not forward any gossip messages with a
	// timestamp older than a given value (not the time the peer received the filter, but the
	// timestamp in the update message, which is often hours behind when the peer received the
	// message).
	//
	// Obnoxiously, `gossip_timestamp_filter` isn't just a filter, but its also a request for
	// your peer to send you the full routing graph (subject to the filter). Thus, in order to
	// tell a peer to send you any updates as it sees them, you have to also ask for the full
	// routing graph to be synced. If you set a timestamp filter near the current time, peers
	// will simply not forward any new updates they see to you which were generated some time
	// ago (which is not uncommon). If you instead set a timestamp filter near 0 (or two weeks
	// ago), you will always get the full routing graph from all your peers.

Gossip filtration fix #3390

Are you sure you want to change the base?

Gossip filtration fix #3390

Conversation

arik-so commented Oct 31, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkczyz Oct 31, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov bot commented Nov 7, 2024 • edited Loading

Codecov Report

Choose a reason for hiding this comment

arik-so commented Nov 21, 2024

jkczyz left a comment

Choose a reason for hiding this comment

arik-so commented Oct 31, 2024 •

edited

Loading

jkczyz Oct 31, 2024 •

edited

Loading

codecov bot commented Nov 7, 2024 •

edited

Loading