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

Merge PR 'Defer splice_locked during RBF signing' (#4891)

Public commit record

What the developer wrote

Authored by Matt Corallo

81/100 · Strong
Merge PR 'Defer splice_locked during RBF signing' (#4891)

from delay-splice-promotion-inflight-rbf-negotiation into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4891
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit fixes a timing bug in Lightning Dev Kit's splicing code. Previously, a node could prematurely send a 'splice_locked' message and promote an older splice transaction to active while a replacement transaction was still being signed through RBF. The patch defers sending splice_locked until the RBF signing round completes and the channel is no longer quiescent, then releases the lock on a timer tick. This prevents inconsistent channel states between peers and avoids potential fund loss or channel closure from conflicting funding transactions.

Recommended action

Review and merge if not already merged; ensure downstream users running splicing/RBF pick up this commit. No immediate emergency response is warranted, but the fix should be included in the next release because it prevents a real consensus/state inconsistency between channel peers.

Security signals we found

01

Prevents premature splice funding promotion during incomplete RBF signing

02

Defers splice_locked emission until quiescence ends

03

Adds timer-driven release of deferred splice_locked

04

Refactors promotion handling to avoid duplicate code paths

05

Adds regression test covering reload, async monitor, async signer, and early peer lock cases

Risk score

Why this scored 44/100

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