1
Lightning nodes store a full network snapshots to calculate routes for outgoing payments. Nodes listen to announcements of new (public) channel openings and constantly update their local snapshots.
But where do new nodes (or nodes which return after being offline) get the information about the currently existing channels?
2
This is done via the peer 2 peer network that comes along with lightning and is specified in BOLT 07 - routing-gossip. If you read the details you will see that you have to peer to a node in order to maintain a channel. But you could also establish peer2peer connections with other peers without the necessity to maintain a channel.
The peer protocol supports channel announcement messages that are being forwarded via the gossip protocol and query messages to ask for messages if a node connects for the first time to the network or was offline as asked.
So new node issues a
querymessage to a neighbor and gets an archive of all past channel announcements in response? There is no guarantee that a remote node has the full picture of the network and doesn't intentionally omit some messages, right? – Sergei Tikhomirov – 2019-05-08T14:40:19.607Yes. But as the node can query any peer I believe this ability to censor should not yield a problem – Rene Pickhardt – 2019-05-08T14:43:52.807
Is this sustainable long-term as the network graph will be getting bigger? – Sergei Tikhomirov – 2019-05-08T15:04:18.627
1A new node will flag the
initial_gossip_syncbit in thelocal_featuresof theinitmessage the first time they connect. The connected node will forward all known gossip information in response. Query messages are used later to re-sync if there is some missing information, of if information has been filtered. – Mark H – 2019-05-08T15:26:00.517In regards to it being sustainable, you can calculate the probability of not receiving a message based on the number of peers being connected to. I previously proposed probabilistically forwarding gossip information based on the number of channels a node has, because the chance of not receiving information is very low when you're connected to > 6 peers is extremely small.
– Mark H – 2019-05-08T15:28:11.723@MarkH: It sounds as if you should be adding an answer! It's perfectly acceptable to have multiple answers to questions. Often, people explain stuff differently or focus on different aspects so at least the first few answers are usually complementary. – Murch – 2019-05-08T16:09:52.153
1@MarkH By sustainable I meant that the nodes won't be able to store the whole graph to do proper routing. The question of censorship indeed seems to be solvable by querying multiple peers (unless the node is eclipsed somehow). – Sergei Tikhomirov – 2019-05-08T16:12:40.343
This is currently being discussed on the mailing list under the title "Routemap Scaling...", and related posts on "Just-In-Time Routing...". Nodes will eventually need to filter their network graph but there are some trade-offs to be made.
– Mark H – 2019-05-08T16:22:11.240@Murch, my answers were in response to the comments so I think it is best left that way unless the original question is rephrased to include the additional questions raised in the comment. – Mark H – 2019-05-08T16:27:13.937
@MarkH: It's just that I've seen a lot of follow up discussions in comments lately. Ideally, the points that come up in comments would get incorporated in the answer post or in another answer. Comments tend to add visual clutter, so once they've been addressed, we should clean them up: https://bitcoin.stackexchange.com/help/privileges/comment. In this case it seems that there is good content in the comments that would be nice to preserve. :)
– Murch – 2019-05-08T16:59:41.003