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

openingd: bound funding_satoshis by total bitcoin supply

Public commit record

What the developer wrote

Authored by Matt Morehouse

93/100 · Strong
openingd: bound funding_satoshis by total bitcoin supply

funding_satoshis values above the total bitcoin supply were not rejected
during open_channel/accept_channel negotiation and would later cause
libwally to fail and openingd to crash during commitment transaction
construction.

Reject such funding_satoshis values immediately so that the negotiation
terminates gracefully.

Fixes: #9225
Changelog-Fixed: `openingd` no longer crashes when a peer opens a channel with a `funding_satoshis` value greater than the total bitcoin supply.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This update fixes a bug in Core Lightning's channel-opening code. A malicious or misconfigured peer could send an impossibly large channel funding amount. Previously, the software accepted the value during negotiation and only crashed later when it tried to build a real Bitcoin transaction. Now, these oversized values are rejected immediately and the negotiation ends cleanly instead of crashing the opening daemon.

Recommended action

Apply the patch and run the new regression test. Nodes accepting inbound channel opens should prioritize this fix because any reachable peer can trigger the crash. Consider backporting to maintained release branches.

Security signals we found

01

Denial-of-service vector: remote peer can trigger openingd crash/assertion failure via malformed funding_satoshis

02

Input validation gap: funding_satoshis above total Bitcoin supply accepted during negotiation

03

Downstream invariant failure: libwally refuses to build transaction with output exceeding max supply, causing assertion crash

04

Fix centralizes funding bound logic and applies it consistently across v1 and v2/dual-funding open paths

05

Regression test explicitly exercises funding_satoshis = MAX_SUPPLY_SAT + 1, MAX_SUPPLY_SAT * 2, and UINT64_MAX

Risk score

Why this scored 68/100

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