Re: [Lightning-dev] Improving the initial gossip sync

Fabrice Drouin writes: > On 20 February 2018 at 02:08, Rusty Russell 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 >>

Re: [Lightning-dev] Improving the initial gossip sync

> With that said, this should instead be a distinct `chan_update_horizon` > message (or w/e name). If a particular bit is set in the `init` message, > then the next message *both* sides send *must* be `chan_update_horizon`. Tweaking this a bit, if we make it: don't send *any* channel updates at

Re: [Lightning-dev] Improving the initial gossip sync

Hi Rusty, > 1. query_short_channel_id > IMPLEMENTATION: trivial *thumbs up* > 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,

Re: [Lightning-dev] Improving the initial gossip sync

On 20 February 2018 at 02:08, Rusty Russell 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

Re: [Lightning-dev] Improving the initial gossip sync

Good morning Rusty, ​>4. query_short_channel_id > = > > >5. type: 260 (query_short_channel_id) > >6. data: > - [32:chain_hash] > > - [8:short_channel_id] > > This is general mechanism which lets you query for a > channel_announcement and channel_updates for a specific

Re: [Lightning-dev] Improving the initial gossip sync

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: 1. A query message for a particular shortid. 2. A query message for shortids in a range of blocks. 3. A gossip_timestamp field

Re: [Lightning-dev] Improving the initial gossip sync

I'm still pushing for the hash-based solution because it can be implemented and developed quickly and easily and fixes the main issues we've seen on testnet: - routing sync on mobile nodes - "route not found" errors when you're missing routing info. It can be deployed as an optional feature and

Re: [Lightning-dev] Improving the initial gossip sync

Christian Decker writes: > Rusty Russell writes: >> Finally catching up. I prefer the simplicity of the timestamp >> mechanism, with a more ambitious mechanism TBA. > > Fabrice and I had a short chat a few days ago and decided that

Re: [Lightning-dev] Improving the initial gossip sync

I like Christian's proposal of adding a simple announcement cutoff timestamp with the intention of designing something more sophisticated given more time. I prefer the approach of having an optional feature bit signalling that a `set_gossip_timestamp` message must be sent immediately after

Re: [Lightning-dev] Improving the initial gossip sync

Hi, Suppose you partition nodes into 3 generic roles: - payers: they mostly send payments, are typically small and operated by end users, and are offline quite a lot - relayers: they mostly relay payments, and would be online most of the time (if they're too unreliable other nodes will eventually

Re: [Lightning-dev] Improving the initial gossip sync

Hi, On 5 February 2018 at 14:02, Christian Decker wrote: > Hi everyone > > The feature bit is even, meaning that it is required from the peer, > since we extend the `init` message itself, and a peer that does not > support this feature would be unable to parse any