Merged
Conversation
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
18 tasks
|
LGTM. Should we consider adding an error TLV to cover the intent of |
16 tasks
Collaborator
|
LGTM! In retrospect not having an explicit |
t-bast
added a commit
to ACINQ/eclair
that referenced
this pull request
Jan 7, 2021
We are restoring the previous behavior of using the `sync_complete` field to signal the end of a `channel_range_query` sync. The first step is to correctly set that field, before we can read it and interpret it to mark the end of sync. See lightning/bolts#826
This was referenced Jan 7, 2021
Collaborator
|
Ack: this won't break anything worse than it is now. We might get upset and send an error if the final block is split, so I'll fix that now. |
21 tasks
t-bast
added a commit
to ACINQ/eclair
that referenced
this pull request
Feb 4, 2021
We are restoring the previous behavior of using the `sync_complete` field to signal the end of a `channel_range_query` sync. The first step is to correctly set that field, before we can read it and interpret it to mark the end of sync. See lightning/bolts#826
23 tasks
t-bast
added a commit
to ACINQ/eclair
that referenced
this pull request
Feb 15, 2021
We are restoring the previous behavior of using the `sync_complete` field to signal the end of a `channel_range_query` sync. The first step is to correctly set that field, before we can read it and interpret it to mark the end of sync. See lightning/bolts#826
Collaborator
Author
|
Merging as agreed during the spec meeting (#840) |
ysangkok
reviewed
Feb 15, 2021
| - 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`. |
Contributor
There was a problem hiding this comment.
what is true/false in a byte typed value? 0x01 and 0x00?
Collaborator
There was a problem hiding this comment.
Probably worth opening a PR to fix it, but, yes.
Collaborator
Author
There was a problem hiding this comment.
Of course, 0x01. Feel free to clarify if you feel it's needed.
rustyrussell
added a commit
to rustyrussell/lightning
that referenced
this pull request
Feb 18, 2021
We assume if they set this to 0 (which nobody did previously), they're using it as a modern flag and use it to indicate when they're finished. Otherwise, we count how many blocks they've sent and use that to determine whether they've finished. See: lightning/bolts#826 Signed-off-by: Rusty Russell <[email protected]> Changelog-Changed: Protocol: we use `sync_complete` for gossip range query replies, with detection for older spec nodes.
rustyrussell
added a commit
to rustyrussell/lightning
that referenced
this pull request
Feb 22, 2021
We assume if they set this to 0 (which nobody did previously), they're using it as a modern flag and use it to indicate when they're finished. Otherwise, we count how many blocks they've sent and use that to determine whether they've finished. See: lightning/bolts#826 Signed-off-by: Rusty Russell <[email protected]> Changelog-Changed: Protocol: we use `sync_complete` for gossip range query replies, with detection for older spec nodes.
rustyrussell
added a commit
to rustyrussell/lightning
that referenced
this pull request
Feb 23, 2021
We assume if they set this to 0 (which nobody did previously), they're using it as a modern flag and use it to indicate when they're finished. Otherwise, we count how many blocks they've sent and use that to determine whether they've finished. See: lightning/bolts#826 Signed-off-by: Rusty Russell <[email protected]> Changelog-Changed: Protocol: we use `sync_complete` for gossip range query replies, with detection for older spec nodes.
rustyrussell
added a commit
to ElementsProject/lightning
that referenced
this pull request
Feb 25, 2021
We assume if they set this to 0 (which nobody did previously), they're using it as a modern flag and use it to indicate when they're finished. Otherwise, we count how many blocks they've sent and use that to determine whether they've finished. See: lightning/bolts#826 Signed-off-by: Rusty Russell <[email protected]> Changelog-Changed: Protocol: we use `sync_complete` for gossip range query replies, with detection for older spec nodes.
vibhaa
pushed a commit
to spider-pcn/lightning
that referenced
this pull request
Mar 24, 2021
We assume if they set this to 0 (which nobody did previously), they're using it as a modern flag and use it to indicate when they're finished. Otherwise, we count how many blocks they've sent and use that to determine whether they've finished. See: lightning/bolts#826 Signed-off-by: Rusty Russell <[email protected]> Changelog-Changed: Protocol: we use `sync_complete` for gossip range query replies, with detection for older spec nodes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We previously insisted that
reply_channel_rangemessages 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
completefield to afull_informationfield.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. AFAIK, no-one actually reads the
full_informationfield and use its info: so it's ok to re-purpose it.Implementations should probably deploy this in multiple phases:
sync_completefield: set it totrueonly in your lastreply_channel_rangesync_completereply_channel_rangeA safer approach would be to avoid re-using the
full_informationfield and instead introduce a new TLV field.Let me know if you think that's better.
Fixes #804