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

Allow counterparty tx_abort before handling initial commitment signed

Public commit record

What the developer wrote

Authored by Wilmer Paulino

85/100 · Strong
Allow counterparty tx_abort before handling initial commitment signed

Upon processing the counterparty's initial `commitment_signed` for a
splice, we queue a monitor update with the new commitment transactions
spending the new funding transaction. Once handled, funding transaction
signatures can be exchanged and we must start monitoring the chain for a
possible commitment transaction broadcast spending the new funding
transaction. Aborting the splice negotiation then would therefore be
unsafe, hence why we currently force close in such cases. However, there
is no reason to force close prior to receiving their initial
`commitment_signed`, as this would imply the funding transaction
signatures have yet to be exchanged, thus making a commitment broadcast
spending said transaction impossible allowing us to abort the splice
negotiation safely.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This change fixes a Lightning channel splicing behavior where one side would unnecessarily force-close the channel if the counterparty tried to abort a splice before both sides had exchanged their first commitment signatures. Previously, any tx_abort during the signature-waiting phase triggered a force close. The patch makes the protocol more forgiving: aborting is allowed until the counterparty has actually sent its initial commitment_signed, because before that point no dangerous on-chain transaction has been committed to. Once commitment_signed is received, aborting remains unsafe and still triggers a force close. The change also cleans up internal state when aborting early and adds tests for the new behavior.

Recommended action

Review the updated state cleanup paths to ensure no stale interactive_tx_signing_session or pending_splice state remains after an early abort, and verify that monitor updates are not queued prematurely. Run the extended splicing tests under reload and non-reload configurations.

Security signals we found

01

Force-close avoidance in protocol edge case

02

State machine change around commitment_signed receipt

03

Monitor update safety consideration mentioned in commit message

04

New test coverage for splice abort and reconnect/reload paths

Risk score

Why this scored 44/100

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