Set HTLC tx version 3 on handling `BumpTransactionEvent::HTLCResolution`
What the developer wrote
Authored by Leo Nash
Set HTLC tx version 3 on handling `BumpTransactionEvent::HTLCResolution`
What changed, and why it matters
This commit changes the transaction version used when creating HTLC (Hashed Timelocked Contract) resolution transactions during fee-bumping. For channels that support a specific anchor-based commitment type, the code now uses version 3 instead of version 2. Transaction version 3 enables package relay rules that help ensure child transactions can be broadcast alongside their parents, which is important for anchor-based fee bumping to work reliably on the Bitcoin network. The change appears to be a protocol correctness or compatibility fix rather than a direct vulnerability patch, but using the wrong version could in theory cause transactions to be rejected or fail to propagate, potentially affecting fund recovery in dispute scenarios.
Review whether this change is part of a coordinated protocol update for anchor zero-fee commitments and ensure all related transaction construction paths use consistent version selection. Test HTLC resolution broadcast behavior on networks with package relay / v3 transaction policies. Consider whether a security advisory is warranted if incorrect versions could lead to stuck transactions or delayed fund recovery.
Security signals we found
Transaction version selection tied to channel type features
Anchor zero-fee commitment channel type now requires non-standard version 3 HTLC resolution transactions
Potential relay/policy failure if wrong version is used for anchor channels
No explicit vulnerability language in commit message or diff
Evidence from the diff
In lightning/src/events/bump_transaction/mod.rs, the handle_htlc_resolution method previously constructed HTLC resolution transactions with Version::TWO unconditionally. The patch inspects channel_type_features from the first HTLC descriptor’s channel derivation parameters and selects Version::non_standard(3) when supports_anchor_zero_fee_commitments() is true, otherwise keeping version 2. Bitcoin Core v27+ introduces package relay policy changes (BIP-related) where version 3 transactions are treated as topologically restricted until confirmed (TRUC), which is intended for use with ephemeral anchors and zero-fee commitment transactions. Using version 2 for anchor-zero-fee commitment HTLC resolutions would therefore be inconsistent with the expected transaction topology and relay behavior, potentially causing the transaction to be non-standard or rejected by nodes enforcing v3-only rules for this channel type.
Changed components
lightning/src/events/bump_transaction/mod.rsHTLC resolution transaction constructionBumpTransactionEvent::HTLCResolution handlingAnchor zero-fee commitment channelsInspect captured patch +9 / −1
diff --git a/lightning/src/events/bump_transaction/mod.rs b/lightning/src/events/bump_transaction/mod.rs
index f600397..a5e0874 100644
--- a/lightning/src/events/bump_transaction/mod.rs
+++ b/lightning/src/events/bump_transaction/mod.rs
@@ -849,8 +849,16 @@ where
&self, claim_id: ClaimId, target_feerate_sat_per_1000_weight: u32,
htlc_descriptors: &[HTLCDescriptor], tx_lock_time: LockTime,
) -> Result<(), ()> {
+ let channel_type = &htlc_descriptors[0]
+ .channel_derivation_parameters
+ .transaction_parameters
+ .channel_type_features;
let mut htlc_tx = Transaction {
- version: Version::TWO,
+ version: if channel_type.supports_anchor_zero_fee_commitments() {
+ Version::non_standard(3)
+ } else {
+ Version::TWO
+ },
lock_time: tx_lock_time,
input: vec![],
output: vec![],
Why this scored 44/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.