splice: Change abort rules to sent sigs
What the developer wrote
Authored by Dusty Daemon
splice: Change abort rules to sent sigs
Previous behavior was to fail on abort when we have signatures in the inflight — change this behavior to fail on abort if we have sent our peer our signatures.
What changed, and why it matters
This commit tightens the conditions under which Core Lightning's channel daemon will abort a splice operation. Previously, the daemon treated a splice as unabortable if any signatures existed in the 'inflight' (pending) channel state. Now it only blocks abort if this specific node has actually sent its signatures to the peer. The change is one line and appears aimed at preventing a node from backing out of a splice after it has already committed to it cryptographically, which could otherwise let a malicious or buggy peer exploit inconsistent state.
Treat as a low-to-moderate correctness/security fix. Review the splice state machine to confirm `i_sent_sigs` is set atomically with signature transmission and cannot be spoofed or rolled back. Backport if the project maintains stable branches that include splicing support. No immediate emergency response is warranted based solely on this diff.
Security signals we found
Changes abort policy for a multi-step channel mutation (splice)
Replaces local-state signature check with a peer-transmission check
Prevents abort after cryptographic commitment has been sent
Ties behavior to a specific sent-message flag (`i_sent_sigs`)
Commit message frames change as a correctness fix, not a feature
Evidence from the diff
In channeld/channeld.c, splice_abort() now checks inflight && inflight->i_sent_sigs instead of have_i_signed_inflight(peer, inflight). The old helper likely returned true once signatures were present locally in the inflight object, even if they had not been transmitted. The new condition ties the abort restriction to the network event of having sent signatures (i_sent_sigs), which is a stronger lifecycle signal. This reduces the window in which a node can abort after becoming cryptographically committed, mitigating potential race or state-confusion issues during splicing.
Changed components
channeld/channeld.csplice_abort()Lightning channel splicing protocol implementationInspect captured patch +1 / −1
diff --git a/channeld/channeld.c b/channeld/channeld.c
index eb20158..43914b6 100644
--- a/channeld/channeld.c
+++ b/channeld/channeld.c
@@ -1814,7 +1814,7 @@ static void splice_abort(struct peer *peer, const char *fmt, ...)
reason = tal_vfmt(NULL, fmt, ap);
va_end(ap);
- if (have_i_signed_inflight(peer, inflight))
+ if (inflight && inflight->i_sent_sigs)
peer_failed_err(peer->pps, &peer->channel_id,
"I needed to abort a splice where I have already"
" sent my signatures");
Why this scored 43/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.