<p>The protocol is purposefully built in such a way that DoS attacks are mitigated and reduced in impact. Each <code>channel_announcement</code> contains a reference to the funding transaction, and each node verifies that this funding transaction matches the information in the announcement. This makes the creation of a <code>channel_announcement</code> non-free, and binds some resources of a potential attacker, and a channel may only be announced once. <code>channel_update</code>s are only valid if they are preceded by a matching <code>channel_announcement</code> making them also non-free. The same is true for <code>node_announcement</code>s which must be preceded by at least one <code>channel_announcement</code> announcing a channel for that node.</p>

<p>While <code>channel_announcement</code>s are unique, this is not true for <code>channel_update</code>s and <code>node_announcement</code>s, which can update the parameters of a channel/node. To mitigate a potential flood of updates the protocol specifies that a <a href="https://github.com/lightningnetwork/lightning-rfc/blob/57dad8161b8aa121dcdc669a877db05732ea5e5d/07-routing-gossip.md#rebroadcasting" rel="nofollow noreferrer">staggered broadcast</a> must be used, which buffers incoming gossip messages and waits 60 seconds for in-memory replacements before forwarding them. This coalesces multiple updates for the same channel or node into a single message then being actually broadcast. So if you attempt to broadcast loads of updates they'll be aggregated at the first hop, and only the latest one will ever be forwarded.</p>

<p>This reduces the number of messages that a node may broadcast to 1 <code>channel_announcement</code> per channel, and 1 <code>node_announcement</code> per node per 60 seconds and 1 <code>channel_update</code> per channel per 60 seconds.</p>

<p>(Disclaimer: I am one of the spec authors and the author of the staggered broadcast proposal)</p>

CC BY-SA 4.0
2018-12-09T09:49:55.713Z
Though it was not asked I would add that dos attacks by flooding htlcs are quite possible, in particular if coordinated well
Rene Pickhardt
CC BY-SA 4.0
2018-11-01T11:02:47.897Z
2018-11-01T11:02:47.897Z
cdecker
<p>In the current implementations of the Lightning network protocol (c-lightning, eclair and lnd), is there any check that stops spamming/flooding of channel_announcement, mode_announcement or channel_update messages? Assume that these messages are valid and provable.</p>

<lightning-network><lightning-network-daemon><core-lightning><eclair><ln-gossip>
Can the lightning network be subject to DoS attacks due to message flooding?
Samvid
# Can the lightning network be subject to DoS attacks due to message flooding?

(Asked by: username_0 on 2018-10-31)

In the current implementations of the Lightning network protocol (c-lightning, eclair and lnd), is there any check that stops spamming/flooding of channel\_announcement, mode\_announcement or channel\_update messages? Assume that these messages are valid and provable.

**Tags:** lightning-network, lightning-network-daemon, core-lightning, eclair, ln-gossip


---

## 1 answers

### Answer by username_1 on 2018-11-01. Score: 3 | Accepted answer

The protocol is purposefully built in such a way that DoS attacks are mitigated and reduced in impact. Each `channel_announcement` contains a reference to the funding transaction, and each node verifies that this funding transaction matches the information in the announcement. This makes the creation of a `channel_announcement` non-free, and binds some resources of a potential attacker, and a channel may only be announced once. `channel_update`s are only valid if they are preceded by a matching `channel_announcement` making them also non-free. The same is true for `node_announcement`s which must be preceded by at least one `channel_announcement` announcing a channel for that node.

While `channel_announcement`s are unique, this is not true for `channel_update`s and `node_announcement`s, which can update the parameters of a channel/node. To mitigate a potential flood of updates the protocol specifies that a [staggered broadcast](https://github.com/lightningnetwork/lightning-rfc/blob/57dad8161b8aa121dcdc669a877db05732ea5e5d/07-routing-gossip.md#rebroadcasting) must be used, which buffers incoming gossip messages and waits 60 seconds for in-memory replacements before forwarding them. This coalesces multiple updates for the same channel or node into a single message then being actually broadcast. So if you attempt to broadcast loads of updates they'll be aggregated at the first hop, and only the latest one will ever be forwarded.

This reduces the number of messages that a node may broadcast to 1 `channel_announcement` per channel, and 1 `node_announcement` per node per 60 seconds and 1 `channel_update` per channel per 60 seconds.

(Disclaimer: I am one of the spec authors and the author of the staggered broadcast proposal)

> **Comments:**
> **username_2**: Though it was not asked I would add that dos attacks by flooding htlcs are quite possible, in particular if coordinated well  

---

