Enable Creation of Offers and Refunds Without Blinded Path #3246

shaavan · 2024-08-16T08:09:12Z

PR Description:

An Offer and a Refund can exist without a blinded path, where the signing_pubkey is 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_builder and create_refund_builder now 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 like create_compact_blinded_paths and create_blinded_paths_using_absolute_expiry are now redundant and have been removed. This makes the flow cleaner and easier to maintain.
Router-Driven Flexibility:
The DefaultMessageRouter now uses a RouterConfig to 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

codecov · 2024-08-16T08:18:56Z

Codecov Report

Attention: Patch coverage is 96.88312% with 12 lines in your changes missing coverage. Please review.

Project coverage is 90.58%. Comparing base (3da69f7) to head (65401b9).
Report is 26 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/onion_message/messenger.rs	85.71%	5 Missing ⚠️
lightning/src/offers/flow.rs	97.19%	0 Missing and 3 partials ⚠️
lightning/src/ln/channelmanager.rs	96.82%	0 Missing and 2 partials ⚠️
lightning-dns-resolver/src/lib.rs	66.66%	1 Missing ⚠️
lightning/src/ln/offers_tests.rs	99.07%	0 Missing and 1 partial ⚠️

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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

shaavan · 2024-08-19T12:38:27Z

Updated from pr3246.01 to pr3246.02 (diff):

Changes:

Rebase on main to resolve merge conflicts.

shaavan · 2024-08-19T13:29:40Z

Updated from pr3246.02 to pr3246.03 (diff):

Changes:

Fix docs.
Introduce tests for offer and refund with no blinded paths.

shaavan · 2024-08-20T12:17:51Z

Updated from pr3246.03 to pr3246.04 (diff):

Changes:

Rebase on main, to resolve merge conflicts.
Fix CI.

lightning/src/onion_message/messenger.rs

lightning/src/ln/channelmanager.rs

jkczyz · 2024-09-04T03:37:00Z

lightning/src/ln/offers_tests.rs

+	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() {


The naming at least for the following tests is no longer relevant, it seems.

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?

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.

lightning/src/ln/offers_tests.rs

shaavan · 2024-09-04T11:05:53Z

Updated from pr3246.04 to pr3246.05 (diff):

Changes:

Rebase on main.

lightning/src/onion_message/messenger.rs

shaavan · 2024-09-05T20:37:45Z

Updated from pr3246.05 to pr3246.06 (diff):
Addressed @jkczyz comments

Changes:

Removed the global constant PATHS_PLACEHOLDER, and instead use a default constructor, and local DEFAULT_VALUE.
Remove the redundant functions in their appropriate commits.
Use match to avoid mut variables.

shaavan · 2024-09-19T15:40:34Z

Updated from pr3246.06 to pr3246.07 (diff):

Changes:

Introduce a new approach using the BlindedPathType enum.
The enum allows for the specification of the type of Blinded Path (Compact or Full) that a user can specify to create the desired type of Blinded Path.
Update offer_builder and refund_builder so that user can explicitly specify the type of Blinded Path they want to create.
Update the Blinded Path creation flow so that only one function flow is responsible for creating both kinds of Blinded Paths.

shaavan · 2024-09-19T16:03:19Z

Updated from pr3246.07 to pr3246.08 (diff):

Changes:

Rebase on main to resolve merge conflicts.

shaavan · 2024-10-03T12:30:51Z

Updated from pr3246.08 to pr3246.09 (diff):

Changes:

Rebase on main, and fix ci.

lightning/src/onion_message/messenger.rs

jkczyz · 2024-10-04T22:51:51Z

lightning/src/ln/channelmanager.rs

+				let context = MessageContext::Offers(context);
+				let path = $self
+					.create_blinded_paths(context)
+					.and_then(|paths| paths.into_iter().next().ok_or(()))


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.

Yea, IMO we should include all paths - if the router wants to do something funky in the offer, so be it.

What should we have DefaultMessageRouter do?

What we currently do (use the context of why we're asking for a path to decide how many paths to include)?

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).

Right, that makes sense but then I'm confused about your previous comment about keeping get interface the same as it is?

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.

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

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.

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,

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 MessageRouter is buggy we can just fail.

Yeah, though it doesn't look like we are enforcing this at the moment.

lightning/src/ln/channelmanager.rs

lightning/src/onion_message/messenger.rs

shaavan · 2024-10-11T14:28:53Z

Updated from pr3246.09 to pr3246.10 (diff):
Addressed @jkczyz comments

Changes:

Update BlindedPathType documentation.
Update code to amend all returned paths by MessageRouter to offers, and refund
DRY create_offer_builder, and create_refund_builder

lightning/src/ln/channelmanager.rs

@TheBlueMatt

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))

@TheBlueMatt

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))

@TheBlueMatt

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))

shaavan · 2025-06-24T12:00:13Z

Updated from pr3246.20 to pr3246.21 (diff):

Changes:

Rebase on main
Clean-up commits history and messages.
Address other minor nit-changes.

TheBlueMatt

Design LGTM, feel free to land it after review @jkczyz

lightning/src/ln/channelmanager.rs

lightning/src/onion_message/messenger.rs

lightning/src/ln/functional_test_utils.rs

lightning/src/util/test_utils.rs

lightning/src/ln/channelmanager.rs

lightning/src/offers/flow.rs

@TheBlueMatt

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))

@TheBlueMatt

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))

@TheBlueMatt

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))

@TheBlueMatt

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))

shaavan · 2025-07-01T12:05:33Z

Updated from pr3246.21 to pr3246.22 (diff):
Addressed @TheBlueMatt and @jkczyz comments

Changes:

Addressed documentation updates, other nit suggestions.

In earlier versions of LDK, [`Router`] implemented [`MessageRouter`], but the two have since been decoupled. The removed documentation is outdated and no longer accurate, so it has been cleaned up in this commit.

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.

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.

@TheBlueMatt

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`.

shaavan · 2025-07-01T12:18:48Z

Updated from pr3246.22 to pr3246.23 (diff):

Changes:

Rebase on main

jkczyz · 2025-07-01T18:46:13Z

lightning/src/onion_message/messenger.rs

+/// # Privacy
+///
+/// Creating [`BlindedMessagePath`]s may affect privacy since, if a suitable path cannot be found,
+/// it will create a one-hop path using the recipient as the introduction node if it is a announced


s/a announced/an announced

jkczyz · 2025-07-01T18:48:27Z

lightning/src/onion_message/messenger.rs

+/// [`NullMessageRouter`] **must not** be used as the type parameter for [`ChannelManager`],
+/// since [`ChannelManager`] requires a functioning [`MessageRouter`] to create blinded paths,
+/// which are necessary for constructing reply paths in onion message communication.
+/// However, [`NullMessageRouter`] *can* still be passed as an argument to methods that accept


s/methods/[`ChannelManager`] methods

jkczyz · 2025-07-01T18:53:36Z

lightning/src/onion_message/messenger.rs

+}
+
+/// A special [`MessageRouter`] that performs no routing and does not create blinded paths.
+/// Its purpose is to enable the creation of [`Offers`] and [`Refunds`] without blinded paths,


s/[`Offers`]/s/[`Offer`]s
s/[`Refunds`]/s/[`Refund`]s

jkczyz · 2025-07-01T18:54:07Z

lightning/src/onion_message/messenger.rs

+
+/// A special [`MessageRouter`] that performs no routing and does not create blinded paths.
+/// Its purpose is to enable the creation of [`Offers`] and [`Refunds`] without blinded paths,
+/// where the user's `signing_pubkey` is used directly as the [`Destination`].


s/`signing_pubkey`/`node_id`

jkczyz · 2025-07-01T19:14:40Z

lightning/src/util/test_utils.rs

-		&'a TestLogger,
-		&'a TestKeysInterface,
-	>,
+pub enum TestMessageRouter<'a> {


Instead of introducing this enum, can each test that needs to a different MessageRouter simply override NodeCfg::message_router before calling create_node_chanmgrs?

jkczyz · 2025-07-01T19:16:02Z

lightning/src/ln/offers_tests.rs

@@ -406,7 +416,7 @@ fn creates_short_lived_offer() {
 #[test]
 fn creates_long_lived_offer() {
 	let chanmon_cfgs = create_chanmon_cfgs(2);
-	let node_cfgs = create_node_cfgs(2, &chanmon_cfgs);
+	let node_cfgs = create_node_cfgs_with_node_id_message_router(2, &chanmon_cfgs);


We can use create_offer_builder_using_router instead.

jkczyz · 2025-07-01T19:16:25Z

lightning/src/ln/offers_tests.rs

@@ -470,7 +480,7 @@ fn creates_short_lived_refund() {
 #[test]
 fn creates_long_lived_refund() {
 	let chanmon_cfgs = create_chanmon_cfgs(2);
-	let node_cfgs = create_node_cfgs(2, &chanmon_cfgs);
+	let node_cfgs = create_node_cfgs_with_node_id_message_router(2, &chanmon_cfgs);


jkczyz · 2025-07-01T19:32:52Z

lightning/src/ln/channelmanager.rs

+	/// # Privacy
+	///
+	/// Constructs a [`BlindedMessagePath`] for the offer using a custom [`MessageRouter`].
+	/// Users can implement a custom [`MessageRouter`] to define properties of the
+	/// [`BlindedMessagePath`] as required or opt not to create any `BlindedMessagePath`.
+	///
+	/// Also, uses a derived signing pubkey in the offer for recipient privacy.
+	///
+	/// # Limitations
+	///
+	/// See [`OffersMessageFlow::create_offer_builder`] for limitations on the offer builder.
+	///
+	/// # Errors
+	///
+	/// Errors if the provided [`MessageRouter`] is unable to create a blinded path for the offer.
+	///
+	/// [`BlindedMessagePath`]: crate::blinded_path::message::BlindedMessagePath
+	/// [`Offer`]: crate::offers::offer::Offer
+	/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest


Instead of duplicating the docs, could you instead reference ChannelManager::create_offer_builder docs, noting the differences. Similarly in OffersMessageFlow.

jkczyz · 2025-07-01T19:34:31Z

lightning/src/ln/channelmanager.rs

-	/// Uses [`MessageRouter`] to construct a [`BlindedMessagePath`] for the offer based on the given
-	/// `absolute_expiry` according to [`MAX_SHORT_LIVED_RELATIVE_EXPIRY`]. See those docs for
-	/// privacy implications.
+	/// Uses the [`ChannelManager`]'s [`MessageRouter`] to construct a [`BlindedMessagePath`] for


Won't this use OffersMessageFlow's message router? Seems like ChannelManager no longer has one as it is being passed through to OffersMessageFlow. Since we are only creating the flow internally now, perhaps we should word this as:

/// Uses the [`MessageRouter`] passed to [`ChannelManager`]'s constructor to ...

jkczyz · 2025-07-01T19:43:32Z

lightning/src/ln/channelmanager.rs

@@ -11024,6 +11024,72 @@ macro_rules! create_refund_builder { ($self: ident, $builder: ty) => {

 		Ok(builder.into())
 	}
+
+	/// Creates a [`RefundBuilder`] such that the [`Refund`] it builds is recognized by the


Similarly regarding repeating the docs.

shaavan marked this pull request as draft August 16, 2024 12:09

shaavan force-pushed the blinded_api branch from 53a3d18 to 6fa28be Compare August 16, 2024 12:09

jkczyz self-requested a review August 16, 2024 14:36

shaavan mentioned this pull request Aug 19, 2024

Exploring the Integration of Dummy Hops into Blinded Paths #3252

Open

shaavan force-pushed the blinded_api branch from 6fa28be to 52efbc6 Compare August 19, 2024 12:38

shaavan force-pushed the blinded_api branch from 52efbc6 to 79d6fdd Compare August 19, 2024 13:29

shaavan marked this pull request as ready for review August 19, 2024 13:30

shaavan force-pushed the blinded_api branch from 79d6fdd to 0d9ac2a Compare August 20, 2024 12:17

jkczyz reviewed Sep 4, 2024

View reviewed changes

shaavan force-pushed the blinded_api branch from 0d9ac2a to cbaf88a Compare September 4, 2024 11:05

TheBlueMatt reviewed Sep 5, 2024

View reviewed changes

lightning/src/onion_message/messenger.rs Outdated Show resolved Hide resolved

shaavan force-pushed the blinded_api branch from cbaf88a to 7a18051 Compare September 5, 2024 20:37

shaavan force-pushed the blinded_api branch from 7a18051 to bc00884 Compare September 19, 2024 15:40

shaavan force-pushed the blinded_api branch from bc00884 to 3bcc420 Compare September 19, 2024 16:03

shaavan changed the title ~~Introduce BlindedPathParams~~ Introduce BlindedPathType enum Sep 24, 2024

shaavan force-pushed the blinded_api branch from 3bcc420 to d6dde1e Compare October 3, 2024 12:30

jkczyz reviewed Oct 4, 2024

View reviewed changes

shaavan force-pushed the blinded_api branch from d6dde1e to 6817512 Compare October 11, 2024 14:28

jkczyz reviewed Oct 11, 2024

View reviewed changes

lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved

shaavan force-pushed the blinded_api branch from 6817512 to fe33775 Compare October 19, 2024 11:57

shaavan mentioned this pull request Jun 23, 2025

No Blinded Path Offer (Review Branch) shaavan/rust-lightning#1

Open

shaavan force-pushed the blinded_api branch from e67b695 to 65401b9 Compare June 24, 2025 12:00

shaavan requested review from TheBlueMatt and jkczyz June 29, 2025 18:09

TheBlueMatt reviewed Jun 30, 2025

View reviewed changes

lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved

lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved

jkczyz reviewed Jun 30, 2025

View reviewed changes

shaavan force-pushed the blinded_api branch from 65401b9 to fda57e9 Compare July 1, 2025 12:05

shaavan added 10 commits July 1, 2025 17:36

Fixup: Remove stale documentation

cd298aa

In earlier versions of LDK, [`Router`] implemented [`MessageRouter`], but the two have since been decoupled. The removed documentation is outdated and no longer accurate, so it has been cleaned up in this commit.

Refactor: Update TestMessageRouter to enum

6b4181f

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.

Test: Add coverage for Offers and Refunds without blinded paths

40ae7a0

Introduced tests to validate the behavior of Offers and Refunds created without blinded paths, using `NullMessageRouter`.

shaavan force-pushed the blinded_api branch from fda57e9 to 40ae7a0 Compare July 1, 2025 12:18

shaavan requested a review from jkczyz July 1, 2025 12:25

jkczyz reviewed Jul 1, 2025

View reviewed changes

Enable Creation of Offers and Refunds Without Blinded Path #3246

Are you sure you want to change the base?

Enable Creation of Offers and Refunds Without Blinded Path #3246

Conversation

shaavan commented Aug 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Description:

The Key Changes:

Uh oh!

codecov bot commented Aug 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

shaavan commented Aug 19, 2024

Uh oh!

shaavan commented Aug 19, 2024

Uh oh!

shaavan commented Aug 20, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

shaavan commented Sep 4, 2024

Uh oh!

Uh oh!

shaavan commented Sep 5, 2024

Uh oh!

shaavan commented Sep 19, 2024

Uh oh!

shaavan commented Sep 19, 2024

Uh oh!

shaavan commented Oct 3, 2024

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shaavan Oct 19, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

shaavan commented Oct 11, 2024

Uh oh!

Uh oh!

shaavan commented Jun 24, 2025

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

shaavan commented Aug 16, 2024 •

edited

Loading

codecov bot commented Aug 16, 2024 •

edited

Loading

shaavan Oct 19, 2024 •

edited

Loading