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

lnwallet/chancloser: record the remote close output only when accepted

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

73/100 · Adequate
lnwallet/chancloser: record the remote close output only when accepted

In this commit, we hold off on recording the remote party's close output until
we've decided we can act on their Shutdown. ReceiveShutdown wrote the field
before it looked at the state, so a Shutdown that arrives at a point where we
have nothing to do with it, say once we've already finished the negotiation,
would still overwrite the output we settled on before being turned away with
ErrInvalidState. The output we report for the close then describes a message we
rejected.

Nothing acts on this today, as we hand the outputs to the caller only after
ClosingTx tells it the negotiation finished, but the field is what we report to
the party that asked for the close, so we may as well only fill it in from a
message we accepted.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This change fixes a bookkeeping bug in how LND records the other party's preferred closing address during a channel close. Previously, a late or unexpected Shutdown message could overwrite the correct address with one from a message that was rejected. The fix only saves the address when the message is actually accepted. The bug currently has no downstream effect because the recorded value is not used until after negotiation finishes, but it makes the close record more accurate.

Recommended action

Apply the patch. It is a low-risk correctness fix. No immediate incident response is required, but operators should keep LND up to date. Review whether any monitoring or reporting that consumes remoteCloseOutput could have shown inconsistent close addresses prior to this fix.

Security signals we found

01

State variable written before validation

02

Rejected message could overwrite accepted close output

03

Fix prevents stale/incorrect close metadata

04

No active exploitation path identified in diff

Risk score

Why this scored 29/100

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