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

Store our closing_complete in the simple close session (#3289)

AQda7cd962 View source ↗
Public commit record

What the developer wrote

Authored by Fabrice Drouin

96/100 · Strong
Store our closing_complete in the simple close session (#3289)

In the simple close session, which is never persisted, we just need to remember our closing_complete and
the partial signatures it contains, instead of keeping our musig2 nonces and generating our partial signatures a second time to build the final closing tx when we receive our peer's partial signatures.
We also check our peer's partial signature and fail early if they're not valid, instead of building a fully sign
closing tx and then verify that it is correct.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit changes how Eclair (a Bitcoin Lightning node) remembers its own closing signatures during a mutual channel close. Previously, the code re-generated signing nonces and re-signed closing transactions when the peer's signature arrived. Now it stores the original closing message and reuses its signatures. It also adds an early check that the peer's partial signature is valid before trying to build a final signed transaction. The change is a defensive correctness improvement rather than a clear fix for an active exploit.

Recommended action

Review the new checkRemotePartialSignature implementation and ensure it covers all closing transaction variants. Verify that storing ClosingComplete in volatile memory (simple close session is never persisted, per commit message) does not introduce a crash-recovery issue where a stale or missing closing_complete could lead to force-close. Consider whether the early InvalidCloseSignature failure path correctly updates nonce state to allow negotiation to continue.

Security signals we found

01

MuSig2 nonce handling changed: local partial signatures are now stored and reused instead of regenerated

02

Early signature validation added for peer's partial signature before final transaction aggregation

03

Removed CloserNonces helper that generated three random nonces per closing attempt

04

Potential nonce-reuse class eliminated by storing closing_complete message

Risk score

Why this scored 32/100

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

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 ↗
Low 36 AI analysisMessage 81 · Strong
AQ ACINQEclair BitcoinLightning Network

Bump org.postgresql:postgresql version (#3305)

This commit updates the PostgreSQL database driver used by the Eclair Lightning node software from version 42.7.8 to 42.7.11. The commit message says this fixes a vulnerability that could allow denial-of-service (DoS) attacks if a node con…

Dependency version bump for security fixVendor-disclosed potential DoS vector via untrusted database hostChecksum file updated for reproducible builds
76da19f1by Bastien Teinturier+4−42 files
Vendor flagged security relevance
Open full analysis →Source commit ↗