đź“… 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
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:53:50
in reply to nevent1q…2fv5
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:53:50Event JSON
{
"id": "a022c9f78c34c21088cd49fe45c41ba2e69689a959a5871748362e9a5c4745a5",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315230,
"kind": 1,
"tags": [
[
"e",
"fd0da5dbd5383b525edc98216d5094b180c1b831bf7af1f8df8ca35294a8c8fd",
"",
"root"
],
[
"e",
"d71a59e03a5845f89072fab5c5f819aa40cd8eb25952ebc95887e6d83477a361",
"",
"reply"
],
[
"p",
"81c48ba46c211bc8fdb490d1ccfb03609c7ea090f8587ddca1c990676f09cfd3"
]
],
"content": "📅 Original date posted:2019-01-02\n📝 Original message:\nHi Fabrice,\n\nhappy new year to you too :-)\n\nThanks for taking the time to collect that information. It's very much\nin line with what we were expecting in that most of the updates come\nfrom flapping channels. Your second observation that some updates only\nchange the timestamp is likely due to the staggered broadcast merging\nmultiple updates, e.g., one disabling and one enabling the channel, that\nare sent very close to each other. This is the very reason we introduced\nthe staggering back in the days, as it limits the maximum rate of\nupdates a single node may produce for each of its channels.\n\nIn the second case we can probably get away with not forwarding the\nupdate, but updating the timestamp and signature for the old\n`channel_update` locally, so that we don't then flap back to an older\none should we get that in a roundabout way. That's purely a local\ndecision and does not warrant a spec change imho.\n\nFor the ones that flap with a period that is long enough for the\ndisabling and enabling updates being flushed, we are presented with a\ntradeoff. IIRC we (c-lightning) currently hold back disabling\n`channel_update`s until someone actually attempts to use the channel at\nwhich point we fail the HTLC and send out the stashed `channel_update`\nthus reducing the publicly visible flapping. For the enabling we can't\ndo that, but we could think about a local policy on how much to delay a\n`channel_update` depending on the past stability of that peer. Again\nthis is local policy and doesn't warrant a spec change.\n\nI think we should probably try out some policies related to when to send\n`channel_update`s and how to hide redundant updates, and then we can see\nwhich ones work best :-)\n\nCheers,\nChristian\n\nFabrice Drouin \u003cfabrice.drouin at acinq.fr\u003e writes:\n\u003e Hello All, and Happy New Year!\n\u003e\n\u003e To understand why there is a steady stream of channel updates, even\n\u003e when fee parameters don't seem to actually change, I made hourly\n\u003e backups of the routing table of one of our nodes, and compared these\n\u003e routing tables to see what exactly was being modified.\n\u003e\n\u003e It turns out that:\n\u003e - there are a lot of disable/enable/disable etc…. updates which are\n\u003e just sent when a channel is disabled then enabled again (when nodes go\n\u003e offline for example ?). This can happen\n\u003e there are also a lot of updates that don’t change anything (just a new\n\u003e timestamp and signatures but otherwise same info), up to several times\n\u003e a day for the same channel id\n\u003e\n\u003e In both cases we end up syncing info that we already have.\n\u003e I don’t know yet how best to use this when syncing routing tables, but\n\u003e I thought it was worth sharing anyway. A basic checksum that does not\n\u003e cover all fields, but only fees and HTLC min/max values could probably\n\u003e be used to improve routing table sync ?\n\u003e\n\u003e Cheers,\n\u003e\n\u003e Fabrice\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "112856d07ce72c0b1fe118f07f609b4a536629380e47bef873840554c0f8c9d5b3569c7efb95b0e6459dedffdb82074ed238f8d2b346447128540d311c9ec1e7"
}