On Wed, 2 Jan 2019 at 18:26, Christian Decker <decker.christ...@gmail.com> 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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
