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

Allow overriding `max-closing-feerate` with `forceclose` API (#3142)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

81/100 · Strong
Allow overriding `max-closing-feerate` with `forceclose` API (#3142)

We introduced a mechanism to limit the feerate used for non-urgent
force-close transactions in #3097. We now provide a way to update
this feerate on a per-channel basis, without restarting the eclair
node, by using the `forceclose` API.

Fixes #3108.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit adds an optional API parameter to the Eclair Lightning node that lets an operator override the maximum on-chain fee rate when force-closing a channel. It is a feature enhancement, not a fix for a known vulnerability. The change gives node operators more control over how quickly force-close transactions confirm, but it does not by itself create a way for an outsider to steal funds or take over the node. The main security consideration is that a user who sets the override too high could pay unexpectedly large transaction fees during a force close.

Recommended action

Treat as a routine feature commit. Reviewers should verify that the new maxClosingFeerate override is validated against a reasonable upper bound before use, that authenticated API access is still required, and that the override cannot be set by an unauthorized peer protocol message. Operators should be warned in documentation that raising the limit can lead to high on-chain fees.

Security signals we found

01

New API parameter influences on-chain fee rate for force-close transactions

02

Override stored per-channel in closing state and propagated to claim transaction construction

03

No input sanitization logic shown beyond existing FeeratePerByte/FeeratePerKw types

04

No authentication or authorization changes in the API handler

05

No buffer overflow, memory corruption, or cryptographic weakness visible in diff

Risk score

Why this scored 26/100

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