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

Resign next remote commit on reconnection (#3157)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

88/100 · Strong
Resign next remote commit on reconnection (#3157)

We previously retransmitted our last `commit_sig` on reconnection if it
hadn't been received by our peer, without changing it. This can be an
issue for taproot channels when remote nodes don't use deterministic
nonce derivation, because their nonce may be different on reconnection
and our previous `commit_sig` would thus not be valid anymore.

We now re-sign the next commitment on reconnection, using the latest
nonces we receive from `channel_reestablish`.
✓ 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 commit fixes a bug in Eclair's Lightning payment channels that use the newer taproot format. When two nodes reconnect after a temporary network interruption, the local node used to resend the exact same cryptographic signature it had sent before. For taproot channels, the remote peer may choose a fresh random 'nonce' after reconnecting, which makes the old signature invalid. The fix makes the local node re-sign the next commitment using the latest nonces received during reconnection, preventing the channel from getting stuck or failing to advance after reconnect.

Recommended action

Treat this as a security-relevant correctness fix. Nodes running taproot channels should upgrade to ensure reconnection signatures are valid and channels do not get stuck or force-closed unnecessarily. Review whether any other code paths still rely on a cached CommitSig after a peer nonce may have changed.

Security signals we found

01

Protocol-level signature invalidation on reconnection for taproot channels

02

Stored CommitSig no longer trusted after peer nonce change

03

Channel synchronization failure risk if old signature is accepted/rejected incorrectly

04

Taproot-specific nonce handling changed in reconnection path

Risk score

Why this scored 60/100

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