Drop spurious limitations section on `pay_for_offer`
What the developer wrote
Authored by Matt Corallo
Drop spurious limitations section on `pay_for_offer`
For some time we've automatically opened a connection to the
blinded path introduction point when we need to send a message we
generated. However, the "Limitations" section in
`ChannelManager::pay_for_offer` lists having a direct connection
as required for the payment to succeed, which is not true.
Instead, we simply remove the section from both `pay_for_offer` and
`pay_for_offer_from_human_readable_name`.
What changed, and why it matters
This commit only removes outdated documentation comments from two functions. The deleted text incorrectly stated that users needed a direct network connection to specific nodes for certain Lightning payments to work. The code already automatically opens those connections, so the documentation was wrong and misleading, but no actual behavior changed. There is no security issue in the code change itself.
No security action needed. This is a documentation-only correction. Reviewers may optionally verify that the auto-connection behavior described in the commit message is indeed implemented elsewhere, but the diff itself introduces no vulnerability.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit deletes two ‘# Limitations’ doc sections from ChannelManager::pay_for_offer and ChannelManager::pay_for_offer_from_human_readable_name in lightning/src/ln/channelmanager.rs. The removed sections claimed a direct connection to an introduction node or issuer signing pubkey was required. The commit message states that the implementation already automatically opens a connection to the blinded path introduction point when sending a generated message, making the documented limitation inaccurate. The diff is -12 lines, all comments; no executable code was modified.
Changed components
lightning/src/ln/channelmanager.rs documentationInspect captured patch +0 / −12
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index fa739ed..162e0e2 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -12303,12 +12303,6 @@ where
/// For payer privacy, uses a derived payer id and uses [`MessageRouter::create_blinded_paths`]
/// to construct a [`BlindedMessagePath`] for the reply path.
///
- /// # Limitations
- ///
- /// Requires a direct connection to an introduction node in [`Offer::paths`] or to
- /// [`Offer::issuer_signing_pubkey`], if empty. A similar restriction applies to the responding
- /// [`Bolt12Invoice::payment_paths`].
- ///
/// # Errors
///
/// Errors if:
@@ -12522,12 +12516,6 @@ where
/// For payer privacy, uses a derived payer id and uses [`MessageRouter::create_blinded_paths`]
/// to construct a [`BlindedMessagePath`] for the reply path.
///
- /// # Limitations
- ///
- /// Requires a direct connection to the given [`Destination`] as well as an introduction node in
- /// [`Offer::paths`] or to [`Offer::issuer_signing_pubkey`], if empty. A similar restriction applies to
- /// the responding [`Bolt12Invoice::payment_paths`].
- ///
/// # Errors
///
/// Errors if a duplicate `payment_id` is provided given the caveats in the aforementioned link.
Why this scored 15/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.