From 9fef80507916e5af82d6b297b3824c9d3383daa0 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Mon, 14 Oct 2019 13:59:23 +1030 Subject: [PATCH] BOLT 7: be more aggressive about sending our own gossip. As more nodes on the network use timestamp_filter to block gossip floods, we've seen some propagation problems. This should avoid it (and is implemented now by c-lightning). Signed-off-by: Rusty Russell --- 07-routing-gossip.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index 6ae579d8a..68eaa8ff6 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -828,9 +828,11 @@ The receiver: equal to `first_timestamp`, and less than `first_timestamp` plus `timestamp_range`. - MAY wait for the next outgoing gossip flush to send these. - - SHOULD restrict future gossip messages to those whose `timestamp` - is greater or equal to `first_timestamp`, and less than - `first_timestamp` plus `timestamp_range`. + - SHOULD send gossip messages as it generates them regardless of `timestamp`. + - Otherwise (relayed gossip): + - SHOULD restrict future gossip messages to those whose `timestamp` + is greater or equal to `first_timestamp`, and less than + `first_timestamp` plus `timestamp_range`. - If a `channel_announcement` has no corresponding `channel_update`s: - MUST NOT send the `channel_announcement`. - Otherwise: @@ -855,6 +857,12 @@ is simple to implement. In the case where the `channel_announcement` is nonetheless missed, `query_short_channel_ids` can be used to retrieve it. +Nodes can use `timestamp_filter` to reduce their gossip load when they +have many peers (eg. setting `first_timestamp` to `0xFFFFFFFF` after the +first few peers, in the assumption that propagation is adequate). +This assumption of adequate propagation does not apply for gossip messages +generated directly by the node itself, so they should ignore filters. + ## Initial Sync If a node requires an initial sync of gossip messages, it will be flagged @@ -872,7 +880,7 @@ interactions with them. A node: - if the `gossip_queries` feature is negotiated: - - MUST NOT relay any gossip messages unless explicitly requested. + - MUST NOT relay any gossip messages it did not generate itself, unless explicitly requested. - otherwise: - if it requires a full copy of the peer's routing state: - SHOULD set the `initial_routing_sync` flag to 1. @@ -904,7 +912,7 @@ A receiving node: A node: - if the `gossip_queries` feature is negotiated: - - MUST not send gossip until it receives `gossip_timestamp_filter`. + - MUST not send gossip it did not generate itself, until it receives `gossip_timestamp_filter`. - SHOULD flush outgoing gossip messages once every 60 seconds, independently of the arrival times of the messages. - Note: this results in staggered announcements that are unique (not