BOLT 9: Assume gossip_queries.

Supported by all but 11 nodes*.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
[* 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

@@ -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
+Understanding of messages used to be indicated with the `gossip_queries`
-of extended queries for gossip synchronization.  These explicitly
+feature bit; now these messages are universally supported, that feature has
-request what gossip should be received.
+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
+a specific range.  A node which wants any gossip messages has
-to send this, otherwise `gossip_queries` negotiation means no gossip
+to send this, otherwise no gossip messages would be received.
-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.
-    - 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.
 
 ## 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

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]                                                 |