Hi Fabrice, happy new year to you too :-)
Thanks for taking the time to collect that information. It's very much in line with what we were expecting in that most of the updates come from flapping channels. Your second observation that some updates only change the timestamp is likely due to the staggered broadcast merging multiple updates, e.g., one disabling and one enabling the channel, that are sent very close to each other. This is the very reason we introduced the staggering back in the days, as it limits the maximum rate of updates a single node may produce for each of its channels. In the second case we can probably get away with not forwarding the update, but updating the timestamp and signature for the old `channel_update` locally, so that we don't then flap back to an older one should we get that in a roundabout way. That's purely a local decision and does not warrant a spec change imho. 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 :-) Cheers, Christian Fabrice Drouin <fabrice.dro...@acinq.fr> writes: > Hello All, and Happy New Year! > > To understand why there is a steady stream of channel updates, even > when fee parameters don't seem to actually change, I made hourly > backups of the routing table of one of our nodes, and compared these > routing tables to see what exactly was being modified. > > It turns out that: > - there are a lot of disable/enable/disable etc…. updates which are > just sent when a channel is disabled then enabled again (when nodes go > offline for example ?). This can happen > there are also a lot of updates that don’t change anything (just a new > timestamp and signatures but otherwise same info), up to several times > a day for the same channel id > > In both cases we end up syncing info that we already have. > I don’t know yet how best to use this when syncing routing tables, but > I thought it was worth sharing anyway. A basic checksum that does not > cover all fields, but only fees and HTLC min/max values could probably > be used to improve routing table sync ? > > Cheers, > > Fabrice > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
