Skip to content

Always-online node forward invoice request #4049

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Sep 15, 2025
Merged

Always-online node forward invoice request #4049

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d1d51b3
Update OnionMessage with link to BOLTs
elnosh Aug 28, 2025
d810708
Use correct nonce in InvoiceRequest context
elnosh Aug 29, 2025
f46a3ff
Forward invoice requests to async recipient
elnosh Aug 29, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 1 addition & 2 deletions lightning-types/src/features.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,8 +54,7 @@
//! - `SimpleClose` - requires/supports simplified closing negotiation
//! (see [BOLT-2](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#closing-negotiation-closing_complete-and-closing_sig) for more information).
//! - `OnionMessages` - requires/supports forwarding onion messages
//! (see [BOLT-7](https://github.com/lightning/bolts/pull/759/files) for more information).
// TODO: update link
//! (see [BOLT-4](https://github.com/lightning/bolts/blob/master/04-onion-routing.md#onion-messages) for more information).
//! - `ChannelType` - node supports the channel_type field in open/accept
//! (see [BOLT-2](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) for more information).
//! - `SCIDPrivacy` - supply channel aliases for routing
Expand Down
26 changes: 21 additions & 5 deletions lightning/src/events/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ pub mod bump_transaction;

pub use bump_transaction::BumpTransactionEvent;

use crate::blinded_path::message::OffersContext;
use crate::blinded_path::message::{BlindedMessagePath, OffersContext};
use crate::blinded_path::payment::{
Bolt12OfferContext, Bolt12RefundContext, PaymentContext, PaymentContextRef,
};
Expand All @@ -28,6 +28,7 @@ use crate::ln::channelmanager::{InterceptId, PaymentId, RecipientOnionFields};
use crate::ln::types::ChannelId;
use crate::ln::{msgs, LocalHTLCFailureReason};
use crate::offers::invoice::Bolt12Invoice;
use crate::offers::invoice_request::InvoiceRequest;
use crate::offers::static_invoice::StaticInvoice;
use crate::onion_message::messenger::Responder;
use crate::routing::gossip::NetworkUpdate;
Expand Down Expand Up @@ -1654,6 +1655,13 @@ pub enum Event {
/// The invoice that should be persisted and later provided to payers when handling a future
/// [`Event::StaticInvoiceRequested`].
invoice: StaticInvoice,
/// The path to where invoice requests will be forwarded. If we receive an invoice
/// request, we'll forward it to the async recipient over this path in case the
/// recipient is online to provide a new invoice. This path should be persisted and
/// later provided to [`ChannelManager::respond_to_static_invoice_request`].
///
/// [`ChannelManager::respond_to_static_invoice_request`]: crate::ln::channelmanager::ChannelManager::respond_to_static_invoice_request
invoice_request_path: BlindedMessagePath,
Copy link
Contributor

@valentinewallace valentinewallace Sep 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if it's awkward that we have a raw BlindedMessagePath here but use a Responder below... Not blocking though.

Copy link
Contributor Author

@elnosh elnosh Sep 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm yeah can be a bit awkward. I used a BlindedMessagePath since that is how it's sent in the ServeStaticInvoice message. And if passed as a Responder I think I would still need to use it as a BlindedMessagePath to build the MessageSendInstructions::WithSpecifiedReplyPath

/// Useful for the recipient to replace a specific invoice stored by us as the static invoice
/// server.
///
Expand Down Expand Up @@ -1686,12 +1694,14 @@ pub enum Event {
///
/// If we previously persisted a [`StaticInvoice`] from an [`Event::PersistStaticInvoice`] that
/// matches the below `recipient_id` and `invoice_slot`, that invoice should be retrieved now
/// and forwarded to the payer via [`ChannelManager::send_static_invoice`].
/// and forwarded to the payer via [`ChannelManager::respond_to_static_invoice_request`].
/// The invoice request path previously persisted from [`Event::PersistStaticInvoice`] should
/// also be provided in [`ChannelManager::respond_to_static_invoice_request`].
///
/// [`ChannelManager::blinded_paths_for_async_recipient`]: crate::ln::channelmanager::ChannelManager::blinded_paths_for_async_recipient
/// [`ChannelManager::set_paths_to_static_invoice_server`]: crate::ln::channelmanager::ChannelManager::set_paths_to_static_invoice_server
/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest
/// [`ChannelManager::send_static_invoice`]: crate::ln::channelmanager::ChannelManager::send_static_invoice
/// [`ChannelManager::respond_to_static_invoice_request`]: crate::ln::channelmanager::ChannelManager::respond_to_static_invoice_request
StaticInvoiceRequested {
/// An identifier for the recipient previously surfaced in
/// [`Event::PersistStaticInvoice::recipient_id`]. Useful when paired with the `invoice_slot` to
Expand All @@ -1702,10 +1712,16 @@ pub enum Event {
/// retrieve the [`StaticInvoice`] requested by the payer.
invoice_slot: u16,
/// The path over which the [`StaticInvoice`] will be sent to the payer, which should be
/// provided to [`ChannelManager::send_static_invoice`] along with the invoice.
/// provided to [`ChannelManager::respond_to_static_invoice_request`] along with the invoice.
///
/// [`ChannelManager::send_static_invoice`]: crate::ln::channelmanager::ChannelManager::send_static_invoice
/// [`ChannelManager::respond_to_static_invoice_request`]: crate::ln::channelmanager::ChannelManager::respond_to_static_invoice_request
reply_path: Responder,
/// The invoice request that will be forwarded to the async recipient to give the
/// recipient a chance to provide an invoice in case it is online. It should be
/// provided to [`ChannelManager::respond_to_static_invoice_request`].
///
Copy link
Collaborator

@TheBlueMatt TheBlueMatt Sep 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Presumably we should document here that LSPs should try to use LSPS5 to wake the client (based on the invoice_request_path first-hop, presumably? or is there a place where the LSP sees the counterparty node id? I don't see one in PersistStaticInvoice). From there the LSP should give them a second to come online before calling respond_to_static_invoice_request to make sure they have a shot at receiving the message.

Copy link
Collaborator

@TheBlueMatt TheBlueMatt Sep 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed it more with @valentinewallace really I think we need to be pushing the forwarded static invoice requests through the OnionMessenger forwarding pipeline (so we use the onion message mailbox logic and so that we avoid the direct-peer-connect logic) rather than the sending pipeline.

Copy link
Contributor Author

@elnosh elnosh Sep 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LSPs should try to use LSPS5 to wake the client (based on the invoice_request_path first-hop, presumably?

I was wondering why not this approach instead of the mailbox logic? It could be weird to have this flow outside of the mailbox but as you said it would allow the LSP to wake up the client before deciding to call respond_to_static_invoice_request to send the static invoice back. Which with the mailbox I think it will do both at the same time - generate the OnionMessageIntercepted event and send back the static invoice unless we separate them.

Also, in any of the 2 approaches, although I would think most likely the introduction node of the invoice_request_path will be the LSP, there's no way to guarantee that. So we would also need to first check the first hop and if it's not the LSP, just send the message?

Copy link
Collaborator

@TheBlueMatt TheBlueMatt Sep 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be in addition/conjunction with the mailbox logic. LSPS5 is just a way to tell the client to run by sending a notification, we'd still have to keep the pending message in the mailbox so that we can deliver it when they come online.

/// [`ChannelManager::respond_to_static_invoice_request`]: crate::ln::channelmanager::ChannelManager::respond_to_static_invoice_request
invoice_request: InvoiceRequest,
},
/// Indicates that a channel funding transaction constructed interactively is ready to be
/// signed. This event will only be triggered if at least one input was contributed.
Expand Down
Loading
Loading