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

lnwallet/chancloser: revamp sig type parsing to be spec compliant

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

73/100 · Adequate
lnwallet/chancloser: revamp sig type parsing to be spec compliant

In this commit, we revise the sig type parsing to make the control flow
clearer, and also to be spec compliant. Before we would error out if
_both_ the CloserNoClosee and the CloserAndClosee fields were set.

lnwallet/chancloser: fix priority ordering for rbf sig parsing

We need to parse the sigs in a strict order, as it's possible for a
party to send more than one siganture.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes how LND parses signature fields during RBF (fee-bumping) cooperative channel closes. Previously, the code rejected valid protocol messages that contained both a 'closer-only' and a 'both-parties' signature, and it didn't always pick the right signature in the order required by the Lightning spec. The change makes signature selection follow the BOLT specification strictly, which prevents a peer from accidentally or deliberately stalling or breaking a cooperative close by sending a spec-compliant message.

Recommended action

Treat as a bug-fix patch with security relevance for RBF cooperative close reliability. Reviewers should verify that validateSigFields and selectAndExtractSig correctly implement the BOLT spec for all dust/non-dust and taproot combinations, and that the new tests exercise the previously failing both-sigs-present case. Node operators running RBF cooperative close (protocol.rbf-coop-close) should upgrade once this is released.

Security signals we found

01

Protocol compliance fix for RBF cooperative close signature selection

02

Previously rejected valid messages with both CloserNoClosee and CloserAndClosee signatures

03

Added strict BOLT-spec priority ordering for signature extraction

04

Added channel-type mismatch validation between taproot and regular signatures

05

Fixed initialization order of remote MuSig2 nonce before ProposalClosingOpts

06

Expanded integration and unit tests for taproot and both-sigs-present scenarios

Risk score

Why this scored 58/100

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