Expose the dummy-hop tail constructor publicly
What changed, and why it matters
This commit makes a previously internal helper function public so that outside developers can build dummy-hop tails for blinded payment paths without recreating the logic themselves. It is an API usability change, not a fix for a known security bug. The function's behavior is unchanged; only its visibility and documentation were updated.
No security action required. Treat as a normal API-visibility/documentation change during code review.
Security signals we found
No security-relevant behavior change in the diff
API visibility broadened from crate-public to public
CLTV expiry overflow check already present and unchanged
Entropy source usage unchanged except for naming/test suppression
Evidence from the diff
The patch changes DummyTlvs::new_dummy_tail_from_receive_constraints from pub(crate) to pub in lightning/src/blinded_path/payment.rs. It improves the doc comment, renames _entropy_source to entropy_source, and adds an explicit let _ = entropy_source; under test configuration to avoid unused-variable warnings. The construction logic for dummy hop TLVs and the CLTV overflow check remain identical. No vulnerability is addressed; the change exposes an existing constructor to external callers.
Changed components
lightning/src/blinded_path/payment.rsDummyTlvs::new_dummy_tail_from_receive_constraintsBlindedPaymentPath dummy-hop construction APIInspect captured patch +14 / −7
### lightning/src/blinded_path/payment.rs
@@ -489,21 +489,28 @@ impl DummyTlvs {
Self { payment_relay, payment_constraints }
}
- /// Builds a dummy-hop tail from the receive constraints outward.
+ /// Builds the TLVs for the `num_hops` dummy hops which sit immediately in front of the
+ /// receiving hop of a [`BlindedPaymentPath`], returned in path order.
///
- /// Each dummy hop's constraints depend on the hop after it, so construction starts at the
- /// receive hop and reverses the result into path order. Returns the dummy TLVs and the
- /// upstream-most dummy constraints.
- pub(crate) fn new_dummy_tail_from_receive_constraints<ES: EntropySource>(
- num_hops: usize, receive_constraints: PaymentConstraints, _entropy_source: &ES,
+ /// `receive_constraints` must be the [`PaymentConstraints`] of that receiving hop. Along with
+ /// the TLVs, the [`PaymentConstraints`] which the hop preceding the dummy hops relays into are
+ /// returned, which the caller must use in place of `receive_constraints` when building that
+ /// hop.
+ ///
+ /// Returns `Err(())` if the accumulated CLTV expiry would overflow.
+ pub fn new_dummy_tail_from_receive_constraints<ES: EntropySource>(
+ num_hops: usize, receive_constraints: PaymentConstraints, entropy_source: &ES,
) -> Result<(Vec<Self>, PaymentConstraints), ()> {
+ #[cfg(any(test, feature = "_externalize_tests"))]
+ let _ = entropy_source;
+
let mut dummy_tlvs = Vec::with_capacity(num_hops);
let mut last_payment_constraints = receive_constraints;
for _ in 0..num_hops {
#[cfg(any(test, feature = "_externalize_tests"))]
let payment_relay = Self::default_relay();
#[cfg(not(any(test, feature = "_externalize_tests")))]
- let payment_relay = Self::random_relay(_entropy_source);
+ let payment_relay = Self::random_relay(entropy_source);
let payment_constraints =
Self::derive_payment_constraints(&payment_relay, last_payment_constraints)?;Why this scored 19/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.