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

Allow acceptor contribution to RBF splice via tx_init_rbf

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

73/100 · Adequate
Allow acceptor contribution to RBF splice via tx_init_rbf

Previously, the tx_init_rbf acceptor always contributed zero to the RBF
transaction. This is incorrect when both parties try to RBF
simultaneously and one loses the quiescence tie-breaker — the loser
becomes the acceptor but still has a pending QuiescentAction::Splice
with inputs/outputs that should be included in the RBF transaction.

Consume the acceptor's QuiescentAction in the tx_init_rbf handler, just
as is already done in the splice_init handler, and report the
contribution in the TxAckRbf response.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a bug in Lightning Dev Kit's splicing/RBF (Replace-By-Fee) logic. When both channel partners tried to update a splice at the same time, the loser of a tie-breaker was supposed to contribute its inputs/outputs as the 'acceptor' of the RBF transaction, but the code incorrectly made the acceptor contribute nothing. The patch makes the acceptor include its queued splice contribution in the RBF transaction and report it in the response. It is a protocol-correctness bug that could cause stuck or inconsistent splice states, but it is not a clear theft-of-funds vulnerability.

Recommended action

Review and merge. This is a protocol-correctness fix for dual-initiated RBF splices. Monitor for any related edge cases around QuiescentAction lifecycle and ensure the new tests cover the main feerate/budget branches. No emergency response is indicated, but nodes running splicing/RBF should update to avoid stuck splice states.

Security signals we found

01

Protocol state inconsistency: acceptor's pending QuiescentAction::Splice was ignored during RBF, leading to incomplete funding transactions.

02

Funds-flow correctness: acceptor inputs/outputs and funding_output_contribution are now included in TxAckRbf, preventing omitted splice contributions.

03

No explicit authentication/authorization bypass, memory safety issue, or cryptographic flaw in the diff.

04

Test-only helper changes (remove_watched_by_txid, lock_splice signature change) are not production security signals.

Risk score

Why this scored 46/100

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