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

Rework ChannelManager::funding_transaction_signed

Public commit record

What the developer wrote

Authored by Wilmer Paulino

58/100 · Thin
Rework ChannelManager::funding_transaction_signed

Previously, we'd emit a FundingTransactionReadyForSigning event once the
initial commitment_signed is exchanged for a splicing/dual-funding
attempt and require users to call back with their signed inputs using
ChannelManager::funding_transaction_signed. While this approach worked
in practice, it prevents us from abandoning a splice if we cannot or no
longer wish to sign as the splice has already been committed to by this
point.

This commit reworks the API such that this is now possible. After
exchanging tx_complete, we will no longer immediately send our initial
commitment_signed. We will now emit the
FundingTransactionReadyForSigning event and wait for the user to call
back before releasing both our initial commitment_signed and our
tx_signatures. As a result, the event is now persisted, as there is only
one possible path in which it is generated. Note that we continue to
only emit the event if a local contribution to negotiated transaction
was made.

Future work will expose a cancellation API such that we can abandon
splice attempts safely (we can just force close the channel with
dual-funding).
✓ Descriptive subject✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit reorders the splicing/dual-funding handshake in LDK so that the node does not send its initial commitment signature until after the user has had a chance to sign the funding transaction. Previously, the commitment was sent first, which locked the node into the splice even if the user could not or did not want to sign. The change also makes the 'ready to sign' event persistent across restarts and adds a forward-compatibility note that downgrading while a splice is pending is not supported with async monitor updates. It is a protocol-flow hardening change, not a fix for an active exploit.

Recommended action

Review the new state machine for edge cases around restart and reconnection, ensure the regenerated FundingTransactionReadyForSigning event cannot be duplicated or lost, and verify that the monitor_pending_tx_signatures flag is correctly cleared in all paths. Users relying on splicing/dual-funding should plan upgrades around the downgrade limitation noted in the changelog.

Security signals we found

01

Protocol state machine change: defers commitment_signed until user signs funding transaction

02

Prevents accidental lock-in to a splice before holder has signed

03

Adds persistence for FundingTransactionReadyForSigning event

04

Adds new monitor_pending_tx_signatures state and serialization field

05

Removes old event emission path tied to counterparty commitment_signed

06

Forward-compatibility note: downgrade unsupported with pending splice + async monitor updates

Risk score

Why this scored 33/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 6/15
Confidence 7/10
Evidence quality 3/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.