Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gossip queries: sync complete is back #826

Merged
merged 1 commit into from
Feb 15, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 6 additions & 8 deletions 07-routing-gossip.md
Original file line number Diff line number Diff line change
Expand Up @@ -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`]
Expand Down Expand Up @@ -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

Expand All @@ -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`.
Copy link
Contributor

@ysangkok ysangkok Feb 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is true/false in a byte typed value? 0x01 and 0x00?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably worth opening a PR to fix it, but, yes.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course, 0x01. Feel free to clarify if you feel it's needed.


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
Expand Down