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

Lower strictness of pending monitor update while awaiting tx_signatures

Public commit record

What the developer wrote

Authored by Wilmer Paulino

73/100 · Adequate
Lower strictness of pending monitor update while awaiting tx_signatures

We previously assumed that no monitor update should ever be pending when
receiving `tx_signatures` while quiescent, with the exception of the
`RenegotiatedFunding` variant. This was a bit too strict, as we did not
consider that if an HTLC was sent via the same channel, its preimage
could be received from upstream leading to a monitor update to durably
persist it.

This commit ensures that if the recipient of a `tx_signatures` has not
yet echoed theirs back, and it is awaiting a monitor update completion,
then the pending monitor update must be of the `RenegotiatedFunding`
variant. If the pending monitor update is of another variant, then we
must remain quiescent with no pending updates available to send until
after the `tx_signatures` exchange.
✓ 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 logic bug in the Lightning Dev Kit's channel splicing code. Previously, the code wrongly assumed that no unrelated monitor update could be pending when a splice `tx_signatures` message arrived while the channel was quiescent. In reality, an unrelated HTLC preimage could trigger a pending monitor update at the same time. The fix relaxes the strictness so the protocol does not panic or get stuck, and adds a regression test covering the scenario.

Recommended action

Review the relaxed assertions to ensure they fully cover all monitor update variants that may legitimately be pending during `tx_signatures` handling. Run the new regression test and fuzzing around splice + HTLC preimage races. Consider whether any other quiescence checks elsewhere make the same overly strict assumption.

Security signals we found

01

Assertion relaxation in state-machine handling of splice `tx_signatures`

02

Race condition between unrelated HTLC preimage monitor update and splice signature exchange

03

Potential panic or protocol stall due to overly strict debug assertion

04

Regression test added for async monitor update during splicing

Risk score

Why this scored 57/100

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