Enable Creation of Offers and Refunds Without Blinded Path #3246
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3246 +/- ##
==========================================
+ Coverage 89.72% 90.58% +0.86%
==========================================
Files 164 164
Lines 133333 142506 +9173
Branches 133333 142506 +9173
==========================================
+ Hits 119627 129084 +9457
+ Misses 11031 10828 -203
+ Partials 2675 2594 -81 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
lightning/src/ln/offers_tests.rs
Outdated
| assert_eq!(refund.payer_id(), alice_id); | ||
| assert!(refund.paths().is_empty()); | ||
| } | ||
|
|
||
| /// Checks that blinded paths are compact for short-lived offers. | ||
| #[test] | ||
| fn creates_short_lived_offer() { |
There was a problem hiding this comment.
The naming at least for the following tests is no longer relevant, it seems.
There was a problem hiding this comment.
As far as I understand, with the introduction of BlindedPathParameters, it seems like the behavior these tests were checking isn't relevant anymore. Should we think about removing these tests?
There was a problem hiding this comment.
Let's wait on the resolution of #3246 (comment). We'll ultimately want to test cases allowed by whatever interface is exposed to the user.
shaavan
force-pushed
the
blinded_api
branch
from
7a18051 to
bc00884
Compare
|
Updated from pr3246.06 to pr3246.07 (diff): Changes:
|
shaavan
force-pushed
the
blinded_api
branch
from
bc00884 to
3bcc420
Compare
lightning/src/ln/channelmanager.rs
Outdated
| let context = MessageContext::Offers(context); | ||
| let path = $self | ||
| .create_blinded_paths(context) | ||
| .and_then(|paths| paths.into_iter().next().ok_or(())) |
There was a problem hiding this comment.
Hmm... @TheBlueMatt I don't think this interface is sufficient to allow someone to specify they want more than one path in the offer, unless we include all the paths returned by the MessageRouter instead of just one.
There was a problem hiding this comment.
Yea, IMO we should include all paths - if the router wants to do something funky in the offer, so be it.
There was a problem hiding this comment.
What should we have DefaultMessageRouter do?
There was a problem hiding this comment.
What we currently do (use the context of why we're asking for a path to decide how many paths to include)?
There was a problem hiding this comment.
I suppose DefaultMessageRouter could use both MessageContex and BlindedPathType -- or which MessageRouter method is called, if we revert to that state -- to determine if more than one path should be returned. That way we'd allow users to pass BlindedPathType::Full to create_offer_builder such that they can create an offer with more than one path (e.g., when an offer doesn't need to be in a QR code).
There was a problem hiding this comment.
Right, that makes sense but then I'm confused about your previous comment about keeping get interface the same as it is?
There was a problem hiding this comment.
If we change MessageRouter to only have one method, then we need to pass in BlindedPathType. But then the peers parameter will need to be Vec<MessageForwardNode> even when used with BlindedPathType::Full instead of Vec<PublicKey>. So callers could pass in a MessageForwardNode with an scid even though it isn't expected, resulting in the last hop being compact.
There was a problem hiding this comment.
So callers could pass in a MessageForwardNode with an scid even though it isn't expected, resulting in the last hop being compact.
Makes sense! I have reintroduced the two function flow back in pr3246.11
Also, I have updated the DefaultMessageRouter's create_compact_blinded_paths to only return a single path in pr3246.11
There was a problem hiding this comment.
I'm confused why this is a concern, if the MessageRouter insists on a specific type of blinded path in general, so what? Ideally the MessageRouter gets to pick what it wants to do, though I think we're not allowed to have a compact introduction point in reply paths? Even in that case, though, ISTM we can communicate the restrictions and if the MessageRouter is buggy we can just fail.
There was a problem hiding this comment.
I'm confused why this is a concern, if the
MessageRouterinsists on a specific type of blinded path in general, so what? Ideally theMessageRoutergets to pick what it wants to do,
Nothing is preventing a MessageRouter from doing so. It would just need access to the channels.
It's just kinda ugly for DefaultMessageRouter to need to clear short_channel_id depending on how it is called. Plus, ChannelManager needs to do additional lookups to get this information just to have it discarded. I'm fine either way, but it doesn't optimize the usual case (i.e., use non-compact paths for reply paths).
though I think we're not allowed to have a compact introduction point in reply paths? Even in that case, though, ISTM we can communicate the restrictions and if the
MessageRouteris buggy we can just fail.
Yeah, though it doesn't look like we are enforcing this at the moment.
|
I'm definitely okay with having methods to override the router used, and like the changes to not decide in |
It could create compact paths by default if I guess by passing the |
shaavan
force-pushed
the
blinded_api
branch
2 times, most recently
from
7b9b2ea to
49c6c3a
Compare
Right, this is what I was thinking - give the router enough information to decide and let it decide, then let users override the router if they want to override the decision.
I guess if you want to always use a compact path (even for long-lived paths)? Could also have some kind of configurable router that just lets you pick the time limit.
Agreed, it can be a separate function tho. |
|
I see the point you're suggesting, Matt, and I agree there’s some convenience in having the router automatically decide the blinded path type based on The current approach has the benefit of being explicit and predictable. By default, we always generate a full-length path, providing a consistent baseline across all offers. If a user wants a compact path—for example, for short-lived offers—they can opt into it clearly via the router they pass in. Conversely, if the user parameterizes This trades away automatic decision-making by the router in favor of something I believe is more valuable in the long run: user awareness and control. It also avoids introducing heuristics that could surprise users unless they’re quite familiar with the internal logic. In that sense, prioritizing clear defaults and explicit opt-in behavior, I believe, makes the design more intuitive and easier to reason about over time. Curious to hear your thoughts—thanks! |
Regarding this point, I tend to agree that removing the |
There was a problem hiding this comment.
Grr, not sure why I responded to this, sorry.
This trades away automatic decision-making by the router in favor of something I believe is more valuable in the long run: user awareness and control.
I think this is the fundamental disagreement, indeed. While we should always put the user in control, allowing them to do what they want to do, I think the current approach fails the "user awareness" goal. In general, IMO we should assume that users will not read every line of our documentation (there's a ton of it!) but rather will try to call methods and if it works they'll leave it.
In this specific case, I think that the most common use-case for BOLT12 will prefer a more compact QR code/offer as they're receiving a single payment (as most "end users" of lightning will have single LSPs where they have a single channel which has the same SCID alias for its lifetime, splicing in and out as needed but with the SCID alias constant). If the SCID ever does become invalid, a pubkey-based blinded path would become similarly invalid as they are no longer using the same LSP.
Thus, assuming most users will just "do the default thing that works", they're actually going to get something they don't want.
Now, I'm not defending picking it based on the expiry time, in the above scenario, users probably want a compact offer even if it has an extended expiry time, so maybe the right answer is to just keep what we have here and change the default to always use a compact offer.
|
Updated from pr3246.19 to pr3246.20 (diff): Changes:
|
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
Previously, the `compact_paths` flag was only used to determine whether to use a compact introduction node when creating compact blinded paths. With the upcoming change to accept `MessageForwardNode` in `create_blinded_paths`, there's a risk of SCIDs being passed (and used) even when the user intends to create a full-length blinded path. This patch updates the logic in `create_blinded_paths_from_iter` to ignore SCIDs unless `compact_paths` is explicitly true—preserving correct behavior for full-length blinded paths.
To prepare for supporting both standard and compact blinded paths, this commit updates the `create_blinded_paths` function to take a `Vec<MessageForwardNode>` as input. This change ensures the function has all the information it needs to handle both types of blinded path creation. This refactor that sets the stage for upcoming enhancements.
Reasoning: This change aligns `DefaultMessageRouter`'s default behavior with the most common and practical usage: generating compact blinded paths for BOLT12 offers. While configurability is important, most users won't read all documentation and will rely on defaults that "just work." In line with this PR's principle— "One `MessageRouter`, one type of `BlindedPath`"—the previous default would silently produce full blinded paths, even when a compact one would have been more appropriate. In typical setups (e.g., a user connected to a single LSP), the SCID alias remains stable for the channel's lifetime. Compact paths are not only sufficient in this case, but also result in smaller, more efficient offers. And if the alias becomes invalid, a pubkey-based path wouldn't help either—so compact remains the better default. In brief: This commit makes the default behavior match what users actually want. Thanks to [@TheBlueMatt](https://github.com/TheBlueMatt) for the original reasoning. **Discussion link:** [lightningdevkit#3246 (pull request review)](lightningdevkit#3246 (review))
Reasoning: This change aligns `DefaultMessageRouter`'s default behavior with the most common and practical usage: generating compact blinded paths for BOLT12 offers. While configurability is important, most users won't read all documentation and will rely on defaults that "just work." In line with this PR's principle— "One `MessageRouter`, one type of `BlindedPath`"—the previous default would silently produce full blinded paths, even when a compact one would have been more appropriate. In typical setups (e.g., a user connected to a single LSP), the SCID alias remains stable for the channel's lifetime. Compact paths are not only sufficient in this case, but also result in smaller, more efficient offers. And if the alias becomes invalid, a pubkey-based path wouldn't help either—so compact remains the better default. In brief: This commit makes the default behavior match what users actually want. Thanks to [@TheBlueMatt](https://github.com/TheBlueMatt) for the original reasoning. **Discussion link:** [lightningdevkit#3246 (pull request review)](lightningdevkit#3246 (review))
Reasoning: This change aligns `DefaultMessageRouter`'s default behavior with the most common and practical usage: generating compact blinded paths for BOLT12 offers. While configurability is important, most users won't read all documentation and will rely on defaults that "just work." In line with this PR's principle— "One `MessageRouter`, one type of `BlindedPath`"—the previous default would silently produce full blinded paths, even when a compact one would have been more appropriate. In typical setups (e.g., a user connected to a single LSP), the SCID alias remains stable for the channel's lifetime. Compact paths are not only sufficient in this case, but also result in smaller, more efficient offers. And if the alias becomes invalid, a pubkey-based path wouldn't help either—so compact remains the better default. In brief: This commit makes the default behavior match what users actually want. Thanks to [@TheBlueMatt](https://github.com/TheBlueMatt) for the original reasoning. **Discussion link:** [lightningdevkit#3246 (pull request review)](lightningdevkit#3246 (review))
To make the purpose of each `MessageRouter` implementation unambiguous, this commit sets a direction where the type of `MessageRouter` used deterministically defines the kind of blinded paths created. As a step toward this goal, two new default routers are introduced: - `NodeIdMessageRouter` – creates full-length blinded paths using the peer's node ID. - `NullMessageRouter` – intentionally creates no blinded paths.
To allow choosing different message router types for testing nodes, convert `TestMessageRouter` to an enum with variants `DefaultMessageRouter` and `NodeIdMessageRouter`. This provides better flexibility when testing various scenarios.
Reasoning: This change aligns `DefaultMessageRouter`'s default behavior with the most common and practical usage: generating compact blinded paths for BOLT12 offers. While configurability is important, most users won't read all documentation and will rely on defaults that "just work." In line with this PR's principle— "One `MessageRouter`, one type of `BlindedPath`"—the previous default would silently produce full blinded paths, even when a compact one would have been more appropriate. In typical setups (e.g., a user connected to a single LSP), the SCID alias remains stable for the channel's lifetime. Compact paths are not only sufficient in this case, but also result in smaller, more efficient offers. And if the alias becomes invalid, a pubkey-based path wouldn't help either—so compact remains the better default. In brief: This commit makes the default behavior match what users actually want. Thanks to [@TheBlueMatt](https://github.com/TheBlueMatt) for the original reasoning. **Discussion link:** [lightningdevkit#3246 (pull request review)](lightningdevkit#3246 (review))
To simplify blinded path creation and uphold the principle of "One `MessageRouter`, one `BlindedPath` type," this commit updates `create_offer_builder` to use the `create_blinded_paths` method of the `MessageRouter`. Now, when `create_offer_builder` is called, the offer will be created using the `MessageRouter` implementation that the `ChannelManager` or `OffersMessageFlow` is parameterized with. If a user wishes to create an offer with a different type of blinded path, they can explicitly use `create_offer_builder_using_router`, which allows passing a custom `MessageRouter`. The reasoning behind this change is to give users clearer, more deterministic control over the type of blinded path used in the offer. It also improves user awareness, ensuring that creating a non-default blinded path becomes an *intentional choice*.
This change mirrors the previous update to `create_offer_builder`, applying the **“One `MessageRouter`, one `BlindedPath` type”** principle to refund creation. Now, `create_refund_builder` uses the `create_blinded_paths` method of the `MessageRouter` associated with the `ChannelManager` or `OffersMessageFlow`. For non-default path behavior, users can call `create_refund_builder_using_router` and pass a custom `MessageRouter`. See previous commit for detailed reasoning.
This commit completes the series implementing the principle: **“One `MessageRouter`, one `BlindedPath` type.”** As the final step, it removes now-redundant variations of the blinded path creation functions, streamlining the API and simplifying the blinded path creation process.
Introduced tests to validate the behavior of Offers and Refunds created without blinded paths, using `NullMessageRouter`.
PR Description:
An Offer and a Refund can exist without a blinded path, where the
signing_pubkeyis used to determine the destination. While we could already handle Offers and Refunds without a blinded path, we didn’t have a way to create them like this. This PR addresses that gap and simplifies the blinded path creation flow.The Key Changes:
Pass Router to Builders:
Both
create_offer_builderandcreate_refund_buildernow take a router as a parameter. This gives users control over how blinded paths are created. For example, users can now choose not to include any blinded paths, or use a custom router for specific behavior.Unified Blinded Path Creation:
The Blinded Path creation has been simplified by only keeping a single function for Blinded Path creation, i.e.,
create_blinded_path. Older, separate variants likecreate_compact_blinded_pathsandcreate_blinded_paths_using_absolute_expiryare now redundant and have been removed. This makes the flow cleaner and easier to maintain.Router-Driven Flexibility:
The
DefaultMessageRouternow uses aRouterConfigto allow it to create any kind of blinded path (if any) to create. This simplifies the flow, while maintaining the same functionality.This PR makes blinded path creation more straightforward and gives users better control, while preserving the core logic of the
MessageRouter.blocked on #3412