Skip to content

RGS Update had same timestamp as last processed update shouldn't be an error #1746

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

Closed
TheBlueMatt opened this issue Sep 28, 2022 · 2 comments · Fixed by #1764
Closed

RGS Update had same timestamp as last processed update shouldn't be an error #1746

TheBlueMatt opened this issue Sep 28, 2022 · 2 comments · Fixed by #1764
Assignees
Labels
good first issue Good for newcomers

Comments

@TheBlueMatt
Copy link
Collaborator

See lightningdevkit/rapid-gossip-sync-server#17 but this just shouldn't be an error, we should probably try to apply anyway, though.

@G8XSU
Copy link
Contributor

G8XSU commented Oct 7, 2022

I will take this up,
BOLT: "MUST set timestamp to be greater than that of any previous node_announcement it has previously created."
And we should re-broadcast if new timestamp in received msg is greater.

Doubt: If we remove this check, we might apply and broadcast a few duplicate gossips. (non-rgs case)
is that fine?

Concern is when we receive same msg from multiple nodes.

@TheBlueMatt
Copy link
Collaborator Author

The timestamp here is the one set by the RGS server (roughly "when the snapshot was generated"), not one connected to network messages themselves, so there's no relevant BOLT requirements here.

G8XSU added a commit to G8XSU/rust-lightning that referenced this issue Oct 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants