#11128·lnd

Unknown channel messages dropped without `error`

Author: morehouseCreated Aug 27, 2026Updated Sep 17, 2026

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