-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Fix TimeStamp issue in the Gossip Syncer #9011
Fix TimeStamp issue in the Gossip Syncer #9011
Conversation
Important Review skippedAuto reviews are limited to specific labels. Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
6905143
to
f1005e7
Compare
Still need to add unit tests probably, let's see whether the ci fails. |
channeldb/graph.go
Outdated
// NOTE: In the past we used to resurrect zombie | ||
// channels based on the timestamp value | ||
// included in the `ReplyChannelRange` msg, | ||
// however this is too risky because there is no | ||
// proof that the peer has an `ChanUpdate` msg | ||
// with this timestamp or could even just lie to | ||
// us. Therefore to resurrect zombie channel we | ||
// have to receive the actual `ChanUpdate` msg. | ||
if isZombie { |
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.
See https://github.com/lightningnetwork/lnd/pull/8030/files#r1394730858.
I flagged this potential issue on the previous PR, and @ellemouton explained that we need zombies to be marked live before the channel announcement comes. Since we're reverting that change, we should make sure channel announcements are still handled correctly.
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.
Hmm thinking about it twice and reading through the thread of the prior issue, I think we can somehow rely on the timestamp in resurrecting the zombie channels, however we should probably built in some banning protection if the peer promises a ChanUpdate with a specific timestamp but is not sending it.
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.
The query msges, at least the range queries built on trust anyways so having a proper banning system in place is more important rather than not trusting the data in the first place ?
So building back ...
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.
Just want to point out that resurrecting a zombie channel just means removing it from the index and not inserting it into the edgeIndexBucket
. So I think we can keep it?
f1005e7
to
1aee909
Compare
if we use %x here we would get the hex representation of the String() method of the vertex, which is wrong.
2ba4627
to
905cb17
Compare
channeldb/graph.go
Outdated
} | ||
|
||
// isSkewed returns whether the timestamp is too far into the future. | ||
isSkewed := func(timestamp time.Time) bool { |
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.
Maybe some services rely on setting the chanupdate far in the future to not have to update gossip very often ?
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.
perhaps but I think they should not be allowed to do this (according to the spec too iirc) & so we should not need to accommodate for that behaviour
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.
Great find - thanks for this! 🙏 ⌛
channeldb/graph.go
Outdated
Node1UpdateTimestamp: time.Unix(0, 0), | ||
Node2UpdateTimestamp: time.Unix(0, 0), |
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.
👍 great catch
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.
perhaps we should add a NewChannelUpdateInfo
constructor so that this is done by default & we dont need to remember to do it?
// However we should start punishing peers when | ||
// they don't provide us honest data ? |
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.
yeah ideally but it is tricky because:
- we query them by channel ID so it could be that by the time they reply, they have a new channel update and so will send that new one & so timestamp will not match (but at least should be greater than old one).
- Where we currently send this query and where we receive the requested messages is completely disjoint at the moment. So will require some coupling between this and the gossiper.
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.
We could do strict validation for every p2p message. In some cases it's useful, in some cases it's not. I'm not totally convinced that we should add logic for this unless not doing so presents a real problem.
channeldb/graph.go
Outdated
} | ||
|
||
// isSkewed returns whether the timestamp is too far into the future. | ||
isSkewed := func(timestamp time.Time) bool { |
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.
perhaps but I think they should not be allowed to do this (according to the spec too iirc) & so we should not need to accommodate for that behaviour
channeldb/graph_test.go
Outdated
@@ -1942,10 +1942,23 @@ func TestFilterKnownChanIDs(t *testing.T) { | |||
|
|||
// If we try to filter out a set of channel ID's before we even know of | |||
// any channels, then we should get the entire set back. | |||
currentTimeStamp := time.Now() |
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.
style nit: should squash this commit into the commit that changes the behaviour (ie, where the unit tests starts failing)
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 squashed the logic change into one commit because changes were all in the same file.
8b13935
to
fce74f2
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.
looks good
cf122e0
to
a46b8d2
Compare
ChanUpdate timestamps are now restircted so that they cannot be more than two weeks into the future. Moreover channels with both timestamps in the ReplyChannelRange msg either too far in the past or too far in the future are not queried. Moreover fix unitests.
Describe why it is ok to resurrect zombie channels based on the timestamp of the `ReplyChannelRange` msg although its not verifiable data.
a46b8d2
to
fc5b763
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.
LGTM 🪢
Fixes parts of #8889 especially nr. 1-3 in comment #8889 (comment)
The last commit introduces a check to not query channel which have outdated timestamp data. However I think we should also implement
encoded_query_flags
of thequery_short_channel_ids
msg. Meaning that we query for specific msg and therefore anticipate the correct msg from the peer. If the peer cannot send us a ChanUpdate although he claimed to have sone with a specific timestamp in theRangeReply
which should probably punish him ?