pull down to refresh

Channel gossip question
1517 sats \ 11 comments \ @EagleSats 13 Jan 2024 lightning
Not sure if this is really the right format for SN, since you essentially have to pay to answer my question 🤷‍♂️
But Anyhoo
Can anyone explain how channel gossiping works at a high-ish level?
Specifically, does my node SEND out gossip messages about the state of my channels to my peers.
OR
Does my channel PROBE each of my peers separately to determine the channel details?
OR
Is it something completely different?
Also how often does it happen?
Thanks in advance...
write
preview
related posts
362 sats \ 10 replies \ @fanis 13 Jan 2024
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
reply
31 sats \ 9 replies \ @EagleSats OP 13 Jan 2024
Ah yes of course. Should've checked the BOLTs first! Thanks 👍
reply
0 sats \ 8 replies \ @fanis 13 Jan 2024
To be fair bolts are a bit cumbersome to read, so at least now there's a short answer here if anyone else wonders :)
reply
0 sats \ 7 replies \ @EagleSats OP 14 Jan 2024
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
0 sats \ 6 replies \ @fanis 14 Jan 2024
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

  1. https://bitcoin.stackexchange.com/questions/80581/can-the-lightning-network-be-subject-to-dos-attacks-due-to-message-flooding/80600#80600 ↩
  2. Here for Acinq's node for example https://amboss.space/node/03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f ↩
  3. over the last 30 days ↩
reply
0 sats \ 5 replies \ @EagleSats OP 15 Jan 2024
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?
view all 5 replies