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

Extract `CommitParams` to individual commitments (#3118)

AQ49bee72f View source ↗
Public commit record

What the developer wrote

Authored by Bastien Teinturier

93/100 · Strong
Extract `CommitParams` to individual commitments (#3118)

We introduce a new channel codec version where:

- we extract per-commitment parameters (commitment format and params
such as `dust_limit` which we may want to dynamically update in the
future)
- we clean-up the splice iterations on the `Commitments` structure
- we remove the funding transaction from the confirmed local funding
status (once confirmed, we don't need it anymore: it is wasting DB
space for no good reason, we can get it from the blockchain)
- we add a `maxClosingFeerate_opt` to the closing state, to allow
limiting the feerate used in RBF attempts for safe transactions
- we add the commitment format to interactive-tx parameters
- we make channel type feature non permanent

We add a mechanism to prevent the node from starting-up, unless an
override is provided. This provides an opportunity to iterate on codecs
while knowing that node operators won't be affected if we make changes
that are backwards-incompatible. This is meant to be temporary.
✓ 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 is a large internal refactoring of Eclair's Lightning channel data structures. It moves commitment-specific settings (such as dust limits and HTLC limits) from the overall channel parameters into each individual commitment, so future splices can change them. It also removes the full confirmed funding transaction from the local database record, adds a cap on closing fee rates for RBF attempts, and introduces a startup-blocking guard when the database serialization format changes. The commit is not described by the vendor as a security fix; it is a forward-looking infrastructure change with some safety mechanisms.

Recommended action

Treat this as a high-risk infrastructure change rather than an active vulnerability. Operators should not downgrade across this commit because channel database serialization is changed. Reviewers should verify that the new startup guard correctly prevents accidental startup on incompatible DB states, that `ConfirmedFundingTx` removal does not break on-chain transaction reconstruction or fee bumping, and that the TODOs around revoked-commit penalty parameters are addressed before dynamic commitment updates are enabled.

Security signals we found

01

Large data-model refactor of channel state serialization

02

New channel codec version (version5) and startup guard against unsupported codec versions

03

Removal of full confirmed funding transaction from local DB record

04

Addition of maxClosingFeerate_opt to limit RBF closing feerate

05

Per-commitment parameters now stored per commitment, enabling future dynamic updates

06

Multiple TODO comments noting that revoked-commit penalty paths may use wrong toSelfDelay/commitmentFormat after future splices

Risk score

Why this scored 35/100

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

More from Eclair

Related watches

Low 47 AI analysisMessage 88 · Strong
AQ ACINQEclair BitcoinLightning Network

Ignore repeated invalid `tx_signatures` (#3328)

This update changes how the Eclair Lightning node handles repeated bad 'tx_signatures' messages from a peer during dual-funded channel opens and splices. Previously, every bad signature was processed and logged, which could waste CPU and d…

Rate-limiting of invalid peer messages (tx_signatures) to prevent repeated CPU/disk consumptionRemoval of unnecessary DB writes on shutdown receipt, reducing disk-wear and potential DoS surfaceNo channel force-close on invalid signatures; node remains open and waits for on-chain confirmation
823341e6by Bastien Teinturier+74−402 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Informational 22 AI analysisMessage 53 · Thin
AQ ACINQEclair BitcoinLightning Network

Use bitcoin-lib 0.48 (#3316)

This commit updates Eclair's underlying Bitcoin library from version 0.47 to 0.48 and makes small code adjustments to match the new library's API. The changes touch how private keys are derived and how test data is converted. There is no d…

Dependency version bump of cryptographic Bitcoin libraryPrivate key derivation code modifiedTaproot/MuSig2 test vector code adjusted
743dcdd1by Fabrice Drouin+8−44 files
No security note in commit
Open full analysis →Source commit ↗
Low 34 AI analysisMessage 100 · Strong
AQ ACINQEclair BitcoinLightning Network

Add support for zero-fee commitment format (#3192)

This commit adds an experimental new Lightning channel type to Eclair called 'zero-fee commitments.' It is a large feature patch implementing a draft BOLT specification (PR 1228), not a fix for a known vulnerability. The change introduces …

Large feature addition (+1618/-276 across 42 files) touching consensus-sensitive transaction construction and signingNew experimental channel type disabled by default; requires explicit opt-in via eclair.confImplements draft BOLT specification (lightning/bolts#1228), not a finalized standard
35403401by Bastien Teinturier+1618−27642 files
No security note in commit
Open full analysis →Source commit ↗