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

BOLT7: extend channel range queries with optional fields #557

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@sstone
Copy link
Collaborator

sstone commented Jan 23, 2019

This is a new pull requests that supersedes #519 .

It addresses issues with the original proposal, mainly that it defined a new set of messages, adding complexity to a simple gossip protocol that we knew was limited in the first place.

This proposal does not add new messages, or feature bits, and is fully compatible with existing implementations. Instead of defining new messages it extends existing ones with additional data, that will be ignored by nodes which do not implement extended queries (see BOLT #1).

Nodes that support extended queries will append an additional extended query flag to their query_channel_range queries. If the receiver supports extended queries and understands this flag, it will append the requested additional data to its reply_channel_range message.

There is currently only one type of additional data: one timestamp and one checksum per channel_update.
The checksum is a simple Adler32 checksum computed over the channel_update with timestamp and signature omitted.
Together they can be used to avoid querying channel_updates that are older than the ones you already have, or that are newer but don't include new information.

Nodes can then append additional data to their query_short_channel_ids messages, which consists in one flag per short channel id and specifies what they would like to receive (channel_announcement, or/and one channel_update or both`).

sstone added some commits Jan 22, 2019

BOLT7: extend channel range queries with optional fields
Nodes that support extended queries will append an additional extended query flag to
their `query_channel_range` queries. If the receiver supports extended queries and
understands this flag, it will append the required additional data to its
`reply_channel_range` message.

There is currently only one type of additional data: one timestamp and one checksum
per `channel_update`.
The checksum is a simple Adler32 checksum computed over the `channel_update`
with `timestamp` and `signature` omitted.
Together they can be used to avoid querying `channel_updates` that are older than
the ones you already have, or that are newer but don't include new information.

Nodes can then append additional data to their `query_short_channel_ids` messages, which
consists in one flag per short channel id and specifies what they would like to
receive (`channel_announcement`, or/and one `channel_update` or both`).
@sstone

This comment has been minimized.

Copy link
Collaborator Author

sstone commented Jan 24, 2019

For completeness, there is even a simpler solution: leave query_channel_range as is (no extra flag to signify that you want extended data), and if the receiver supports extended queries they always include extended data in their reply_channel_range.

I chose instead to explicitly signal support for extended queries in query_channel_range, which is more bandwidth efficient (replies won't include extended data unless you ask for it).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment