<p>This is an excellent question but still probably a little bit under specified. Let me try to give an answer and elaborate.</p>

<p>When looking at network bandwidth there are several componants playing into it. </p>

<p>The most obvious (and probably most dominant) one 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>. There are 4 messages which are used to provide the information about the gossip protocol to every node. </p>

<ul>
<li>The <code>announcement_signatures</code> Message</li>
<li>The <code>channel_announcement</code> Message</li>
<li>The <code>node_announcement</code> Message</li>
<li>The <code>channel_update</code> Message</li>
</ul>

<p>While the first one is only sent between two peers to decide if a channel stays private or not the second and third needs to be delivered to every node. The way how gossip achieves this is by forwarding the message to each peer if it was received and novel to the node. The amortized / expected network bandwidth for those messages should thus be <code>O(E/V*(E+V))</code> where <code>E/V</code> ist the average node degree. And <code>E</code> the number of edges and <code>V</code> the number of nodes. In the worst case (unrealistic) of a fully connected graph we have <code>E=V*V</code> and thus <code>O(V^3 + V^2) = O(V^3)</code></p>

<p>The situation is even worse for the 4th message. Everytime the routing fees are adjusted by a node this message needs to be delivered to every other node and creates <code>O(E/V*(E))</code> messages. While the 3rd and 4th message will only be propagated when received first. The update message can be send every second and will be propagated Everytime. This the network bandwidth req can be arbitrary (? Still bound by the second) large even for small networks. This is obviously also a ddos attack vector. There is <a href="https://medium.com/@rusty_lightning/proposal-the-million-channel-lightning-project-d8c34666d6d4" rel="nofollow noreferrer">the million channel challenge</a> by rusty to stimulate this behavior.</p>

<p>Other less dominant components are messages that are only exchanged between peers to maintain the channel state. While connecting, handshakes etc seem neglictable there is the case of routing. Let us in a first step assume that every routing process is successful the bandwidth will then grow as <code>O(b*t)</code> with <code>t</code> being the number of transactions or payments being done by the network and <code>b</code> being the betweeness centrality of the node on the fee graph which according to <a href="https://youtu.be/L39IvFqTZk8" rel="nofollow noreferrer">this video is likelihood of that node being on a cheapest path</a>. This would have to be corrected by the likelihoid of routing failures. For the overall network it could be the product of number of transactions times average Pathlenght times average number of routing attempts. </p>

<p>There is also the network bandwidth coming from the Bitcoin node but that should not change with the growth of lightning. </p>

<p>I hope I didn't miss anything. Stuff changes drastically with AMP routing since every payment is split into several small payments. </p>

CC BY-SA 4.0
2019-05-06T08:56:05.373Z
Wow, that's actually a great answer. This is the best O() analysis of LN that I've seen. Thanks! One thing I'm confused about though is that channel balances also change the network topology. Shouldn't balances also be updated at some point? If not, the number of failed tx might even create more extra traffic than the updates... Am I misunderstanding something?
Clayton Rabenda
CC BY-SA 4.0
2019-05-06T09:01:16.487Z
Only the capacity of channels is announced and publuc. The channel balance is a private datapoint between the channel partners. This is the reason why path finding (trying routes) is difficult. The exact topology is unknown. I am happy you liked my answer. I think great questions deserve extensive answers (which is why I was happy to do it on a mobile device!) I hope my calculations / assumptions are correct though. Btw goggle tried 3 times to recruite me as a PM and everytime they suggested software engineering after the recruiting process ;)
Rene Pickhardt
CC BY-SA 4.0
2019-05-06T08:38:00.450Z
2019-05-06T08:38:00.450Z
Rene Pickhardt
<p>When I worked at Google, if someone wanted to deploy a network application they would need to provide a document to the SREs detailing the behaviour of the application at scale in terms of Big-O. Does something like this exist for LN?</p>

<p>I understand that we would have to make some assumptions about the network topology, that's fine. What I really need to know is simply what are all the network functions and when do they fire.</p>

<lightning-network><scalability><lightning-routing><network>
What is the Big-O for LN bandwidth? Can anyone answer this or provide a link to a spec that is sufficient enough for us to calculate it?
Clayton Rabenda
# What is the Big-O for LN bandwidth? Can anyone answer this or provide a link to a spec that is sufficient enough for us to calculate it?

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

When I worked at Google, if someone wanted to deploy a network application they would need to provide a document to the SREs detailing the behaviour of the application at scale in terms of Big-O. Does something like this exist for LN?

I understand that we would have to make some assumptions about the network topology, that's fine. What I really need to know is simply what are all the network functions and when do they fire.

**Tags:** lightning-network, scalability, lightning-routing, network


---

## 1 answers

### Answer by username_1 on 2019-05-06. Score: 3

This is an excellent question but still probably a little bit under specified. Let me try to give an answer and elaborate.

When looking at network bandwidth there are several componants playing into it.

The most obvious (and probably most dominant) one is specified in [BOLT 07 routing-gossip](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md). There are 4 messages which are used to provide the information about the gossip protocol to every node.

* The `announcement_signatures` Message
* The `channel_announcement` Message
* The `node_announcement` Message
* The `channel_update` Message

While the first one is only sent between two peers to decide if a channel stays private or not the second and third needs to be delivered to every node. The way how gossip achieves this is by forwarding the message to each peer if it was received and novel to the node. The amortized / expected network bandwidth for those messages should thus be `O(E/V*(E+V))` where `E/V` ist the average node degree. And `E` the number of edges and `V` the number of nodes. In the worst case (unrealistic) of a fully connected graph we have `E=V*V` and thus `O(V^3 + V^2) = O(V^3)`

The situation is even worse for the 4th message. Everytime the routing fees are adjusted by a node this message needs to be delivered to every other node and creates `O(E/V*(E))` messages. While the 3rd and 4th message will only be propagated when received first. The update message can be send every second and will be propagated Everytime. This the network bandwidth req can be arbitrary (? Still bound by the second) large even for small networks. This is obviously also a ddos attack vector. There is [the million channel challenge](https://medium.com/@rusty_lightning/proposal-the-million-channel-lightning-project-d8c34666d6d4) by rusty to stimulate this behavior.

Other less dominant components are messages that are only exchanged between peers to maintain the channel state. While connecting, handshakes etc seem neglictable there is the case of routing. Let us in a first step assume that every routing process is successful the bandwidth will then grow as `O(b*t)` with `t` being the number of transactions or payments being done by the network and `b` being the betweeness centrality of the node on the fee graph which according to [this video is likelihood of that node being on a cheapest path](https://youtu.be/L39IvFqTZk8). This would have to be corrected by the likelihoid of routing failures. For the overall network it could be the product of number of transactions times average Pathlenght times average number of routing attempts.

There is also the network bandwidth coming from the Bitcoin node but that should not change with the growth of lightning.

I hope I didn't miss anything. Stuff changes drastically with AMP routing since every payment is split into several small payments.

> **Comments:**
> **username_0**: Wow, that's actually a great answer. This is the best O() analysis of LN that I've seen. Thanks! One thing I'm confused about though is that channel balances also change the network topology. Shouldn't balances also be updated at some point? If not, the number of failed tx might even create more extra traffic than the updates... Am I misunderstanding something?  
> **username_1**: Only the capacity of channels is announced and publuc. The channel balance is a private datapoint between the channel partners. This is the reason why path finding (trying routes) is difficult. The exact topology is unknown. I am happy you liked my answer. I think great questions deserve extensive answers (which is why I was happy to do it on a mobile device!) I hope my calculations / assumptions are correct though. Btw goggle tried 3 times to recruite me as a PM and everytime they suggested software engineering after the recruiting process ;)  

---

