Do not produce 0FC HTLC txs on `unsafe_get_latest_holder_commitment_txn`
What the developer wrote
Authored by Leo Nash
Do not produce 0FC HTLC txs on `unsafe_get_latest_holder_commitment_txn`
As in CSV anchor channels, HTLC transactions in 0FC channels require
external funding before they can be finalized, so we choose to return
the commitment transaction alone here.
What changed, and why it matters
This change fixes a behavior in the Lightning Dev Kit where, for a newer type of channel (0FC, or zero-fee commitments), the function that retrieves the latest holder commitment transactions was incorrectly returning unfunded HTLC transactions alongside the commitment transaction. These HTLC transactions cannot be used as-is because they need external funding and, in some cases, cannot be broadcast until anchor claims confirm. Returning them could mislead wallet software or automated scripts into trying to broadcast invalid or premature transactions, potentially causing operational errors or failed fund recovery during a channel dispute.
Treat as a low-to-moderate correctness fix. Review any callers of `unsafe_get_latest_holder_commitment_txn` to ensure they handle the returned commitment-only set correctly for 0FC channels and supply external funding for HTLC claims where needed. No immediate emergency response is indicated, but the fix should be included in the next maintenance release.
Security signals we found
Prevents exposure of unfunded, non-broadcastable HTLC transactions for 0FC channels
Avoids potential invalid transaction broadcast by downstream consumers of `unsafe_get_latest_holder_commitment_txn`
Aligns 0FC behavior with existing CSV anchor channel handling
Comment notes TRUC single-child restriction as a current consensus/policy constraint
Function name contains `unsafe_`, indicating caller is expected to understand risks
Evidence from the diff
In ChannelMonitorImpl::unsafe_get_latest_holder_commitment_txn, the code previously returned only the commitment transaction for channels with supports_anchors_zero_fee_htlc_tx (CSV anchor channels), but would fall through and append HTLC transactions for supports_anchor_zero_fee_commitments (0FC) channels. The patch extends the early return to cover 0FC channels as well. The rationale is that 0FC HTLC transactions are zero-fee and require external UTXOs to fund fees before broadcasting; additionally, current TRUC (Topologically Restricted Until Confirmation) rules impose a single-child restriction that prevents broadcasting an HTLC claim while the anchor claim and its parent are unconfirmed. The change is defensive and avoids exposing unusable transactions.
Changed components
lightning/src/chain/channelmonitor.rsChannelMonitorImpl::unsafe_get_latest_holder_commitment_txn0FC (zero-fee commitment) channel typeInspect captured patch +16 / −3
diff --git a/lightning/src/chain/channelmonitor.rs b/lightning/src/chain/channelmonitor.rs
index 405de0b..d394a0f 100644
--- a/lightning/src/chain/channelmonitor.rs
+++ b/lightning/src/chain/channelmonitor.rs
@@ -5131,9 +5131,22 @@ impl<Signer: EcdsaChannelSigner> ChannelMonitorImpl<Signer> {
self.funding.current_holder_commitment_tx.add_holder_sig(&redeem_script, sig)
};
let mut holder_transactions = vec![commitment_tx];
- // When anchor outputs are present, the HTLC transactions are only final once the commitment
- // transaction confirms due to the CSV 1 encumberance.
- if self.channel_type_features().supports_anchors_zero_fee_htlc_tx() {
+
+ if self.channel_type_features().supports_anchors_zero_fee_htlc_tx()
+ || self.channel_type_features().supports_anchor_zero_fee_commitments()
+ {
+ // HTLC transactions in these channels require external funding before finalized,
+ // so we return the commitment transaction alone here.
+ //
+ // In 0FC channels, we *could* use HTLC transactions to pay for fees on a
+ // 0FC commitment transaction to save the fixed transaction overhead
+ // (locktime + version), but we would still have to pay for fees using
+ // external UTXOs to avoid invalidating the counterparty HTLC signature.
+ // This is something we would consider in the future.
+ //
+ // Furthermore, we can't broadcast a HTLC claim transaction while the
+ // anchor claim transaction and its parent are still unconfirmed due to the
+ // current single-child restriction on TRUC transactions.
return holder_transactions;
}
Why this scored 45/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.