362 sats \ 10 replies \ @fanis 13 Jan \ on: Channel gossip question lightning
Your node sends gossip messages to the peer to which it is connected (note that "peer" doesn't mean "channel partner", your node can be connected to another node to exchange gossip data even if you don't share a channel).
Your node will typically send gossip messages to announce its existence, to announce new channels, or to update the information about said channels (changes in fees, channel closure, etc.). Your peers, upon receiving this messages, will often rebroadcast them to their own peers, and so on. This is how the general topology of the network disseminates across a high portion of nodes.
Nodes typically send gossip messages only when something changes, in order to preserve resources (both their own and their peers'). So this happen on changes, not on any predefined period.
When a new node is coming back online after a pause (or coming online for the first time), it asks its peers for gossip data it doesn't have, in order to learn about new channels and updates about existing channels.
Sauce : Bolt07
Ah yes of course. Should've checked the BOLTs first!
Thanks 👍
reply
reply
So it seems my node will send an update message whenever there is a change. It also sounds like the gossip message is a single message that is the complete state of all channels on the node, and it sends that whole piece of data to every node I am connected to every time there is an update to any channel.
Do you know if it staggers these gossip messages? Or just cycles through the nodes? Or sends them all in a single push?
My main reason for trying to get my head more around it is to do with routing fee updates, and what the optimal delay between updates is. For instance LND's autoloop runs on a 3 day cycle because they are trying to minimise the amount of gossip messages nodes need to deal with.
I feel that is much too slow to take meaningful action when trying to manage liquidity via fee rates.
But there must be an optimal amount of time which both takes decisive action on a depleted channel, but also doesnt overload peers with gossip updates.
reply
It also sounds like the gossip message is a single message that is the complete state of all channels on the node, and it sends that whole piece of data to every node I am connected to every time there is an update to any channel.
I have a different understanding, did you read that somewhere? My understanding is that each channel update is its own message, so if you update several channels in a row there will be a distinct
channel_update message sent to your peers for each updated channel.Batching however occurs on rebroadcasting: when a peer receives a gossip message from your node, it'll wait 60 seconds before rebroadcasting it to its peer. If, in the meantime, another message comes with new data that obsoletes that contained in the old message, the peer will replace the old message in its "rebroadcasting buffer" with the new one. This way, your peers only rebroadcast at most 1 channel update per minute and per channel1.
Regarding update propagation timing, Bolt07 suggests that a node continues to forward HTLCs paying the old fee rate during a 10 minutes window after the update, suggesting that 10 minutes is enough for a
channel_update message to propagate to nodes "near you" in terms of number of hops (which are the nodes that are most likely to route a payment through you).However, Amboss have their own per node metrics for
channel_announcement messages called AOT2 (Average Observability Time), which is the average3 time it takes for a channel_announcement message to be received by Amboss' node after the channel opening transaction has been confirmed. Note that the AOT is expected to be at least around 30 minutes for most nodes, since most nodes typically wait 3 confirmations before they consider a channel to be usable and start communicating about it to the network. However, even for big nodes, typical AOT is at least a few hours. So I guess LND's autoloop 3 days cycle is there not only to avoid exhausting resources, but also to let updates enough time to disseminate.Footnotes
-
Here for Acinq's node for example https://amboss.space/node/03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f ↩
-
over the last 30 days ↩
reply
Ah ok, you're right each update is for the single channel. Then the update announcements are rebroadcast by the peer every 60 seconds -
This reduces the number of messages that a node may broadcast to 1 channel_announcement per channel, and 1 node_announcement per node per 60 seconds and 1 channel_update per channel per 60 seconds.
It also says that because of the staggered batching of the updates, then multiple updates of the same channel can replace previous updates-
Because gossip messages are batched and replace previous ones, the result may be a single seemingly-redundant update.
So my thinking is that technically it shouldnt matter how often you update your channel, even if it hasnt propagated through the network completely, since any following updates that catch up to it will just replace the previous update in-memory during the gossip staggering/batching process.
I guess that might mitigate the propagation question (if im right that is), so its just a matter of resource conservation.
What do you think?
reply
Circling back to your original question, to the network at large it indeed doesn't really matter how often you update your channels, since your peers will act as a buffer and coalesce any redundant updates on 60-seconds windows. However, if you get really spammy about it and keep sending updates every second, your peers might want to rate-limit or blacklist you.
Now for a channel update to be effective, you want it to reach the nodes that might try to route through said channel. Only then can you start to observe if the channel update leads to any change in behaviour and, if it's still not what you expected, update the channel again. In other words, if you update your channels to frequently, the risk is that you don't let enough time for the new information to reach other nodes, and hence the update will appear to you as not having resulted in the expected change in routing flow, but that may only because the update hasn't actually propagated yet.
To put yet in other words: if you update your channel parameter based on the observation of the routing flow in your channel, then you need to wait enough time for any update to propagate before assessing whether this update had the desired effects or not.
Through this lens, I'd say there's definitely a propagation aspect to it, since updates that are so frequent they don't let enough time for previous updates to propagate don't seem very useful to me (unless it's just to amend a mistake/typo made in a previous update, of course).
reply
Any subsequent update will always be more accurate than the previous update. Also you dont need the update to propagate through the entire network for it to be useful. Every new node that receives it along the way creates a higher percentage of the network using the new parameters.
In any case, the use case in my head is more for adjusting rates on wildy fluctuating channels (not for making minor adjustments).
For instance consider you open a channel to a sink and they suck all the liquidity to their side straight away, so theres no more routing capacity in that direction. You'll want a fast and severe increase in fees on that channel to prevent any more nodes from trying to send funds that way.
So in that way it helps the network at large because there should be less failed attempts to route payments.
With the current LND autoloop, you'd be waiting 3 days for an update and it would only be a percentage of the median change in liquidity across all your channels (or something like that, i cant remember it exactly of the top of my head).
So meaningful change on a completely exhausted channel will likely take several cycles of fee adjustments.
Does any of that make sense?
reply