Delay HTLC txs in 0FC channels until both commit and anchor txs confirm
What changed, and why it matters
This change adjusts how Lightning Dev Kit handles zero-fee commitment (0FC) channels. Previously, the code only delayed broadcasting HTLC (payment) claim transactions for older CSV anchor channels until the commitment transaction confirmed. Now it does the same for newer 0FC channels. The commit notes that, in theory, HTLC claims could be bundled together with the anchor-spend transaction before the commitment confirms, but that optimization is left for future work. The practical effect is a more conservative on-chain behavior that avoids potential race conditions or invalid transactions.
Review whether the deferred aggregation of HTLC claims with the P2A anchor spend is tracked as a follow-up issue, and ensure tests cover the delayed-broadcast path for 0FC channels. No immediate user action is required beyond staying current with releases.
Security signals we found
Behavior change in on-chain transaction broadcast timing for 0FC channels
Avoids broadcasting HTLC claim transactions before commitment confirmation
Prevents potential invalid or premature transaction publication
Acknowledged TODO that a more efficient aggregation path exists but is not implemented
Evidence from the diff
In ChannelMonitorImpl::broadcast_latest_holder_commitment_txn, the guard that decides whether to immediately broadcast HTLC claim transactions was expanded. Previously it only checked supports_anchors_zero_fee_htlc_tx(); now it also checks supports_anchor_zero_fee_commitments(). If either zero-fee HTLC or zero-fee commitment anchor feature is present, HTLC transactions are deferred until transactions_confirmed observes the commitment on-chain. The commit message explicitly states this is a temporary imitation of CSV anchor channel behavior and that combining HTLC claims with the P2A anchor spend in one transaction is possible but deferred.
Changed components
lightning/src/chain/channelmonitor.rsChannelMonitorImpl::broadcast_latest_holder_commitment_txn0FC (zero-fee commitment) anchor channelsInspect captured patch +12 / −4
diff --git a/lightning/src/chain/channelmonitor.rs b/lightning/src/chain/channelmonitor.rs
index d394a0f..51a179c 100644
--- a/lightning/src/chain/channelmonitor.rs
+++ b/lightning/src/chain/channelmonitor.rs
@@ -3950,10 +3950,18 @@ impl<Signer: EcdsaChannelSigner> ChannelMonitorImpl<Signer> {
// new channel updates.
self.holder_tx_signed = true;
let mut watch_outputs = Vec::new();
- // We can't broadcast our HTLC transactions while the commitment transaction is
- // unconfirmed. We'll delay doing so until we detect the confirmed commitment in
- // `transactions_confirmed`.
- if !funding.channel_type_features().supports_anchors_zero_fee_htlc_tx() {
+ // In CSV anchor channels, we can't broadcast our HTLC transactions while the commitment transaction is
+ // unconfirmed.
+ // We'll delay doing so until we detect the confirmed commitment in `transactions_confirmed`.
+ //
+ // TODO: For now in 0FC channels, we also delay broadcasting any HTLC transactions until the commitment
+ // transaction gets confirmed. It is nonetheless possible to add HTLC spends to the P2A spend
+ // transaction while the commitment transaction is still unconfirmed.
+ let zero_fee_htlcs =
+ self.channel_type_features().supports_anchors_zero_fee_htlc_tx();
+ let zero_fee_commitments =
+ self.channel_type_features().supports_anchor_zero_fee_commitments();
+ if !zero_fee_htlcs && !zero_fee_commitments {
// Because we're broadcasting a commitment transaction, we should construct the package
// assuming it gets confirmed in the next block. Sadly, we have code which considers
// "not yet confirmed" things as discardable, so we cannot do that here.
Why this scored 46/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.