Clarify CLTV value selection in the first blinded hop marginally
What the developer wrote
Authored by Matt Corallo
Clarify CLTV value selection in the first blinded hop marginally
What changed, and why it matters
This is a one-line code change in how the first hop of a blinded (private) Lightning payment path calculates its expiry deadline. The change switches from using the current accumulated CLTV value to using the starting HTLC offset when computing the final expiry for the first blinded hop. The commit title says it only 'marginally clarifies' the value selection, suggesting it is a minor correctness or readability fix rather than a serious security bug. There is no vendor statement that this is security-relevant, and no independent researcher is credited.
Review the surrounding logic to confirm that starting_htlc_offset is the correct base for the first blinded hop and that cur_cltv was not intended to include upstream delta. If this change affects consensus or protocol behavior, consider regression tests for blinded path CLTV selection. No immediate security response is indicated by the diff alone.
Security signals we found
CLTV expiry value selection changed for first blinded hop
Single-line change in onion payload construction
No explicit security framing by vendor
No CVE, advisory, or researcher attribution present
Change described by commit author as 'marginally' clarifying
Evidence from the diff
In lightning/src/ln/onion_utils.rs, the construction of a blinded receive onion payload for the first blinded hop changes the CLTV expiry passed to OP::new_blinded_receive from cur_cltv + excess_final_cltv_expiry_delta to starting_htlc_offset + excess_final_cltv_expiry_delta. In the surrounding loop, cur_cltv is the running CLTV delta accumulated across hops, while starting_htlc_offset is the initial offset for the HTLC. The commit message frames this as a marginal clarification of CLTV value selection. The change could affect path timing constraints for the first blinded hop, but the diff alone does not demonstrate an exploitable vulnerability such as forced expiry, preimage withholding, or relay failure. It appears to be a correctness/consistency fix.
Changed components
lightning/src/ln/onion_utils.rsBlinded payment route onion constructionCLTV expiry computation for first blinded hopInspect captured patch +1 / −1
diff --git a/lightning/src/ln/onion_utils.rs b/lightning/src/ln/onion_utils.rs
index 5c00368..a74d5fe 100644
--- a/lightning/src/ln/onion_utils.rs
+++ b/lightning/src/ln/onion_utils.rs
@@ -559,7 +559,7 @@ where
OP::new_blinded_receive(
final_value_msat,
recipient_onion.total_mpp_amount_msat,
- cur_cltv + excess_final_cltv_expiry_delta,
+ starting_htlc_offset + excess_final_cltv_expiry_delta,
&blinded_hop.encrypted_payload,
blinding_point.take(),
*keysend_preimage,
Why this scored 23/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.