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

Simple taproot channels (#3103)

AQd8ce91b4 View source ↗
Public commit record

What the developer wrote

Authored by Fabrice Drouin

71/100 · Adequate
Simple taproot channels (#3103)

Implement simple taproot channels

We add new commitment formats and TLV extensions to include musig2 nonces. This includes a specific commitment format for phoenix
taproot channels.

The old v1 channel establishment protocol is updated to include nonces and partial signatures.

The v2 channel estalishment protocol, based on the interactive tx constuction protocol, is also updated, and the
interactive tx session now includes:
- an optional funding nonce for the shared input (i.e. the funding tx that is being spent)
- a nonce for the commit tx that is being created, and another nonce that will become the channel's "next remote nonce" once the session completes
The funding nonce is random and its lifecycle is bound to the interactive session.

Side note: the new v2 protocol is both simpler to extend and gives us support for dual-funding and splices.

Since there can be several different commitment transactions that valid at the same time while splices are pending, revoke_and_ack
and channel_restablish are extended to include a list of funding_tx_id -> nonce tuples (one for each active commitment).

channel_restablish also includes as an optional "current commit nonce": if we got disconnected while a splice was in progress
before both nodes exchanged their commit signatures: if that is the case, we need to re-send our peer's current signature
and will use this nonce to compute it.

We also update the simple close protocol to include closing nonces.

We allow upgrading channels to taproot during splices, with an optional channel_type TLV added to splice_init/splice_ack.
This is not part of the BOLT proposal, and upgrading is currently limited to phoenix taproot channels from phoenix anchor channels.
✓ Descriptive subject✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This is a large feature commit that adds support for a new kind of Bitcoin Lightning channel using Taproot and MuSig2 signatures. It changes how channels are opened, spliced, re-established after disconnections, and closed. The commit is primarily a protocol upgrade, not a stated security fix. However, because it touches sensitive signing logic and introduces new nonce handling, there is a moderate risk that mistakes in the new code could affect channel safety or allow a malicious peer to cause problems. The commit message does not describe this as fixing a known vulnerability.

Recommended action

Treat this as a high-complexity protocol upgrade rather than an urgent security patch. Reviewers should focus on MuSig2 nonce lifecycle correctness: ensure nonces are never reused, are correctly bound to funding transactions and commitment numbers, are validated before partial signatures are accepted, and are properly persisted and retransmitted after reconnection. Pay special attention to splice channel-type upgrades and the new reconnection logic for partially signed transactions. Run the expanded test suite and consider additional fuzzing or cross-implementation interop testing.

Security signals we found

01

New cryptographic signing path using MuSig2 partial signatures and nonces

02

New validation exceptions for missing or invalid commit/funding/closing nonces

03

Protocol message extensions for nonce exchange during channel lifecycle

04

Changes to reconnection retransmission logic for commit_sig and tx_signatures

05

Support for upgrading channel commitment format during splice operations

06

No explicit security bug fix or vulnerability disclosure in commit 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 ↗