BOLT 12 Offers message handling support (offers, onion messages)
Host: dunxen -
BOLT 12 offers essentially provide a way for a merchant to receive payments through the use of a static identifier (they can be long-lived). Offers do not replace the need for something like invoices, in fact, they work in tandem. Readers of an offer will be able to request invoices via onion messages using a blinded path to the merchant. This provides recipient privacy. In fact, any onion messages, not just for offers, can use a blinded path.
PR #2294 introduces onion message handling for offers so that LDK can interpret offer payloads. It also adds support for actually replying to
onion messages via reply paths in general which is an essential part of the offer protocol and other uses of onion messages. The reader of an
offer would create an
InvoiceRequest payload to send to the merchant (to a blinded path provided in the offer contents) who would then reply
Invoice requesting payment or an
InvoiceError. If an
Invoice is received, the payer can then pay the invoice (also to a blinded path)
or respond with an
A successful flow ┌─────┐ ┌─────┐ │ │ InvoiceRequest │ M │ │ ├───────────►(BP)──►│ E │ │ P │ │ R │ │ A │ Invoice │ C │ │ Y │◄─(BP)─────────────┤ H │ │ E │ (reply path) │ A │ │ R │ │ N │ │ │ payment │ T │ │ ├──────────►(BP)───►│ │ └─────┘ └─────┘ * BP: Blinded Path
The PR adds the
OffersMessageHandler trait where implementors handle incoming
OnionMessages containing an offer message as payload.
ChannelManager implements this trait, but it remains a stub for this PR.
- Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK?
- The PR introduces the
MessageRoutertrait for finding routes for onion messages.
MessageRoute::find_routeimplementations must return a
Vec<PublicKey>when provided a sender
Destination. What is a
Destinationin the onion messages context and which
PublicKeys should an implementor be returning from
find_routea good name? Any other ideas for a name?
- To support replies, onion message handlers were modified to return an optional response message. How does a recipient know where a reply should be sent? When replying do we ever know the original sender (the reply’s recipient) node ID/pubkey?
- Currently a BOLT 11 invoice exposes the payee’s node ID explicitly or via signature recovery. Without BOLT 12 (and blinded paths) and currently doable on the Lightning Network, is there any possible way to gain any level of privacy in this regard, or would the payer always know the payee’s pubkey? How could we at the very least try make the effective payee not seem like the final recipient of the payment?
- We’ve generally covered one kind of payment flow scenario up to now. What other payment flow does BOLT 12 enable and how does this differ to the one we’ve discussed?