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

openingd: test that channel open seems possible before bothering peer.

Public commit record

What the developer wrote

Authored by Rusty Russell

91/100 · Strong
openingd: test that channel open seems possible before bothering peer.

Fixes: https://github.com/ElementsProject/lightning/issues/4873

In particular, we used to get upset when a peer accepts our channel,
if it was too small! We should do reasonable checks first.

We no longer try to send requests to delay for 2017 blocks though,
so remove that test.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Protocol: trying to create a channel below our own min-capacity-sat will now fail before asking the peer, not with an error blaming the peer when they accept!
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This change fixes a user-experience and protocol-courtesy bug in Core Lightning's channel-opening code. Previously, if you tried to open a channel smaller than your own configured minimum, the node would still ask the peer to open it and then blame the peer when the peer accepted. Now the node checks its own settings first and fails locally with a clear message before bothering the peer. It is not a funds-loss or remote-code-execution vulnerability.

Recommended action

Treat as a normal bug-fix patch. No urgent security action required. Users may upgrade at their usual cadence. Operators should note that channel-open RPC calls below local min-capacity-sat will now fail locally rather than after peer interaction.

Security signals we found

01

Local policy validation moved earlier in protocol flow

02

Prevents misleading peer-blaming error messages

03

No memory safety, cryptographic, or remote-exploitable primitive changed

04

Changelog labels as protocol bug fix, not security vulnerability

Risk score

Why this scored 25/100

Our methodology →
Potential impact 4/30
Exploitability 2/25
Stealth signal 3/15
Affected reach 4/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.