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

Don't check for no-outputs under fee spikes in `get_available_balances`

Public commit record

What the developer wrote

Authored by Leo Nash

73/100 · Adequate
Don't check for no-outputs under fee spikes in `get_available_balances`

We only assume fee spikes in legacy channels, and we do not allow
`holder_selected_channel_reserve_satoshis` to be set to zero in such
channels. It is nonetheless still possible to reach the no-outputs case
in a fee spike with solely the counterparty selected reserve set to
zero, so we still guard against this case in
`get_next_commitment_stats`.

We don't guard against no-outputs under fee spikes
`get_available_balances`; in the worst case, the receiver of the HTLC we
just sent fails it back.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit relaxes a safety check in how Lightning channels calculate available balances during fee spikes. Previously, the code tried to ensure a commitment transaction would still have at least one output even if fees spiked. The change says that for one specific calculation (get_available_balances), it's okay not to guard against the 'no outputs' case under fee spikes, because the worst outcome is that an HTLC you just sent gets failed back by the receiver. The change keeps the stricter guard in another function (get_next_commitment_stats).

Recommended action

Review whether dropping the no-outputs guard under fee spikes in get_available_balances could allow a channel state where a commitment transaction becomes unbroadcastable or uneconomic. Confirm the assumption that holder-selected reserve cannot be zero in legacy channels holds across all supported channel versions. Consider adding tests for the zero counterparty reserve + fee spike edge case.

Security signals we found

01

Fee spike handling logic changed

02

No-outputs guard removed from balance availability calculation

03

Legacy channel assumptions used to justify relaxed check

04

Counterparty-selected zero reserve still guarded elsewhere

05

Worst-case outcome described as HTLC failure

Risk score

Why this scored 45/100

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