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

lightningd: wire up `option_simple_close` master-side handling

Public commit record

What the developer wrote

Authored by Níckolas Goline

83/100 · Strong
lightningd: wire up `option_simple_close` master-side handling

Adds the master-side glue for the `simpleclosed` subdaemon and removes the xfail markers from the integration tests:
- simple_close_control.c:
- starts the daemon with feerate bounds and shutdown scripts;
- handles SIMPLECLOSED_GOT_SIG (broadcast closer tx), SIMPLECLOSED_CLOSEE_BROADCAST (broadcast closee tx), and SIMPLECLOSED_COMPLETE (advance state, resolve close RPC)
- channel_control.c: route to peer_start_simpleclosed() instead of peer_start_closingd() when OPT_SIMPLE_CLOSE is negotiated;
- peer_control.c: drop_to_chain_simple_close() sets up the funding-spend watch and resolves the close RPC without broadcasting the commitment tx, avoids it RBF-replacing the mutual close txs;
- resend_closing_transactions() uses the same variant on restart

Changelog-Experimental: Protocol: implement `option_simple_close` (BOLT2) for simpler one-shot mutual close fee negotiation. Enable with --dev-force-features=+60.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit turns on a new experimental Lightning feature called 'simple close' (BOLT2 option_simple_close). It adds the master-side code that starts a new subdaemon, validates mutual-close transactions, stores them, and broadcasts them instead of the older commitment transaction. The change removes 'expected to fail' markers from five integration tests, meaning the feature is now considered functional. It is a protocol implementation patch, not a fix for a known vulnerability, and it is gated behind a developer-only feature flag.

Recommended action

Treat this as a feature-enablement commit rather than an urgent security patch. Reviewers should focus on validation correctness in `close_tx_check()` and signature verification in `handle_simpleclosed_got_sig()` / `handle_simpleclosed_closee_broadcast()`, ensure the HSM permission is only used for legitimate close transactions, and confirm that the no-commitment-broadcast path cannot be triggered in non-simple-close flows. Because it is experimental and behind a dev flag, production risk is low unless the feature flag is enabled.

Security signals we found

01

New subdaemon introduced with HSM signing permission for closing transactions

02

Validation added for mutual close transaction inputs and output scripts

03

Remote signature verification before storing close transaction

04

Prevention of commitment tx broadcast that could RBF-replace mutual close tx

05

Restart retransmission path updated to avoid broadcasting commitment tx

06

Feature is experimental and requires --dev-force-features=+60 to enable

Risk score

Why this scored 37/100

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