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

Introduce `FundingTransactionReadyForSignatures` event

Public commit record

What the developer wrote

Authored by Duncan Dean

63/100 · Adequate
Introduce `FundingTransactionReadyForSignatures` event

The `FundingTransactionReadyForSignatures` event requests witnesses
from the client for their contributed inputs to an interactively
constructed transaction.

The client calls `ChannelManager::funding_transaction_signed` to provide
the witnesses to LDK.

The `handle_channel_resumption` method handles resumption from both
a channel re-establish and a monitor update. When the corresponding
monitor update for the commitment_signed message completes, we will
push the event here.

We can thus only ever provide holder signatures after a monitor update
has completed.

We can also get rid of the reestablish code involved with
`monitor_pending_tx_signatures` and remove that field too.
✓ Specific, descriptive subject✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new event that asks the wallet/user to sign inputs they contributed to a jointly-built Lightning channel funding transaction. It also changes when LDK sends its own signatures so that signatures are only provided after the channel monitor has been safely persisted. The change is a feature addition with safety improvements, not a fix for an active bug or known exploit.

Recommended action

Review the new `funding_transaction_signed` API and event handling in downstream integrations; ensure wallet code only signs the exact `unsigned_transaction` provided and uses `SIGHASH_ALL`. No urgent patch is required, but monitor for follow-up commits that complete async-signing TODOs.

Security signals we found

01

New event-driven signing flow for holder-contributed inputs

02

Removal of monitor_pending_tx_signatures field and deferred-signature logic

03

Signatures now gated on monitor persistence via handle_channel_resumption

04

Addition of has_received_tx_signatures to reject duplicate tx_signatures messages

05

SIGHASH_ALL requirement documented for contributed input signatures

06

Warning about counterparty non-standard inputs documented

Risk score

Why this scored 34/100

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