AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
High 72 Bitcoin

htlcswitch: bound peer-controlled channel ingress

Public commit record

What the developer wrote

Authored by Elle Mouton

68/100 · Adequate
htlcswitch: bound peer-controlled channel ingress

In this commit, we bound the channel mailbox by message count and by the
encoded size of non-commitment control messages. Commitment updates retain
their full custom-record allowance and remain protected by the count bound.
If either budget fills, we disconnect the peer instead of silently dropping
an ordered channel message.

We also reject unauthorized fee updates before fee-exposure evaluation,
return the exposure error used to fail the link, and emit peer-controlled
warning classes only once per link lifetime.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit hardens LND's channel message handling against a peer that tries to overwhelm the node. It adds limits on how many ordered messages and how much data a peer can queue up for a channel, and it disconnects the peer if either limit is exceeded instead of silently dropping messages. It also fixes a protocol rule: only the channel initiator is allowed to send fee updates, so the node now rejects fee updates from the wrong side before doing any math on them. Finally, it reduces log spam by recording certain peer warnings and unknown messages only once per channel lifetime.

Recommended action

Review the chosen limits (1000 messages, 4 MiB) against operational channel throughput and memory targets; ensure disconnect-on-full behavior does not introduce a DoS vector for slow readers; monitor for unexpected peer disconnections after upgrade.

Security signals we found

01

Adds resource bounds on peer-controlled channel ingress (count + bytes)

02

Disconnects peer on mailbox admission failure instead of silently dropping ordered channel messages

03

Prevents unauthorized UpdateFee from channel initiator before fee-exposure calculations

04

Returns the fee-exposure error used to fail the link

05

Deduplicates non-fatal warning/unknown message logging to reduce log spam

Risk score

Why this scored 72/100

Our methodology →
Potential impact 22/30
Exploitability 16/25
Stealth signal 10/15
Affected reach 12/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.