What changed, and why it matters
This commit adds a new Lightning protocol feature flag called HtlcHold to the rust-lightning code, but does not actually turn it on or use it yet. It is preparatory code for a future capability that lets an often-offline sender's payment be held by a counterparty until the recipient comes back online. There is no active security flaw here—just a new feature bit being registered so nodes can later advertise support.
No immediate security action needed. Treat as normal feature groundwork. When the full HtlcHold implementation arrives, review it carefully for HTLC timeout handling, preimage release conditions, and onion-message authentication, since holding HTLCs changes the trust and timing assumptions of payment forwarding.
Security signals we found
New experimental feature bit registration only
No functional HTLC-holding logic added
No advertisement of support enabled
References an in-progress BOLTs specification change (PR 989)
Evidence from the diff
The change registers an experimental feature bit (1053, derived from BOLTs PR 989 bits 52/53 plus 1000 for the experimental range) in lightning-types/src/features.rs. It adds HtlcHold to InitContext and NodeContext feature maps, generates setter/getter methods, and updates documentation. The commit explicitly states ‘We don’t yet advertise support of this feature,’ so no runtime behavior changes. It is a protocol-capability placeholder.
Changed components
lightning-types/src/features.rsInspect captured patch +21 / −0
diff --git a/lightning-types/src/features.rs b/lightning-types/src/features.rs
index 148242e..84538ad 100644
--- a/lightning-types/src/features.rs
+++ b/lightning-types/src/features.rs
@@ -82,6 +82,8 @@
//! (see [BOLT PR #1228](https://github.com/lightning/bolts/pull/1228) for more info).
//! - `Splice` - Allows replacing the currently-locked funding transaction with a new one
//! (see [BOLT PR #1160](https://github.com/lightning/bolts/pull/1160) for more information).
+//! - `HtlcHold` - requires/supports holding HTLCs and forwarding on receipt of an onion message
+//! (see [BOLT-2](https://github.com/lightning/bolts/pull/989/files) for more information).
//!
//! LDK knows about the following features, but does not support them:
//! - `AnchorsNonzeroFeeHtlcTx` - the initial version of anchor outputs, which was later found to be
@@ -166,6 +168,10 @@ mod sealed {
ZeroConf,
// Byte 7
Trampoline | SimpleClose | Splice,
+ // Byte 8 - 130
+ ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
+ // Byte 131
+ HtlcHold,
]
);
define_context!(
@@ -191,6 +197,10 @@ mod sealed {
,,,,,,,,,,,,,,,,,,,,,,,,
// Byte 32
DnsResolver,
+ // Byte 33 - 130
+ ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
+ // Byte 131
+ HtlcHold,
]
);
define_context!(ChannelContext, []);
@@ -700,6 +710,17 @@ mod sealed {
supports_dns_resolution,
requires_dns_resolution
);
+ define_feature!(
+ 1053, // The BOLTs PR uses feature bit 52/53, so add +1000 for the experimental bit
+ HtlcHold,
+ [InitContext, NodeContext],
+ "Feature flags for holding HTLCs and forwarding on receipt of an onion message",
+ set_htlc_hold_optional,
+ set_htlc_hold_required,
+ clear_htlc_hold,
+ supports_htlc_hold,
+ requires_htlc_hold
+ );
// Note: update the module-level docs when a new feature bit is added!
Why this scored 20/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.