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

lightningd: refuse to let a peer open a channel if we have no fee estimates.

Public commit record

What the developer wrote

Authored by Rusty Russell

73/100 · Adequate
lightningd: refuse to let a peer open a channel if we have no fee estimates.

This seems a sensible precaution anyway.

Changelog-Changed: lightningd: we don't allow new incoming channels if we cannot estimate fees (rather than assuming minfee).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This change stops Core Lightning from accepting new incoming payment channels when the node cannot estimate current Bitcoin transaction fees. Previously, the node might accept a channel while assuming a very low fallback fee. That could lead to problems later if the real network fees were much higher, because the channel's agreed fee range might be too low to get transactions confirmed promptly. The patch adds a safety check that rejects incoming channel offers with a clear 'feerates unknown' message until fee estimates become available.

Recommended action

Treat as a hardening/defensive fix with possible security relevance. Review whether any other incoming-channel or splice paths can proceed without feerate estimates, and consider backporting to maintained release branches because the change is small, self-contained, and closes a known risky edge case.

Security signals we found

01

Adds a guard condition that rejects protocol state advancement when a safety-critical input (fee estimate) is missing

02

Applies the guard to both supported channel-open protocol variants (v1 and v2/dual-funding)

03

Explicitly overrides the 'ignore-feerates' developer option for incoming channels, preventing accidental bypass

04

Modifies an existing test that previously expected the old behavior, confirming the change is intentional and behavior-altering

05

Removes an xfail marker from a test named 'test_opening_incoming_unknown_feerates', indicating the previously known/failing scenario is now fixed

Risk score

Why this scored 45/100

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