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?

Murch
  • 71,155
  • 33
  • 180
  • 600
Sergei Tikhomirov
  • 1,430
  • 7
  • 17

1 Answers1

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.

Rene Pickhardt
  • 11,670
  • 8
  • 35
  • So new node issues a `query` message 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 May 08 '19 at 14:40
  • Yes. But as the node can query any peer I believe this ability to censor should not yield a problem – Rene Pickhardt May 08 '19 at 14:43
  • Is this sustainable long-term as the network graph will be getting bigger? – Sergei Tikhomirov May 08 '19 at 15:04
  • 1
    A new node will flag the `initial_gossip_sync` bit in the `local_features` of the `init` message 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 May 08 '19 at 15:26
  • In 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](https://github.com/lightningnetwork/lightning-rfc/issues/575) 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 May 08 '19 at 15:28
  • @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 May 08 '19 at 16:09
  • 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 May 08 '19 at 16:12
  • This is currently being discussed on the [mailing list](https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-March/thread.html) 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 May 08 '19 at 16:22
  • @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 May 08 '19 at 16:27
  • @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 May 08 '19 at 16:59