ChannelAnnouncement rebroadcasting is broken
#2418
Comments
slipping to 118 |
|
Want to note that the same goes for node announcements, at least it would be very helpful if we'd take care of (re)broadcasting, especially after a channel has been opened. This would useful if our counterparties are mostly-offline mobile users that that are running of RGS data, i.e., would maybe never see a node announcements for their channel counterparty if they don't happen to be online at the right time (cf. lightningdevkit/ldk-node#234 (comment)). I think generally it would be preferable if LDK could handle this internally, but an intermediate solution is #2866, which would allow us to trigger the rebroadcasting for a specific counterparty after the channel has been created. |
|
Hmm, node_announcements shouldnt ever be sent by mostly-offline nodes, however? They're only relevant for routing nodes, so rebroadcasting on a timer once an hour should more than suffice. |
I agree that only routing nodes should broadcast node announcements, the issue is that if our counterparty (see above) is a mobile node running on RGS they wouldn't get the node announcement via RGS and therefore would only get useful information (e.g. node alias, listening addresses allowing to reconnect) if they happen to be online at the time we decide to broadcast. So I disagree that just rebroadcasting once an hour should suffice, that would only work if our counterparty is also reliably online at that point in time. We should make sure to broadcast our node announcement over freshly opened or reconnected channels. |
|
In that case the counterparty should get the node info when they do regular gossip sync from us, rather than via our hourly (or whatever) broadcast timer. |
Yes I agree this is the intended behavior, but I'm not sure this works currently? Note that neither |
|
Wait, so we're talking about a setup where we have one public, large-ish routing node, with open channels and multiple peers that's online 24/7, and an LDK Node node that's hanging off of it. The LDK Node instance, if its using RGS, indeed should not receive info of the large routing node's channel_announcement because it explicitly opted to use RGS and wishes to receive the network graph that way rather than using the regular gossip sync mechanism. Exposing network information via RGS is a somewhat separate topic, but one we'd discussed possibly doing. |
Mostly, yes, but the issues are around node announcements rather than channel announcements. I think there are two related issues here: a) I'm not convinced the routing node would reliably send the node announcements to the 'client' node, if the latter doesn't happen to be online when the (hourly or daily) broadcast is triggered. |
I think we're on the same page here. In generally I think this is actually preferred - the client isn't doing gossip sync so we shouldn't be sending them gossip.
Right, for IPs specifically we're looking at including hosts in the RGS data. |
Aliases would also be a nice-to-have as Wallet will want to present human-readable names. Currently, they'd do a lookup to |
|
Hmm, I'm vaguely surprised a mobile wallet would care what a node's alias is? Should they really be displaying that vs picking a node they know? |
I think it has mostly to do with showing something prettier / more human readable than a 33-byte pubkey in the UI, i.e., even after the channel is already open. |
|
Right, but presumably a mobile wallet isn't opening channels to random nodes, so it can display the node alias via some out of band knowledge. |
When we first get a public channel confirmed at six blocks, we broadcast a `channel_announcement` once and then move on. As long as it makes it into our local network graph that should be okay, as we should send peers our network graph contents as they seek to sync, however its possible an ill-timed shutdown could cause this to fail, and relying on peers to do a full historical sync from us may delay `channel_announcement` propagation. Instead, here, we re-broadcast our `channel_announcement`s every six blocks for a week, which should be way more than robust enough to get them properly across the P2P network. Fixes lightningdevkit#2418
When we first get a public channel confirmed at six blocks, we broadcast a `channel_announcement` once and then move on. As long as it makes it into our local network graph that should be okay, as we should send peers our network graph contents as they seek to sync, however its possible an ill-timed shutdown could cause this to fail, and relying on peers to do a full historical sync from us may delay `channel_announcement` propagation. Instead, here, we re-broadcast our `channel_announcement`s every six blocks for a week, which should be way more than robust enough to get them properly across the P2P network. Fixes lightningdevkit#2418
When we first get a public channel confirmed at six blocks, we broadcast a `channel_announcement` once and then move on. As long as it makes it into our local network graph that should be okay, as we should send peers our network graph contents as they seek to sync, however its possible an ill-timed shutdown could cause this to fail, and relying on peers to do a full historical sync from us may delay `channel_announcement` propagation. Instead, here, we re-broadcast our `channel_announcement`s every six blocks for a week, which should be way more than robust enough to get them properly across the P2P network. Fixes lightningdevkit#2418
#2382 noted that in
ChannelManager::peer_connectedthe code that used to walk all our channels and sendChannelAnnouncementmessages in response to peers connecting was made dead code when we moved channel storage into per-peer maps. This was the only place we ever rebroadcastedChannelAnnouncementmessages, which means we now are one-and-done, sending our announcement messages when we first exchange signatures and that's it. Luckily our peer should rebroadcast these for us, and if the announcement makes it into our local network graph on-disk we'll do so during normal gossip sync, so its not a huge deal, but we should make sure we rebroadcast them somewhere so that we don't have ldk <-> ldk channels that aren't visible to the network.The text was updated successfully, but these errors were encountered: