mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-01-18 13:22:35 +01:00
Code Issues Projects Releases Wiki Activity

Gossip queries: sync complete is back (#826)

Browse Source 
We previously insisted that `reply_channel_range` messages were not
overlapping: blocks content could not be split across multiple messages.

This made it possible to implicitly figure out when sync was complete, so we
re-purposed the previous `complete` field to a `full_information` field.

We now revert that change to allow blocks to be split across multiple
messages. An explicit flag is thus needed to signal that sync is complete.

Fixes #804
This commit is contained in:
Bastien Teinturier 2021-02-15 21:37:06 +01:00 committed by GitHub
parent a5d4f33467
commit edd45ecf22
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
07-routing-gossip.md
View File

@ -723,7 +723,7 @@ Though it is possible, it would not be very useful to ask for checksums without
* [`chain_hash`:`chain_hash`]
* [`u32`:`first_blocknum`]
* [`u32`:`number_of_blocks`]
* [`byte`:`full_information`]
* [`byte`:`sync_complete`]
* [`u16`:`len`]
* [`len*byte`:`encoded_short_ids`]
* [`reply_channel_range_tlvs`:`tlvs`]
@ -762,7 +762,7 @@ Where:
The checksum of a `channel_update` is the CRC32C checksum as specified in [RFC3720](https://tools.ietf.org/html/rfc3720#appendix-B.4) of this `channel_update` without its `signature` and `timestamp` fields.
This allows to query for channels within specific blocks.
This allows querying for channels within specific blocks.
#### Requirements
@ -781,23 +781,21 @@ The receiver of `query_channel_range`:
- MUST set with `chain_hash` equal to that of `query_channel_range`,
- MUST limit `number_of_blocks` to the maximum number of blocks whose
results could fit in `encoded_short_ids`
- if does not maintain up-to-date channel information for `chain_hash`:
- MUST set `full_information` to 0.
- otherwise:
- SHOULD set `full_information` to 1.
- MAY split block contents across multiple `reply_channel_range`.
- the first `reply_channel_range` message:
- MUST set `first_blocknum` less than or equal to the `first_blocknum` in `query_channel_range`
- MUST set `first_blocknum` plus `number_of_blocks` greater than `first_blocknum` in `query_channel_range`.
- successive `reply_channel_range` message:
- MUST set `first_blocknum` to the previous `first_blocknum` plus `number_of_blocks`.
- MUST have `first_blocknum` equal or greater than the previous `first_blocknum`.
- MUST set `sync_complete` to `false` if this is not the final `reply_channel_range`.
- the final `reply_channel_range` message:
- MUST have `first_blocknum` plus `number_of_blocks` equal or greater than the `query_channel_range` `first_blocknum` plus `number_of_blocks`.
- MUST set `sync_complete` to `true`.
If the incoming message includes `query_option`, the receiver MAY append additional information to its reply:
- if bit 0 in `query_option_flags` is set, the receiver MAY append a `timestamps_tlv` that contains `channel_update` timestamps for all `short_chanel_id`s in `encoded_short_ids`
- if bit 1 in `query_option_flags` is set, the receiver MAY append a `checksums_tlv` that contains `channel_update` checksums for all `short_chanel_id`s in `encoded_short_ids`
#### Rationale
A single response might be too large for a single packet, so multiple replies