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

2018-02-19 Thread ZmnSCPxj via Lightning-dev
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 8-by

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

2018-02-19 Thread Rusty Russell
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 i

[Lightning-dev] Post-Schnorr lightning txes

2018-02-19 Thread Anthony Towns
Hi *, My understanding of lightning may be out of date, so please forgive (or at least correct :) any errors on my behalf. I was thinking about whether Greg Maxwell's graftroot might solve the channel monitoring problem (spoiler: not really) and ended up with maybe an interesting take on Schnorr.

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

2018-02-19 Thread Fabrice Drouin
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 wi