Olaoluwa Osuntokun <laol...@gmail.com> writes: > Hi Rusty, > >> 1. query_short_channel_id >> IMPLEMENTATION: trivial > > *thumbs up*
OK, I'm implementing this now, with data packing so we can have more than one. (Current 0 and the straight array, will then be able to assess how impactful adding a simple encoder is). >> 2. query_channel_range/reply_channel_range >> IMPLEMENTATION: requires channel index by block number, zlib > > For the sake of expediency of deployment, if we add a byte (or two) to > denote the encoding/compression scheme, we can immediately roll out the > vanilla (just list the ID's), then progressively roll out more > context-specific optimized schemes. Meh, zlib is pretty trivial for all implementations though. Will implement and see how long it takes me though. >> 3. A gossip_timestamp field in `init` >> This is a new field appended to `init`: the negotiation of this feature > bit >> overrides `initial_routing_sync` > > As I've brought up before, from my PoV, we can't append any additional > fields to the innit message as it already contains *two* variable sized > fields (and no fixed size fields). Aside from this, it seems that the > `innit` message should be simply for exchange versioning information, which > may govern exactly *which* messages are sent after it. Otherwise, by adding > _additional_ fields to the `innit` message, we paint ourselves in a corner > and can never remove it. Compared to using the `innit` message to set up the > initial session context, where we can safely add other bits to nullify or > remove certain expected messages. I don't see this argument at all; we can add fields, we can remove them, but we still have to transmit them which wastes a little space. Adding a new field and insist it be next packet is a weird ordering contraint, which AFAICT is unique in the protocol. > Another advantage of making this a distinct message, is that either party > can at any time update this horizon/filter to ensure that they only receive > the *freshest* updates.Otherwise, one can image a very long lived > connections (say weeks) and the remote party keeps sending me very dated > updates (wasting bandwidth) when I only really want the *latest*. > > This can incorporate decker's idea about having a high+low timestamp. I > think this is desirable as then for the initial sync case, the receiver can > *precisely* control their "verification load" to ensure they only process a > particular chunk at a time. This is a more convincing argument. I guess we'll have to index by timestamp (we currently index by receive order only); I was hoping we could get away with a single brute-force traverse when the peer initially connected. So, let's say `channel_range_queries` means don't send *any* gossip messages until asked (presumably from `gossip_set_timestamp_range`); we'd implement this by setting the peer's timestamp range to 0,0. Receiving a new `gossip_set_timestamp_range` would override any previous. OK, I'm hacking together now to see if I've missed anything before proposing a proper spec... Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
