Following requirements have been placed on the receiving nodes related to the channel_update
message in BOLT #7.
- if timestamp is NOT greater than that of the last-received
channel_update
for thisshort_channel_id
AND fornode_id
:
- SHOULD ignore the message.
- otherwise:
- if the timestamp is equal to the last-received
channel_update
AND the fields (other than signature) differ:
- MAY blacklist this
node_id
.- MAY forget all channels associated with it.
According to my understanding the receiving node will first check the signature of related the dsha256
of the entire message before verifying the timestamp and not check the remainder of the message if the signature is invalid. So if other fields apart from signature are changed, then the signature will not be valid (as the message has changed) and the node will not process the message further.
Now here's the thing I'm wrestling with: If the node still plans to check the message (as shown in the quoted text above) even though the signature is invalid and then go forward to blacklist the node, it can give rise to DoS attacks. A malicious nodes will just take a channel_update
message that it received in the past from a node, change some fields like htlc_minimum_msat
and rebroadcast to other nodes. Those receiving nodes will then simply blacklist the node_id
without any wrongdoing from its part as (1) the timestamp is equal to the one it received in the past, (2) signature is same AND (3) other fields have changed.
So I feel that this check is simply not needed and if the software goes on to process this message despite checking the signature then it can give rise to attacks from malicious parties. Where am I incorrect in my thought process?