-
Notifications
You must be signed in to change notification settings - Fork 379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gossip filtration fix #3390
Gossip filtration fix #3390
Conversation
lightning/src/ln/peer_handler.rs
Outdated
(f.first_timestamp, f.first_timestamp.saturating_add(f.timestamp_range)) | ||
}); | ||
|
||
if msg.contents.timestamp >= min && msg.contents.timestamp <= max { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll need to apply the same in NodesSyncing
handling below.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3390 +/- ##
==========================================
+ Coverage 89.61% 90.94% +1.33%
==========================================
Files 129 130 +1
Lines 105506 114915 +9409
Branches 105506 114915 +9409
==========================================
+ Hits 94544 104508 +9964
+ Misses 8208 7986 -222
+ Partials 2754 2421 -333 ☔ View full report in Codecov by Sentry. |
268ecea
to
3854be0
Compare
47f4228
to
e5f9a11
Compare
I have split the check in two to address that, @jkczyz. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
|
lightning/src/ln/peer_handler.rs
Outdated
use std::time::{SystemTime, UNIX_EPOCH}; | ||
full_sync_threshold = SystemTime::now().duration_since(UNIX_EPOCH).expect("Time must be > 1970").as_secs() - 6 * 3600; | ||
} | ||
if (msg.first_timestamp as u64) <= full_sync_threshold { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for non-std builds, full_sync_threshold
will be left unchanged to 0
, and we will never trigger a full gossip sync even if message contained now-2weeks ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my understanding is that for non-std builds, we rather always trigger a full gossip sync
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made the code a bit clearer for default no-std behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iiuc, it wouldn't have worked as expected earlier. lmk if that was not the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does what it says, and handles non-std behavior correctly.
Lgtm, unless other reviewers have more feedback!
lightning/src/ln/peer_handler.rs
Outdated
@@ -1724,10 +1733,26 @@ impl<Descriptor: SocketDescriptor, CM: Deref, RM: Deref, OM: Deref, L: Deref, CM | |||
if let wire::Message::GossipTimestampFilter(_msg) = message { | |||
// When supporting gossip messages, start initial gossip sync only after we receive | |||
// a GossipTimestampFilter | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: newline not required.
lightning/src/ln/peer_handler.rs
Outdated
#[cfg(feature = "std")] | ||
{ | ||
// if the timestamp range starts more than six hours ago, do a full sync | ||
// otherwise, start at the current time |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: "otherwise, do not send historical gossip."
lightning/src/ln/peer_handler.rs
Outdated
if peer_lock.their_features.as_ref().unwrap().supports_gossip_queries() && | ||
!peer_lock.sent_gossip_timestamp_filter { | ||
peer_lock.sent_gossip_timestamp_filter = true; | ||
peer_lock.sync_status = InitSyncTracker::ChannelsSyncing(0); | ||
|
||
#[allow(unused_mut, unused_assignments)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: unused_assignments
should no longer be required.
249cf2c
to
e582222
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presumably the second commit should be squashed as a fixup?
e582222
to
0247ad0
Compare
squashed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM other than re-wording a comment.
lightning/src/ln/peer_handler.rs
Outdated
// if the timestamp range starts more than six hours ago, do a full sync | ||
// otherwise, only forward ad-hoc gossip |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment would be less confusing if it was re-phrased to say "less than six hours ago" as that is the condition where should_do_full_sync
is modified below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eh, I think it's quite clear honestly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It describes the opposite of the if
clause as worded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about this phrasing I just pushed:
// determine if the timestamp range starts more than six hours ago
// if it doesn't, only forward ad-hoc gossip
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eh, I mean, I read the comment then see if the code does what it says, but I need to reverse the logic to determine that. Can't we just say: "Forward ad-hoc gossip if the timestamp range is less than six hours ago. Otherwise, do a full sync."?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oops, push had failed. Worked now
b7a7ef6
to
b350233
Compare
Current git commit message is confusing though. |
Would you like me to add an "only" to the commit message? Or rephrase it? |
anything is fine i guess, upto you |
b350233
to
a837f2b
Compare
ok, sure, I rephrased it |
Waiting on ci to merge. |
Previously, upon receipt of a GossipTimestampFilter message, we would immediately start unloading the entire network graph on our unsuspecting peer. This commit modifies our behavior to only do so if the timestamp of the filter message is at least six hour old. Otherwise, we only send updated sync data as it comes in.
a837f2b
to
145e1ab
Compare
Let's expanded the commit message with the why from the PR description, as discussed offline. |
hm, the expanded message seems to show up for me, maybe Github doesn't auto-refresh? |
There is a fuzz test failure for 'test_gossip_exchange_breakage', looks like it is related. |
I believe this is from #3439, working on a fix for this |
Sounds good, will merge this after ci completes in that case. |
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.