mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 01:50:03 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 9: Assume gossip_queries.

Browse Source 
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]
This commit is contained in:
Rusty Russell 2024-04-09 05:48:17 +09:30 committed by neil saitug
parent e042c615ef
commit fce8bab931
2 changed files with 20 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
07-routing-gossip.md
View File

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

4
09-features.md
View File

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