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.
1 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 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)
-
3Though it was not asked I would add that dos attacks by flooding htlcs are quite possible, in particular if coordinated well Dec 9, 2018 at 9:49