Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-02 📝 Original message: Hi Fabrice, happy new ...
📅 Original date posted:2019-01-02
📝 Original message:
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.drouin at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
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.drouin at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev