Encodings in gossip_queries

[bmancini55]

Currently the spec requires an implementation to support both raw and zlib deflate encodings for short_channel_ids in reply_channel_range and query_short_channel_ids messages.

There is discrepancy of the default encoding used when replying to a query with reply_channel_range message. It would be nice to have clarification surrounding when zlib deflate or raw encodings should be sent in reply to a query.

A bigger request is that rust-lightning would like to not add a zlib dependency to the project. There is currently no way to signal support or lack thereof for zlib. It would be nice if a node could signal this support in Init. There is likely overlap with #804 depending on how reply sequencing is structured, so I wanted to raise this issue for discussions while that is being discussed.

[ariard]

@bmancini55 Or can you add a option_scid_encodings in Init and a new u8 supported_encodings in gossip_timestamp_filter, which is also re-purposed as a encoding negotiation message ? Though I've not thought that much about soundness of this, do people expect to extend with other encodings in the future?

[bmancini55]

@ariard, that's an interesting idea!

From my understanding of the historical conversation there isn't much interest in supporting additional encodings. That said, I believe compression addresses two concerns:

1. Trades bandwidth for processing
2. Increases the limit of scids we can share for a single block

The latter exists because BOLT7 requires sequential reply_channel_range messages to start on the next block. There is a limit of ~8k channels per message due to the number of scids you can pack into the 65535-byte Lightning message payload. If a block has more than ~8k scids there is no way to share that in a reply_channel_range, unless you compress it.

My hope is that if we allow resumption on the same block in #804, concern 2 goes away and encoding becomes more a preferential thing than an escape hatch.

[t-bast]

We removed zlib support in #981, thus fixing this issue.