Queue holder commit once funding tx confirms
What the developer wrote
Authored by Martin Saposnic
Queue holder commit once funding tx confirms
Sets should_broadcast_commitment=true when funding confirms.
Since we skip the initial broadcast when funding_seen_onchain is false,
we need to queue it once funding actually hits the chain.
What changed, and why it matters
This patch fixes a logic gap in Lightning Dev Kit's channel monitoring. When a user manually chooses not to broadcast their side of a new channel immediately, the code was supposed to queue that broadcast for once the funding transaction is seen on the blockchain. Before this fix, the queueing did not happen, so the holder's commitment transaction might never be broadcast automatically. That could leave funds at risk if the counterparty misbehaved after the channel opened.
Treat as a bug-fix patch with potential security relevance for manual-broadcast channel operators. Users relying on manual broadcast should upgrade so that holder commitments are correctly queued once funding confirms. No immediate emergency response is indicated by the diff alone, but downstream integrators should verify their channel-monitor behavior.
Security signals we found
Funds-safety / liveness issue in channel state machine
Missing automatic broadcast of holder commitment after funding confirmation
Manual-broadcast code path only
No explicit vulnerability language in commit message
Evidence from the diff
In ChannelMonitorImpl::block_connected, the code now records funding_seen_before before calling filter_block. After filter_block potentially sets funding_seen_onchain to true, a new check fires when is_manual_broadcast is true, funding was not previously seen, funding is now seen on-chain, and the holder commitment transaction has already been signed. In that case it sets should_broadcast_commitment = true, ensuring the signed holder commitment gets broadcast once the funding transaction confirms. Without this, manual-broadcast channels could fail to ever trigger the holder commitment broadcast, breaking the intended safety fallback.
Changed components
lightning/src/chain/channelmonitor.rsChannelMonitorImpl::block_connectedHolder commitment broadcast logic for manual-broadcast channelsInspect captured patch +6 / −0
diff --git a/lightning/src/chain/channelmonitor.rs b/lightning/src/chain/channelmonitor.rs
index bbf2e5f..6fcc125 100644
--- a/lightning/src/chain/channelmonitor.rs
+++ b/lightning/src/chain/channelmonitor.rs
@@ -5363,6 +5363,7 @@ impl<Signer: EcdsaChannelSigner> ChannelMonitorImpl<Signer> {
F::Target: FeeEstimator,
L::Target: Logger,
{
+ let funding_seen_before = self.funding_seen_onchain;
let txn_matched = self.filter_block(txdata);
if !self.funding_seen_onchain {
@@ -5397,6 +5398,11 @@ impl<Signer: EcdsaChannelSigner> ChannelMonitorImpl<Signer> {
let mut watch_outputs = Vec::new();
let mut claimable_outpoints = Vec::new();
+
+ if self.is_manual_broadcast && !funding_seen_before && self.funding_seen_onchain && self.holder_tx_signed
+ {
+ should_broadcast_commitment = true;
+ }
'tx_iter: for tx in &txn_matched {
let txid = tx.compute_txid();
log_trace!(logger, "Transaction {} confirmed in block {}", txid , block_hash);
Why this scored 57/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.