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

Release tx_signatures after async monitor update completes

Public commit record

What the developer wrote

Authored by Wilmer Paulino

100/100 · Strong
Release tx_signatures after async monitor update completes

In 83b2d3e, we reworked `ChannelManager::funding_transaction_signed`
such that it would also for a user to cancel a splice up until they send
`commitment_signed`. Previously, we would would only emit
`Event::FundingTransactionReadyForSigning` when both nodes exchanged
`commitment_signed` and the corresponding monitor update completed. With
the event now being generated immediately after the nodes exchange
`tx_complete`, we now need to handle the monitor update not having
completed by the time we are ready to send `tx_signatures`.
Unfortunately, we also did not have test coverage, allowing this to go
unnoticed until being caught by the fuzzer due to a debug assertion.
Doing so avoids a potential funds-loss scenario if the funding
transaction confirms without the counterparty's signature for our
commitment being durably persisted.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit fixes a bug in the Lightning Dev Kit where, during a special channel operation called splicing, the node could release its signatures for the new funding transaction before the local channel monitor had durably saved the counterparty's signature for the new commitment. If the funding transaction confirmed on-chain while the counterparty's signature was not yet persisted, the node could be left unable to enforce its funds, creating a potential loss of funds scenario. The fix delays sending `tx_signatures` until the asynchronous monitor update completes, and adds tests to cover this case.

Recommended action

Upgrade to a release containing this commit. Nodes using splicing with async signers or slow monitor persistence should prioritize this fix. Review any channels that may have entered the splicing state with pending monitor updates to ensure signatures were released only after persistence completed.

Security signals we found

01

Funds-loss bug in splicing/interactive funding flow

02

Asynchronous monitor update race condition

03

Counterparty commitment signature not durably persisted before funding tx signatures released

04

Debug assertion triggered by fuzzer (noted in commit message)

05

Missing test coverage for async signer + monitor update interaction

Risk score

Why this scored 66/100

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