Unknown channel messages dropped without `error`
BOLT 1 states:
A sending node:
- SHOULD send `error` with the unknown `channel_id` in reply to messages of type `32`-`255` related to unknown channels.Every other implementation does this. Except for the funding_signed message, LND does not.
Impact
The major consequence is that it's more difficult to properly diagnose and debug implementation bugs. If the buggy peer receives an error immediately after the buggy message, the cause becomes obvious. If LND silently swallows the message instead, the problem doesn't surface until later on in the flow and debugging becomes more difficult.
This also makes our fuzzing with smite less efficient, since smite waits for LND to process and respond to certain messages (e.g., funding_created elicits either funding_signed when valid or error when invalid), and that response never comes.
Survey of channel_id-keyed messages
These are the places that would need to be updated to send errors.
| message | type | logic location | unknown-channel behavior |
|---|---|---|---|
stfu |
2 | readHandler |
log & drop |
accept_channel |
33 | funderProcessAcceptChannel |
log & drop |
funding_created |
34 | fundeeProcessFundingCreated |
log & drop |
funding_signed |
35 | funderProcessFundingSigned |
log & send error |
channel_ready |
36 | handleChannelReady |
log & drop |
shutdown |
38 | handleCloseMsg |
drop |
closing_signed |
39 | handleCloseMsg |
drop |
closing_complete |
40 | readHandler |
log & drop |
closing_sig |
41 | readHandler |
log & drop |
kickoff_sig |
777 | readHandler |
log & drop |
update_add_htlc |
128 | readHandler |
drop |
update_fulfill_htlc |
130 | readHandler |
drop |
update_fail_htlc |
131 | readHandler |
drop |
commitment_signed |
132 | readHandler |
drop |
revoke_and_ack |
133 | readHandler |
drop |
update_fee |
134 | readHandler |
drop |
update_fail_malformed_htlc |
135 | readHandler |
drop |
channel_reestablish |
136 | readHandler |
drop |
Source: lightningnetwork/lnd