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

Multiply the feerate by the spike multiple in `can_accept_incoming_htlc`

Public commit record

What the developer wrote

Authored by Leo Nash

73/100 · Adequate
Multiply the feerate by the spike multiple in `can_accept_incoming_htlc`

We choose to multiply `FEE_SPIKE_BUFFER_FEE_INCREASE_MULTIPLE` by the
feerate when checking the fee spike buffer in
`can_accept_incoming_htlc` instead of multiplying the multiple by the
commitment transaction fee. This allows us to delete
`NextCommitmentStats::commit_tx_fee_sat`, and return balances including
the commitment transaction fee in `TxBuilder::get_channel_stats`. This
unblocks a good amount of cleanup.

Note that this means LDK now rejects HTLCs that previous versions of LDK
would have accepted. We made the mirroring change in
`get_available_balances_for_scope` a few commits earlier.

We also now account for non-dust HTLCs turning to dust at the multiplied
feerate, decreasing the overall weight of the transaction.

We also remove other fields in `NextCommitmentStats` which can be easily
calculated in `channel` only.

`TxBuilder::get_channel_stats` could also check the reserve
requirements, given that it gets the reserves in `ChannelConstraints`.
I leave this to follow-up work.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit tightens how Lightning Dev Kit (LDK) checks whether an incoming payment (HTLC) can be safely accepted. It changes the fee-spike buffer calculation so that LDK now rejects more borderline HTLCs than before, reducing the risk that a sudden on-chain fee spike leaves the channel unable to close safely. The change is described by the authors as a stricter policy alignment, not a fix for a known active exploit.

Recommended action

Treat as a hardening/refactoring change rather than an emergency vulnerability fix. Node operators and integrators using LDK should review whether the stricter HTLC acceptance affects their channel liquidity or routing behavior, especially during high-fee regimes. No immediate patch deployment is required solely for security reasons, but staying current with the release that includes this commit is prudent.

Security signals we found

01

Stricter incoming-HTLC acceptance policy to account for on-chain fee spikes

02

Fee-spike buffer now applied to feerate rather than absolute commitment fee

03

Non-dust HTLCs that would become dust under multiplied feerate are now excluded from transaction weight

04

Reserve and fee checks simplified to use post-fee balances

05

Test expectations updated to match new error messages and stricter behavior

Risk score

Why this scored 45/100

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