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

BOLT 7: clarify how to encode multiple reply_channel_range messages #730

Closed

Conversation

sstone
Copy link
Collaborator

@sstone sstone commented Jan 20, 2020

When multiple reply_channel_range messages are sent back for a single query_channel_range query, they must cover the requested block range without gaps or overlaps:
first_blocknum must be set to the previous reply_channel_range's first_blocknum plus number_of_blocks.

When multiple `reply_channel_range` messages are sent back for a single `query_channel_range` query, they must cover the requested block range without gaps or overlaps:
`first_blocknum` must be set to the previous `reply_channel_range`'s `first_blocknum` plus `number_of_blocks`.
@sstone sstone added the clarification substantive change or addition around wording or meaning label Jan 20, 2020
@t-bast
Copy link
Collaborator

t-bast commented Jan 21, 2020

Actually there's already a pending PR with the same clarification: #560

@sstone
Copy link
Collaborator Author

sstone commented Jan 22, 2020

Not exactly. #560 specifies that replies must cover the block range requested in a query, without gaps at the beginning or the end, which was implied in the description of channel queries.

This PR adds a constraint for chaining multiple replies to a single query: the next reply_channel_range must start right after the last reply_channel_range that was sent. This is what lnd wants and does, but not eclair or c-lightning for example, which will handle gaps between consecutive replies (but c-lightning will not allow replies to overlap).
Different impls do different things here because the specs are not specific enough, which is what I'm trying to fix: do we allow gaps between consecutive replies ?
This PR says 'no we don't', which imho is the best option as it allows the recipient to validate what it receives.

@t-bast
Copy link
Collaborator

t-bast commented Jan 22, 2020

Gotcha, that means this PR should supercede #560 because it adds something more restrictive.

@t-bast
Copy link
Collaborator

t-bast commented May 11, 2020

Superceded by #737

@t-bast t-bast closed this May 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification substantive change or addition around wording or meaning
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants