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
- SHOULD ignore the message.
- if the timestamp is equal to the last-received
channel_updateAND the fields (other than signature) differ:
- MAY blacklist this
- 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?