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.


Lightning-dev mailing list

Reply via email to