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

closingd: add `lightning_simpleclosed` for `option_simple_close`

Public commit record

What the developer wrote

Authored by Níckolas Goline

73/100 · Adequate
closingd: add `lightning_simpleclosed` for `option_simple_close`

New subdaemon implementing the BOLT2 simple close protocol, replacing `lightning_closingd` when `option_simple_close` is negotiated:
- Each peer independently sends `closing_complete` with their fee proposal;
- The other side signs it and sends `closing_sig`;
- Both sides broadcast two conflicting closing transactions and whichever confirms first wins.

Key protocol details:
- Closer pays the fee and closee receives their exact channel balance;
- TLV variants selected per BOLT2: `closer_output_only`, `closer_and_closee_outputs`, `closee_output_only`;
- Sequence 0xFFFFFFFD enables RBF via re-sending `closing_complete`;
- Script mismatch on `closee_scriptpubkey` warns and fails to reconnect;

common/shutdown_scriptpubkey.h/c: removed `static` from `is_valid_op_return` so it can be used in `simpleclosed.c`
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new sub-program (lightning_simpleclosed) to Core Lightning that implements a new, simpler way for two Lightning nodes to agree on closing a payment channel together. It is a feature addition, not a documented security fix. The code introduces new message handling, transaction signing, and fee logic, which naturally carries implementation risk, but the commit message and diff do not describe any known vulnerability or attack.

Recommended action

Treat as a normal feature commit. Reviewers should audit the new simple-close protocol implementation for correct signature verification, fee capping, dust handling, and OP_RETURN edge cases, especially around the closer/closer_amount and closee_amount computations and the two-conflicting-transactions broadcast behavior.

Security signals we found

01

New subdaemon handling channel-close funds and signatures

02

Signature validation on closing_complete / closing_sig via check_tx_sig

03

Fee sanity checks against local/remote balances

04

Scriptpubkey validation and mismatch warnings

05

No vendor disclosure of security relevance in commit or references

Risk score

Why this scored 35/100

Our methodology →
Potential impact 8/30
Exploitability 7/25
Stealth signal 5/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.