<p>This is done via the peer 2 peer network that comes along with lightning and is specified in <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md" rel="nofollow noreferrer">BOLT 07 - routing-gossip</a>. 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. </p>

<p>The peer protocol supports <code>channel announcement</code> messages that are being forwarded via the gossip protocol and <code>query</code> messages to ask for messages if a node connects for the first time to the network or was offline as asked. </p>

CC BY-SA 4.0
2019-05-08T14:40:19.607Z
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
CC BY-SA 4.0
2019-05-08T14:43:52.807Z
Yes. But as the node can query any peer I believe this ability to censor should not yield a problem
Rene Pickhardt
CC BY-SA 4.0
2019-05-08T15:04:18.627Z
Is this sustainable long-term as the network graph will be getting bigger?
Sergei Tikhomirov
CC BY-SA 4.0
2019-05-08T15:26:00.517Z
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
CC BY-SA 4.0
2019-05-08T15:28:11.723Z
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
CC BY-SA 4.0
2019-05-08T16:09:52.153Z
@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
CC BY-SA 4.0
2019-05-08T16:12:40.343Z
@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
CC BY-SA 4.0
2019-05-08T16:22:11.240Z
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
CC BY-SA 4.0
2019-05-08T16:27:13.937Z
@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
CC BY-SA 4.0
2019-05-08T16:59:41.003Z
@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
CC BY-SA 4.0
2019-05-08T14:10:49.770Z
2019-05-08T14:10:49.770Z
Rene Pickhardt
<p>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.</p>

<p>But where do new nodes (or nodes which return after being offline) get the information about the currently existing channels?</p>

<lightning-network><lightning-routing><ln-topology>
How do new nodes learn the topology of Lightning network?
Sergei Tikhomirov
# How do new nodes learn the topology of Lightning network?

(Asked by: username_0 on 2019-05-08)

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?

**Tags:** lightning-network, lightning-routing, ln-topology


---

## 1 answers

### Answer by username_1 on 2019-05-08. Score: 2 | Accepted answer

This is done via the peer 2 peer network that comes along with lightning and is specified in [BOLT 07 - routing-gossip](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md). 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.

> **Comments:**
> **username_0**: 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?  
> **username_1**: Yes. But as the node can query any peer I believe this ability to censor should not yield a problem  
> **username_0**: Is this sustainable long-term as the network graph will be getting bigger?  
> **username_2**: 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.  
> **username_2**: 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.  
> **username_3**: @username_2: 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.  
> **username_0**: @username_2 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).  
> **username_2**: 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.  
> **username_2**: @username_3, 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.  
> **username_3**: @username_2: 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. :)  

---

