From fabrice.drouin at acinq.fr Wed Jan 2 19:46:42 2019 From: fabrice.drouin at acinq.fr (Fabrice Drouin) Date: Wed, 2 Jan 2019 20:46:42 +0100 Subject: [Lightning-dev] Quick analysis of channel_update data In-Reply-To: <87ef9veztc.fsf@gmail.com> References: <87ef9veztc.fsf@gmail.com> Message-ID: On Wed, 2 Jan 2019 at 18:26, Christian Decker wrote: > > For the ones that flap with a period that is long enough for the > disabling and enabling updates being flushed, we are presented with a > tradeoff. IIRC we (c-lightning) currently hold back disabling > `channel_update`s until someone actually attempts to use the channel at > which point we fail the HTLC and send out the stashed `channel_update` > thus reducing the publicly visible flapping. For the enabling we can't > do that, but we could think about a local policy on how much to delay a > `channel_update` depending on the past stability of that peer. Again > this is local policy and doesn't warrant a spec change. > > I think we should probably try out some policies related to when to send > `channel_update`s and how to hide redundant updates, and then we can see > which ones work best :-) > Yes, I haven't looked at how to handle this with local policies. My hypothesis is that when you're syncing a routing table that is say one day old, you end up querying and downloading a lot of information that you already have, and that adding a basic checksum to our channel queries may greatly improve this. Of course this would be much more actionable with stats and hard numbers which I'll provide ASAP. Cheers, Fabrice