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

Check dust exposure on receiving `commitment_signed`, not `update_fee`

Public commit record

What the developer wrote

Authored by Leo Nash

73/100 · Adequate
Check dust exposure on receiving `commitment_signed`, not `update_fee`

We allow a peer to send an `update_fee` message that pushes the dust
exposure over our max as long as they send HTLC updates that bring the
dust exposure back down under the limit before they send
`commitment_signed`.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes when a Lightning node checks whether a proposed fee change would create risky 'dust' exposure. Previously, the check happened immediately when the peer sent an `update_fee` message. Now, the check is deferred until the peer sends `commitment_signed`, which is the moment the new fee would actually take effect. This allows a peer to send a fee update that temporarily looks risky, as long as they add or remove HTLCs before signing the commitment so that the final state is safe. The change also removes some duplicated fee-calculation code and moves an affordability check into the same deferred validation path.

Recommended action

Review the new `validate_commitment_signed` path to confirm that all pending fee updates are validated exactly once and that the dust-exposure and reserve checks cover both local and remote commitment views. Ensure test coverage includes cases where `update_fee` alone would exceed dust limits but `commitment_signed` does not, and vice versa.

Security signals we found

01

Validation timing moved from `update_fee` to `commitment_signed`

02

Dust-exposure limit now evaluated against final commitment state rather than intermediate fee message

03

Counterparty fee affordability checked at commitment time, not update-fee time

04

Removal of duplicated commitment-stats computation reduces risk of inconsistent validation

05

Channel force-close is the enforcement mechanism for violations

Risk score

Why this scored 63/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 10/15
Affected reach 12/15
Confidence 7/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.