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
reply
Yeah that's right, I meant to say autofees.
Thanks for the chat! 👍
Oh just saw your at LNMarkets. Nice work, hope you guys are still kicking goals over there!
channel_updatemessage sent to your peers for each updated channel.channel_updatemessage 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).channel_announcementmessages called AOT2 (Average Observability Time), which is the average3 time it takes for achannel_announcementmessage 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