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

Don't trim HTLCs when calculating the fee spike commit tx fee

Public commit record

What the developer wrote

Authored by Leo Nash

73/100 · Adequate
Don't trim HTLCs when calculating the fee spike commit tx fee

We previously accounted for HTLC trims at the spiked feerate when
calculating the commitment transaction fee including the fee spike
multiple.

This only ensured that the funder of the channel could afford the
commitment transaction fee for an exact 2x increase in the feerate.

Now, we check that the funder can cover any increase in the feerate
between 1x to 2x.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a bug in how Lightning Dev Kit calculates whether a channel funder can afford a sudden spike in Bitcoin transaction fees. Previously, the code assumed HTLCs (small conditional payments) that would become uneconomical at a doubled feerate were already trimmed away when checking the funder's buffer. This made the check too optimistic: it only verified the funder could survive an exact 2x fee jump, not any jump between normal and 2x. The fix counts HTLCs at the current feerate instead of the spiked one, ensuring the reserve covers the full range of possible fee increases. The commit is framed by its author as a correctness fix for fee-spike buffer accounting.

Recommended action

Treat as a security-relevant correctness fix. Review related fee-spike buffer logic across the codebase, run the new regression test, and consider whether any deployed nodes need to update to avoid accepting HTLCs that could leave the funder unable to cover commitment transaction fees during fee spikes.

Security signals we found

01

Fee-spike buffer accounting bug

02

HTLC dust trimming at spiked feerate

03

Channel funder reserve/balance validation

04

Potential channel force-close or fund loss if funder cannot cover commitment tx fee

05

New regression test added for the fixed behavior

Risk score

Why this scored 60/100

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