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

multi: fix nonce handling bug

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

95/100 · Strong
multi: fix nonce handling bug

In this commit, we fix a nonce handling bug. The bug was unnoticed until
interop testing due to some inadvertent mutation. Before this commit, in
peer/brontide.go, we used the _same_ instance of the musig2 chan closer,
which masked the bug.

The issue was that we would attempt to generate a siganture for the
remote party _before_ we had applied their JIT nonce to our remote (used
to sign their close txn) musig session.

We first created a new test to confirm the issue (in peer, as it needed
to be in order to avoid a circular dep test). Without these changes, the
test fails.

The fix is two fold:
1. Create two independent musig2 chan closers.
2. Update the ordering to apply their nonce before we generate a
signature.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit fixes a bug in LND's cooperative channel-closing code for Taproot channels. When two parties try to close a Lightning channel together, the code accidentally used the same internal helper for both sides and tried to create a signature before the other side's one-time 'nonce' had been applied. The fix creates two separate helpers and reorders the steps so the nonce is applied before signing. The commit message and new test say the bug was hidden in normal use because a shared object masked the ordering problem, and it only surfaced during interoperability testing.

Recommended action

Treat as a security-relevant correctness fix and include in release notes. Users running Taproot channels and the new RBF cooperative close path should upgrade. Review whether the shared-session bug could have led to invalid signatures, failed closes, or protocol-stalling edge cases in earlier versions.

Security signals we found

01

Incorrect nonce ordering in MuSig2 cooperative close signature generation

02

Shared mutable state between local and remote signing sessions masked the ordering issue

03

Regression test added to prevent reintroduction

04

Affects Taproot/RBF cooperative channel close flow only

Risk score

Why this scored 59/100

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