Wait for inbound commitment_signed before producing tx_signatures
What the developer wrote
Authored by Wilmer Paulino
Wait for inbound commitment_signed before producing tx_signatures
We only want to produce `tx_signatures` once we know that the monitor
update (either the initial one for a dual-funded channel, or a
`RenegotiatedFunding` one for a splice) has been persisted. If we
haven't received the counterparty's `commitment_signed` yet, then the
monitor update hasn't been created, leading us to pass the
`!awaiting_monitor_update` condition and produce a holder
`tx_signatures` message.
What changed, and why it matters
This patch fixes a timing issue in Lightning Dev Kit's channel manager. When opening or splicing a dual-funded Lightning channel, LDK could send its transaction signatures too early—before it had received the counterparty's commitment_signed message. Sending signatures prematurely could lead to signing a funding transaction before the necessary security state (the persisted monitor update) is in place, potentially creating a situation where funds are at risk if something goes wrong later. The fix adds a check to wait for the counterparty's commitment_signed before producing the holder's tx_signatures.
Treat this as a security-relevant correctness fix. Users running nodes that open dual-funded channels or perform splicing should upgrade to a release containing this commit. Review related interactive-tx and splice code paths for similar ordering assumptions. No immediate public incident response is indicated by the commit alone, but downstream maintainers should include this in release notes as a bugfix with security implications.
Security signals we found
Premature cryptographic signature generation in funding/splicing flow
Missing state synchronization before sensitive signing operation
Dual-funded channel and splice monitor-update timing dependency
Potential violation of safe signing precondition
Evidence from the diff
In channelmanager.rs, the code that decides whether to produce the holder’s tx_signatures during interactive transaction signing previously only checked that the channel was not awaiting a monitor update and that a signing session existed. However, for dual-funded channel opens and splices (RenegotiatedFunding), the monitor update is created in response to receiving the counterparty’s commitment_signed. If commitment_signed had not yet arrived, the !awaiting_monitor_update guard would pass incorrectly, and LDK would emit holder tx_signatures before the monitor update existed/persisted. The patch adds a filter requiring signing_session.has_received_commitment_signed() before producing tx_signatures, closing the timing window.
Changed components
lightning/src/ln/channelmanager.rsInteractive transaction signing sessionDual-funded channel establishmentSplicing (RenegotiatedFunding) flowHolder tx_signatures message generationInspect captured patch +1 / −0
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 222da4b..e448802 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -9391,6 +9391,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
if let Some(signing_session) = (!channel.is_awaiting_monitor_update())
.then(|| ())
.and_then(|_| channel.context.interactive_tx_signing_session.as_mut())
+ .filter(|signing_session| signing_session.has_received_commitment_signed())
.filter(|signing_session| signing_session.holder_tx_signatures().is_none())
{
if signing_session.has_local_contribution() {
Why this scored 59/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.