Skip to content

BOLT07: don't send historical updates for gossip_timestamp_filter #641

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.

Sign up for GitHub

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
cfromknecht wants to merge 1 commit into from
Closed

BOLT07: don't send historical updates for gossip_timestamp_filter #641

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 0 additions & 4 deletions 07-routing-gossip.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -698,10 +698,6 @@ The sender:
that it wants the gossip to refer to.

The receiver:
- SHOULD send all gossip messages whose `timestamp` is greater or
equal to `first_timestamp`, and less than `first_timestamp` plus
`timestamp_range`.
- MAY wait for the next outgoing gossip flush to send these.
Copy link
Copy Markdown
Contributor

@wpaulino wpaulino Jul 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SHOULD send all gossip messages whose timestamp is greater or
equal to first_timestamp, and less than first_timestamp plus
timestamp_range.

This still seems like something we'd want to keep. Perhaps it's better to note that implementations should be aware of the consequences of setting first_timestamp to a value too far in the past?

Copy link
Copy Markdown
Collaborator Author

@cfromknecht cfromknecht Jul 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still seems like something we'd want to keep.

Why? The whole point of moving to gossip_queries was to avoid dumping the full channel graph on every connection, and you can't really make use of this without triggering it. Maybe it should be changed to MAY rather than SHOULD?

Perhaps it's better to note that implementations should be aware of the consequences of setting first_timestamp to a value too far in the past?

We want to be able to set timestamps in the past, that way we catch new updates arriving at tip that may be slow to propagate due to the staggered gossip. You could say that then we shouldn't set it too far back, but how do we arrive at that value.

It becomes harder to pick a value when some nodes send historical traffic and others don't. You have to choose a balance between DOSing the remote node and forcing yourself to filter out a mound of gossip data, or just accept the loss and miss out on slow-to-propagate updates.

Copy link
Copy Markdown
Collaborator Author

@cfromknecht cfromknecht Jul 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also with extended_gossip_queries I think it makes this functionality redundant, and we should encourage people to get missing data through that rather dumping the graph

Copy link
Copy Markdown
Collaborator

@rustyrussell rustyrussell Jul 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you really want a complete gossip blast, you can always reconnect. Generally asking for everything to be re-transmitted is a bit antisocial.

- SHOULD restrict future gossip messages to those whose `timestamp`
is greater or equal to `first_timestamp`, and less than
`first_timestamp` plus `timestamp_range`.
Expand Down