Fabrice Drouin <fabrice.dro...@acinq.fr> writes: > On 20 February 2018 at 02:08, Rusty Russell <ru...@rustcorp.com.au> wrote: >> Hi all, >> >> This consumed much of our lightning dev interop call today! But >> I think we have a way forward, which is in three parts, gated by a new >> feature bitpair: > > We've built a prototype with a new feature bit `channel_range_queries` > and the following logic: > When you receive their init message and check their local features > - if they set `initial_routing_sync` and `channel_range_queries` then > do nothing (they will send you a `query_channel_range`) > - if they set `initial_routing_sync` and not `channel_range_queries` > then send your routing table (as before) > - if you support `channel_range_queries` then send a > `query_channel_range` message
That seems logical; in this way, channel_range_queries obsoletes initial_routing_sync. >> 1. query_short_channel_id >> ========================= >> >> 1. type: 260 (`query_short_channel_id`) >> 2. data: >> * [`32`:`chain_hash`] >> * [`8`:`short_channel_id`] > > We could add a `data` field which contains zipped ids like in > `reply_channel_range` so we can query several items with a single > message ? We could, let's use the same compression format as we decide for the `reply_channel_range` `data` field. > >> 1. type: 262 (`reply_channel_range`) >> 2. data: >> * [`32`:`chain_hash`] >> * [`4`:`first_blocknum`] >> * [`4`:`number_of_blocks`] >> * [`2`:`len`] >> * [`len`:`data`] > > We could add an additional `encoding_type` field before `data` (or it > could be the first byte of `data`) Yes, let's put it in first byte of data. >> I tried various obvious compression schemes, in increasing complexity >> order (see source below, which takes stdin and spits out stdout): >> >> Raw = raw 8-byte stream of ordered channels. >> gzip -9: gzip -9 of raw. >> splitgz: all blocknums first, then all txnums, then all outnums, >> then gzip -9 >> delta: CVarInt encoding: >> blocknum_delta,num,num*txnum_delta,num*outnum. >> deltagz: delta, with gzip -9 >> >> Corpus 1: LN mainnet dump, 1830 channels.[1] >> >> Raw: 14640 bytes >> gzip -9: 6717 bytes >> splitgz: 6464 bytes >> delta: 6624 bytes >> deltagz: 4171 bytes >> >> Corpus 2: All P2SH outputs between blocks 508000-508999 incl, 790844 >> channels.[2] >> >> Raw: 6326752 bytes >> gzip -9: 1861710 bytes >> splitgz: 964332 bytes >> delta: 1655255 bytes >> deltagz: 595469 bytes >> >> [1] http://ozlabs.org/~rusty/short_channels-mainnet.xz >> [2] http://ozlabs.org/~rusty/short_channels-all-p2sh-508000-509000.xz > > Impressive! Which method did you prefer? splitgz is trivial, deltagz is better but requires some actual work. We should pick one and make that `version 0`. Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
