From fce8bab931674a81a9ea895c9e9162e559e48a65 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Tue, 9 Apr 2024 05:48:17 +0930 Subject: [PATCH] BOLT 9: Assume gossip_queries. Supported by all but 11 nodes*. Signed-off-by: Rusty Russell [* there are 449 three-year old LND nodes which advertize `2200` as their features, which have already been trimmed from most gossip for not having htlc_maximum_msat in their channel_updates] --- 07-routing-gossip.md | 56 ++++++++++++++------------------------------ 09-features.md | 4 ++-- 2 files changed, 20 insertions(+), 40 deletions(-) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index 5afa4c049..b4ebe7d90 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -576,9 +576,11 @@ be present, so `must_be_one` is a constant value, and ignored by receivers. ## Query Messages -Negotiating the `gossip_queries` option via `init` enables a number -of extended queries for gossip synchronization. These explicitly -request what gossip should be received. +Understanding of messages used to be indicated with the `gossip_queries` +feature bit; now these messages are universally supported, that feature has +now been slightly repurposed. Not offering this feature means a node is not +worth querying for gossip: either they do not store the entire gossip map, or +they are only connected to a single peer (this one). There are several messages which contain a long array of `short_channel_id`s (called `encoded_short_ids`) so we include an encoding byte @@ -602,7 +604,7 @@ Nodes can signal that they support extended gossip queries with the `gossip_quer ### The `query_short_channel_ids`/`reply_short_channel_ids_end` Messages -1. type: 261 (`query_short_channel_ids`) (`gossip_queries`) +1. type: 261 (`query_short_channel_ids`) 2. data: * [`chain_hash`:`chain_hash`] * [`u16`:`len`] @@ -628,7 +630,7 @@ Nodes can signal that they support extended gossip queries with the `gossip_quer Query flags must be minimally encoded, which means that one flag will be encoded with a single byte. -1. type: 262 (`reply_short_channel_ids_end`) (`gossip_queries`) +1. type: 262 (`reply_short_channel_ids_end`) 2. data: * [`chain_hash`:`chain_hash`] * [`byte`:`full_information`] @@ -643,6 +645,7 @@ from `reply_channel_range`. #### Requirements The sender: + - SHOULD NOT send this to a peer which does not offer `gossip_queries`. - MUST NOT send `query_short_channel_ids` if it has sent a previous `query_short_channel_ids` to this peer and not received `reply_short_channel_ids_end`. - MUST set `chain_hash` to the 32-byte hash that uniquely identifies the chain that the `short_channel_id`s refer to. @@ -712,7 +715,7 @@ timeouts. It also causes a natural ratelimiting of queries. ### The `query_channel_range` and `reply_channel_range` Messages -1. type: 263 (`query_channel_range`) (`gossip_queries`) +1. type: 263 (`query_channel_range`) 2. data: * [`chain_hash`:`chain_hash`] * [`u32`:`first_blocknum`] @@ -734,7 +737,7 @@ timeouts. It also causes a natural ratelimiting of queries. Though it is possible, it would not be very useful to ask for checksums without asking for timestamps too: the receiving node may have an older `channel_update` with a different checksum, asking for it would be useless. And if a `channel_update` checksum is actually 0 (which is quite unlikely) it will not be queried. -1. type: 264 (`reply_channel_range`) (`gossip_queries`) +1. type: 264 (`reply_channel_range`) 2. data: * [`chain_hash`:`chain_hash`] * [`u32`:`first_blocknum`] @@ -783,6 +786,7 @@ This allows querying for channels within specific blocks. #### Requirements The sender of `query_channel_range`: + - SHOULD NOT send this to a peer which does not offer `gossip_queries`. - MUST NOT send this if it has sent a previous `query_channel_range` to this peer and not received all `reply_channel_range` replies. - MUST set `chain_hash` to the 32-byte hash that uniquely identifies the chain that it wants the `reply_channel_range` to refer to @@ -829,16 +833,15 @@ The addition of timestamp and checksum fields allow a peer to omit querying for ### The `gossip_timestamp_filter` Message -1. type: 265 (`gossip_timestamp_filter`) (`gossip_queries`) +1. type: 265 (`gossip_timestamp_filter`) 2. data: * [`chain_hash`:`chain_hash`] * [`u32`:`first_timestamp`] * [`u32`:`timestamp_range`] This message allows a node to constrain future gossip messages to -a specific range. A node which wants any gossip messages would have -to send this, otherwise `gossip_queries` negotiation means no gossip -messages would be received. +a specific range. A node which wants any gossip messages has +to send this, otherwise no gossip messages would be received. Note that this filter replaces any previous one, so it can be used multiple times to change the gossip from a peer. @@ -848,6 +851,8 @@ multiple times to change the gossip from a peer. The sender: - MUST set `chain_hash` to the 32-byte hash that uniquely identifies the chain that it wants the gossip to refer to. + - If the receiver does not offer `gossip_queries`: + - SHOULD set `first_timestamp` to 0xFFFFFFFF and `timestamp_range` to 0. The receiver: - SHOULD send all gossip messages whose `timestamp` is greater or @@ -898,26 +903,10 @@ Note that the `initial_routing_sync` feature is overridden (and should be considered equal to 0) by the `gossip_queries` feature if the latter is negotiated via `init`. -Note that `gossip_queries` does not work with older nodes, so the -value of `initial_routing_sync` is still important to control -interactions with them. - ### Requirements A node: - - if the `gossip_queries` feature is negotiated: - - 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. - - upon receiving an `init` message with the `initial_routing_sync` flag set to - 1: - - SHOULD send gossip messages for all known channels and nodes, as if they were just - received. - - if the `initial_routing_sync` flag is set to 0, OR if the initial sync was - completed: - - SHOULD resume normal operation, as specified in the following - [Rebroadcasting](#rebroadcasting) section. + - MUST NOT relay any gossip messages it did not generate itself, unless explicitly requested. ## Rebroadcasting @@ -937,8 +926,7 @@ A receiving node: for its peers. A node: - - if the `gossip_queries` feature is negotiated: - - MUST not send gossip it did not generate itself, 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 @@ -947,9 +935,6 @@ A node: and did not specify the `chain_hash` of this gossip message. - MAY re-announce its channels regularly. - Note: this is discouraged, in order to keep the resource requirements low. - - upon connection establishment: - - SHOULD send all `channel_announcement` messages, followed by the latest - `node_announcement` AND `channel_update` messages. ### Rationale @@ -960,11 +945,6 @@ regular intervals; such a store-and-delayed-forward broadcast is called a _staggered broadcast_. Also, such batching forms a natural rate limit with low overhead. -The sending of all gossip on reconnection is naive, but simple, -and allows bootstrapping for new nodes as well as updating for nodes that -have been offline for some time. The `gossip_queries` option -allows for more refined synchronization. - ## HTLC Fees ### Requirements diff --git a/09-features.md b/09-features.md index 755fdf662..122ccd7f6 100644 --- a/09-features.md +++ b/09-features.md @@ -35,9 +35,9 @@ The Context column decodes as follows: | 0/1 | `option_data_loss_protect` | ASSUMED | | | | | 3 | `initial_routing_sync` | Sending node needs a complete routing information dump | I | | [BOLT #7][bolt07-sync] | | 4/5 | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel | IN | | [BOLT #2][bolt02-open] | -| 6/7 | `gossip_queries` | More sophisticated gossip control | IN | | [BOLT #7][bolt07-query] | +| 6/7 | `gossip_queries` | Peer has useful gossip to share | | | | | 8/9 | `var_onion_optin` | ASSUMED | | | | -| 10/11 | `gossip_queries_ex` | Gossip queries can include additional information | IN | `gossip_queries` | [BOLT #7][bolt07-query] | +| 10/11 | `gossip_queries_ex` | Gossip queries can include additional information | IN | | [BOLT #7][bolt07-query] | | 12/13 | `option_static_remotekey` | ASSUMED | | | | | 14/15 | `payment_secret` | Node supports `payment_secret` field | IN9 | | [Routing Onion Specification][bolt04] | | 16/17 | `basic_mpp` | Node can receive basic multi-part payments | IN9 | `payment_secret` | [BOLT #4][bolt04-mpp] |