Allow setting an HRN in invoice_requests built by `pay_for_offer` #3903

TheBlueMatt · 2025-07-01T14:33:52Z

If a user did their own BIP 353 lookup to fetch an offer from a
human readable name, we still want them to be able to use
`ChannelManager::pay_for_offer`.

Because BIP 353 offer payments require that the `invoice_request`
include the human readable name, we need to add an argument to set
the `invoice_request` HRN to `pay_for_offer`, which we do here.

and a few other misc cleanups of the pay_for_offer API.

ldk-reviews-bot · 2025-07-01T14:33:54Z

👋 Thanks for assigning @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

tnull

While I see the motivation for these changes, I'm not super convinced about some of the API changes in this PR.

tnull · 2025-07-02T06:38:29Z

lightning/src/ln/channelmanager.rs

+	///
+	#[cfg_attr(
+		feature = "dnssec",
+		doc = "Note that setting this will cause [`ChannelManager::pay_for_offer_from_human_readable_name`] to fail."


This is confusing. Why move everything to this struct if we introduce a footgun for the user?

More generally, do we really care that much that the LDK method has three more arguments or so?

Its not a huge deal, no, but it did seem like an opportunity to hide parameters we expect to never actually be used behind a default(). Especially the quantity just feels like a weird thing to put in the top-level function signature, though also the routing parameters.

I'm open to dropping the move here (or, honestly, dropping the quantity argument entirely and just setting it to 1 if the offer needs it), if you feel strongly.

(or, honestly, dropping the quantity argument entirely and just setting it to 1 if the offer needs it), if you feel strongly.

Hmm, not sure if we can just drop it, but it does have some footguns that would be nice to tackle at some point, see for example #3233

But presumably @jkczyz would have a stronger/better informed view on how to fix this/how the API should look like.

Seems pay_for_offer_from_human_readable_name should take a different type and have it translate it to OptionalOfferPaymentInfo. Or alternatively just leave quantity as a parameter to pay_for_offer.

Or we could introduce an OfferSupportingQuantity wrapper type on Offer -- which can only be created when Offer::expects_quantity is true -- and have a separate pay_for_offer_using_quantity method taking that type and having a required quantity parameter. Then drop the quantity parameter from pay_for_offer -- setting it internally to 1 if Offer::expects_quantity is true.

Or we could introduce an OfferSupportingQuantity wrapper type on Offer -- which can only be created when Offer::expects_quantity is true -- and have a separate pay_for_offer_using_quantity method taking that type and having a required quantity parameter. Then drop the quantity parameter from pay_for_offer -- setting it internally to 1 if Offer::expects_quantity is true.

Not sure why we need a separate wrapper type? I went ahead and pushed a fixup that adds a separate pay_for_offer_with_quantity type.

Okay, that's fine by me.

Wrapper would just remove a possible error where otherwise an offer not expecting a quantity is passed to pay_for_offer_with_quantity.

That would just move the error somewhere else, though? Instead of getting an error back from pay_for_offer_with_quantity you get a Result when you convert to the wrapper, which is just more code for the user.

lightning/src/ln/channelmanager.rs

tnull · 2025-07-02T06:44:28Z

lightning/src/ln/channelmanager.rs

 	pub fn pay_for_offer(
 		&self, offer: &Offer, amount_msats: Option<u64>, payment_id: PaymentId,
-		optional_info: OptionalOfferPaymentInfo,
+		optional_info: OptionalOfferPaymentInfo, derived_from_hrn: Option<HumanReadableName>,


If we do that, why not actually lean into the switch to bitcoin-payment-instructions and drop the pay_for_offer_from_hrn method. I don't think any of our users really implements HRNs yet, so we wouldn't even break API for anybody, AFAIK.

Yea, we could. Its still useful for a lightning-only wallet, but maybe we don't care too much about those?

What determines if something goes in OptionalOfferPaymentInfo vs added as a new parameter. Seems derived_from_hrn would rarely be Some, so why add another parameter for it?

My thinking was basically "anything that we expect users to need to think about" ie either "we dont have a good default and the user knows best" or "if the user mis-configures this, that's really bad". derived_from_hrn isn't expected to be set that much, but it falls into the second category.

Hmm, I find the parameter a bit odd, especially now that we try to split out most to a params object.

Yea, we could. Its still useful for a lightning-only wallet, but maybe we don't care too much about those?

Do we believe there ever will be a truly Lightning-only wallet that doesn't support to pay any onchain (or other L2) addresses?

IMO, even if we think this will ever be a thing, we should probably not optimize our API around that. Now that we added pay_for_offer_with_quantity, could we add a similar pay_for_offer_derived_from_hrn method that allows setting the HumanReadableName param, and just drop the original pay_for_offer_from_human_readable_name?

Hmm, I find the parameter a bit odd, especially now that we try to split out most to a params object.

Sure, but in this case it falls into the "a default becomes dangerous if it actually needed to be configured" case, so its kinda hard to move...

Do we believe there ever will be a truly Lightning-only wallet that doesn't support to pay any onchain (or other L2) addresses?

Maybe not anymore, I dunno. Phoenix was for a long time pre-splicing, I could see an eventual future where you don't really need L1 payments, and all L2s just "accept lightning" so it doesn't matter. I'm okay with removing the pay_for_offer_from_hrn stuff if you feel strongly that we should just rip it out.

IMO, even if we think this will ever be a thing, we should probably not optimize our API around that.

Hmm? This is the opposite case - the new API is important for wallets that do support L1 payments, and thus need to use bitcoin-payment-instructions to do resolutions.

Now that we added pay_for_offer_with_quantity, could we add a similar pay_for_offer_derived_from_hrn method that allows setting the HumanReadableName param, and just drop the original pay_for_offer_from_human_readable_name?

My fear is that a wallet will use bitcoin-payment-instructions to resolve an HRN, then happily pass the offer to pay_for_offer, since that's "the offer payment method". In practice, most users won't ever read through our long docs, so payments to BOLT 12 HRNs will just fail (while LNURL requests will succeed so the wallet author won't notice until later while BOLT 12/353 HRNs aren't broadly deployed yet).

I suppose we could try to address this by having bitcoin-payment-instructions instead have a pay_with_ldk_channelmanager method that takes the PaymentId and OptionalOfferPaymentParams and passes them through to a separate method, but it still leaves the API quite easy to misuse.

Could we have bitcoin-payment-instructions return an OfferFromHRN (wrapping the offer and name) that we could pass to our own pay_for_offer_derived_from_hrn ? Then we don't need to pass None everywhere pay_for_offer is called.

Hmm, it does still seem easy to accidentally call channelmanager.pay_for_offer(offer_from_hrn.offer()...), though certainly less so than exposing the offer directly. I'm a bit torn on it but willing to go that direction if y'all prefer.

lightning/src/ln/channelmanager.rs

jkczyz · 2025-07-02T13:51:25Z

lightning/src/ln/channelmanager.rs

 	pub fn pay_for_offer(
 		&self, offer: &Offer, amount_msats: Option<u64>, payment_id: PaymentId,
-		optional_info: OptionalOfferPaymentInfo,
+		optional_info: OptionalOfferPaymentInfo, derived_from_hrn: Option<HumanReadableName>,


What determines if something goes in OptionalOfferPaymentInfo vs added as a new parameter. Seems derived_from_hrn would rarely be Some, so why add another parameter for it?

lightning/src/ln/channelmanager.rs

jkczyz · 2025-07-02T14:32:22Z

lightning/src/ln/channelmanager.rs

+	///
+	#[cfg_attr(
+		feature = "dnssec",
+		doc = "Note that setting this will cause [`ChannelManager::pay_for_offer_from_human_readable_name`] to fail."


Seems pay_for_offer_from_human_readable_name should take a different type and have it translate it to OptionalOfferPaymentInfo. Or alternatively just leave quantity as a parameter to pay_for_offer.

Or we could introduce an OfferSupportingQuantity wrapper type on Offer -- which can only be created when Offer::expects_quantity is true -- and have a separate pay_for_offer_using_quantity method taking that type and having a required quantity parameter. Then drop the quantity parameter from pay_for_offer -- setting it internally to 1 if Offer::expects_quantity is true.

tnull

Fixups look good to me. Some more comments on the API design

lightning/src/ln/channelmanager.rs

tnull · 2025-07-08T08:36:55Z

lightning/src/ln/channelmanager.rs

+	///
+	#[cfg_attr(
+		feature = "dnssec",
+		doc = "Note that setting this will cause [`ChannelManager::pay_for_offer_from_human_readable_name`] to fail."


Okay, that's fine by me.

lightning/src/ln/channelmanager.rs

tnull · 2025-07-08T08:40:51Z

lightning/src/ln/channelmanager.rs

 	pub fn pay_for_offer(
 		&self, offer: &Offer, amount_msats: Option<u64>, payment_id: PaymentId,
-		optional_info: OptionalOfferPaymentInfo,
+		optional_info: OptionalOfferPaymentInfo, derived_from_hrn: Option<HumanReadableName>,


Hmm, I find the parameter a bit odd, especially now that we try to split out most to a params object.

Yea, we could. Its still useful for a lightning-only wallet, but maybe we don't care too much about those?

Do we believe there ever will be a truly Lightning-only wallet that doesn't support to pay any onchain (or other L2) addresses?

IMO, even if we think this will ever be a thing, we should probably not optimize our API around that. Now that we added pay_for_offer_with_quantity, could we add a similar pay_for_offer_derived_from_hrn method that allows setting the HumanReadableName param, and just drop the original pay_for_offer_from_human_readable_name?

TheBlueMatt · 2025-09-03T14:28:20Z

Okay, sorry for the extended delay here. I went ahead and rebased (and squashed since its been so long) and took the suggestion at #3903 (comment) (which will have lightning-payment-instructions adapted to it once it updates to LDK 0.2).

TheBlueMatt · 2025-09-03T14:28:45Z

I do think we should include this in LDK 0.2 (and updated the milestone to match) since its (I presume) important for ldk-node to switch to bitcoin-payment-instructions.

codecov · 2025-09-03T14:38:03Z

Codecov Report

❌ Patch coverage is 61.06870% with 51 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.81%. Comparing base (5ae19b4) to head (dbf40d3).
⚠️ Report is 42 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	43.42%	42 Missing and 1 partial ⚠️
lightning/src/ln/async_payments_tests.rs	76.47%	4 Missing ⚠️
lightning/src/offers/offer.rs	50.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3903      +/-   ##
==========================================
- Coverage   88.33%   87.81%   -0.53%     
==========================================
  Files         177      176       -1     
  Lines      131896   131737     -159     
  Branches   131896   131737     -159     
==========================================
- Hits       116512   115681     -831     
- Misses      12728    13421     +693     
+ Partials     2656     2635      -21

Flag	Coverage Δ
fuzzing	`21.57% <0.00%> (-0.04%)`	⬇️
tests	`87.64% <61.06%> (-0.53%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

ldk-reviews-bot · 2025-09-06T00:01:00Z

🔔 1st Reminder

Hey @tnull @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-09-06T00:01:01Z

🔔 1st Reminder

Hey @tnull @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-09-08T00:01:44Z

🔔 2nd Reminder

Hey @tnull @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-09-08T00:01:50Z

🔔 2nd Reminder

Hey @tnull @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-09-10T00:02:21Z

🔔 3rd Reminder

Hey @tnull @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-09-10T00:02:28Z

🔔 3rd Reminder

Hey @tnull @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

lightning/src/offers/offer.rs

jkczyz · 2025-09-10T15:20:10Z

lightning/src/ln/channelmanager.rs

+			payer_note: None,
+			route_params_config: Default::default(),
+			#[cfg(feature = "std")]
+			retry_strategy: Retry::Timeout(core::time::Duration::from_secs(2)),


Should we use something longer that is closer to how long Retry::Attempts(3) may take?

Retry::Attempts(3) should hopefully take around 2 seconds, I believe.

jkczyz · 2025-09-10T15:22:08Z

lightning/src/ln/async_payments_tests.rs

-	let params = RouteParametersConfig::default();
-	nodes[0]
-		.node
-		.pay_for_offer(&offer, None, Some(amt_msat), None, payment_id, Retry::Attempts(1), params)


Presumably the different Retry::Attempts values used throughout these tests weren't necessary?

Apparently not since they pass :) cc @valentinewallace

lightning/src/ln/channelmanager.rs

jkczyz · 2025-09-10T15:44:53Z

lightning/src/ln/channelmanager.rs

+		let create_pending_payment_fn = |invoice_request: &InvoiceRequest, nonce| {
+			let expiration = StaleExpiration::TimerTicks(1);
+			let retryable_invoice_request = RetryableInvoiceRequest {
+				invoice_request: invoice_request.clone(),
+				nonce,
+				needs_retry: true,
+			};
+			self.pending_outbound_payments
+				.add_new_awaiting_invoice(
+					payment_id,
+					expiration,
+					optional_params.retry_strategy,
+					optional_params.route_params_config,
+					Some(retryable_invoice_request),
+				)
+				.map_err(|_| Bolt12SemanticError::DuplicatePaymentId)
+		};


A little different from my earlier suggestions, but to avoid duplicating this, we could consider:

implementing AsRef<Offer> for OfferFromHrn

adding an ToHumanReadableName trait implemented by both Offer and OfferFromHrn with a method returning Option<HumanReadableName>

using a single method taking O: AsRef<Offer> + ToHumanReadableName

That way OfferFromHrn could be private to help avoid misuse. Though maybe explicit methods for each case would be more intuitive?

implementing AsRef<Offer> for OfferFromHrn

Isn't implementing AsRef for anything besides straight wrappers or smart pointers considered a bit of an anti-pattern? Maybe we could just do impl From<OfferFromHrn> for Offer> and have the pay_for_offer take an Into<Offer>?

I very specifically want to avoid it being too easy to convert an OfferFromHrn to an Offer - depending on how its done the compiler may suggest "didn't you mean to into before calling pay_for_offer?" which would be an incorrect suggestion.

ldk-reviews-bot · 2025-09-13T13:41:27Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-09-15T13:42:07Z

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Now that these do not allocate, we should allow them to be `Copy`ed.

TheBlueMatt · 2025-09-15T15:52:11Z

Rebased cause I had to and squashed fixups while I was at it.

graphite-app · 2025-09-15T15:54:06Z

lightning/src/ln/channelmanager.rs

+	/// Pays for an [`Offer`] which was built by resolving a human readable name. It is otherwise
+	/// identical to [`Self::pay_for_offer`].
+	pub fn pay_for_offer_from_hrn(
+		&self, offer: &OfferFromHrn, amount_msats: u64, payment_id: PaymentId,


API contract violation: The pay_for_offer_from_hrn method takes amount_msats: u64 (required) while pay_for_offer takes amount_msats: Option<u64> (optional). This inconsistency could cause confusion and runtime errors when users expect similar behavior between the two methods. Both methods should have consistent parameter types for the same logical operation.

Suggested change

&self, offer: &OfferFromHrn, amount_msats: u64, payment_id: PaymentId,

&self, offer: &OfferFromHrn, amount_msats: Option<u64>, payment_id: PaymentId,

Spotted by Diamond

Is this helpful? React 👍 or 👎 to let us know.

How would this be a runtime issue? It should be caught at compile-time. And the API difference is deliberate.

I take it OfferFromHrn from is expected have an Offer without an amount?

lightning/src/offers/offer.rs

In a coming commit we'll provide users a different `ChannelManager` method for sending to `Offer`s which were fetched by resolving an HRN. Here, we first ad a wrapper type which can be used by HRN resolution methods to nudge users towards calling the correct payment method on `ChannelManager`.

`ChannelManager::pay_for_offer` and `ChannelManager::pay_for_offer_from_human_readable_name` have accumulated a handful of arguments, most of which we expect users to never actually set. Instead, here, we move `quantity` and `payer_note` (which we expect users to never set) as well as `route_params_config` and `retry_strategy` (which we expect users to generally stick with the defaults on) into a new struct, which implements `Default`. This cleans up a good bit of cruft on payment calls.

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

If a user did their own BIP 353 lookup to fetch an offer from a human readable name, we still want them to be able to use `ChannelManager::pay_for_offer`. Because BIP 353 offer payments require that the `invoice_request` include the human readable name, we need to add an argument to set the `invoice_request` HRN to `pay_for_offer`, which we do here.

TheBlueMatt · 2025-09-16T20:49:49Z

Went ahead and removed the extra clone.

$ git diff-tree -U1 71fe9d74f0 dbf40d3fe9
diff --git a/lightning/src/offers/offer.rs b/lightning/src/offers/offer.rs
index ff798388b1..7eb719c104 100644
--- a/lightning/src/offers/offer.rs
+++ b/lightning/src/offers/offer.rs
@@ -846,3 +846,3 @@ impl OfferFromHrn {
 		InvoiceRequestWithDerivedPayerSigningPubkeyBuilder<'a, 'b>,
-		Some(self.hrn.clone())
+		Some(self.hrn)
 	);

ldk-reviews-bot · 2025-09-17T13:42:39Z

🔔 3rd Reminder

Hey @tnull @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tnull

Changes look good to me, going ahead and landing this.

On a more general note I'm still not the biggest fan of having the different payment APIs (BOLT11/BOLT12/spontaneous) diverge further by splitting out RouteParametersConfig in yet another config object just for BOLT12. We'll probably try to keep them more aligned in LDK Node.

Given that it would only be useful for a Lightning-only wallet that never wants to handle any of the other types of HumanReadableNames, I also still think it would make sense to drop pay_for_offer_from_human_readable_names and rely on the bitcoin-payment-instructions API for the resolution part. This is even more so the case since having both pay_for_offer_from_human_readable_names and pay_for_offer_from_hrn APIs side-by-side is pretty confusing IMO.

TheBlueMatt · 2025-09-18T11:24:50Z

This is even more so the case since having both pay_for_offer_from_human_readable_names and pay_for_offer_from_hrn APIs side-by-side is pretty confusing IMO.

Mmm, yea, that's worse than I was thinking lol. Maybe we should deprecate the native-resolution one...

joostjager · 2025-09-18T18:35:50Z

ldk-node broken: lightningdevkit/ldk-node#639

ldk-reviews-bot requested a review from tankyleo July 1, 2025 14:44

TheBlueMatt force-pushed the 2025-07-bpi branch 2 times, most recently from befb3f2 to 076b2b3 Compare July 1, 2025 23:32

tnull reviewed Jul 2, 2025

View reviewed changes

tnull requested review from jkczyz and removed request for tankyleo July 2, 2025 06:47

jkczyz reviewed Jul 2, 2025

View reviewed changes

TheBlueMatt force-pushed the 2025-07-bpi branch 2 times, most recently from 7a7a5d1 to a2daa01 Compare July 7, 2025 14:29

tnull reviewed Jul 8, 2025

View reviewed changes

TheBlueMatt added this to the 0.2 milestone Aug 30, 2025

TheBlueMatt force-pushed the 2025-07-bpi branch from a2daa01 to 297896c Compare September 3, 2025 14:27

TheBlueMatt requested review from jkczyz and tnull September 3, 2025 14:28

tnull reviewed Sep 10, 2025

View reviewed changes

lightning/src/offers/offer.rs Show resolved Hide resolved

jkczyz reviewed Sep 10, 2025

View reviewed changes

TheBlueMatt force-pushed the 2025-07-bpi branch from 297896c to 04cb808 Compare September 11, 2025 13:38

TheBlueMatt requested review from jkczyz and tnull September 11, 2025 13:41

jkczyz previously approved these changes Sep 11, 2025

View reviewed changes

Derive Copy for HumanReadableNames

882a0cb

Now that these do not allocate, we should allow them to be `Copy`ed.

TheBlueMatt dismissed jkczyz’s stale review via 71fe9d7 September 15, 2025 15:52

TheBlueMatt force-pushed the 2025-07-bpi branch from 04cb808 to 71fe9d7 Compare September 15, 2025 15:52

TheBlueMatt requested a review from jkczyz September 15, 2025 15:52

graphite-app bot reviewed Sep 15, 2025

View reviewed changes

jkczyz previously approved these changes Sep 16, 2025

View reviewed changes

lightning/src/offers/offer.rs Outdated Show resolved Hide resolved

TheBlueMatt added 6 commits September 16, 2025 20:49

Mention the bitcoin-payment-instructions crate in docs

0c13a66

Somewhat DRY pay_for_offer_intern callback method

dbf40d3

TheBlueMatt dismissed jkczyz’s stale review via dbf40d3 September 16, 2025 20:49

TheBlueMatt force-pushed the 2025-07-bpi branch from 71fe9d7 to dbf40d3 Compare September 16, 2025 20:49

TheBlueMatt requested a review from jkczyz September 16, 2025 20:49

jkczyz approved these changes Sep 17, 2025

View reviewed changes

tnull approved these changes Sep 18, 2025

View reviewed changes

tnull merged commit 07bf08b into lightningdevkit:main Sep 18, 2025
24 of 25 checks passed

tnull mentioned this pull request Sep 18, 2025

Refactor unified_qr.rs to use bitcoin-payment-instructions lightningdevkit/ldk-node#607

Closed

joostjager mentioned this pull request Sep 18, 2025

Adapt to new pay_for_offer call lightningdevkit/ldk-node#639

Merged

	&self, offer: &OfferFromHrn, amount_msats: u64, payment_id: PaymentId,
	&self, offer: &OfferFromHrn, amount_msats: Option<u64>, payment_id: PaymentId,

Allow setting an HRN in invoice_requests built by pay_for_offer #3903

Allow setting an HRN in invoice_requests built by pay_for_offer #3903

Uh oh!

Conversation

TheBlueMatt commented Jul 1, 2025

Uh oh!

ldk-reviews-bot commented Jul 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnull left a comment • 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!

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!

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!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt commented Sep 3, 2025

Uh oh!

TheBlueMatt commented Sep 3, 2025

Uh oh!

codecov bot commented Sep 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

ldk-reviews-bot commented Sep 6, 2025

Uh oh!

ldk-reviews-bot commented Sep 6, 2025

Uh oh!

ldk-reviews-bot commented Sep 8, 2025

Uh oh!

ldk-reviews-bot commented Sep 8, 2025

Uh oh!

ldk-reviews-bot commented Sep 10, 2025

Uh oh!

Allow setting an HRN in invoice_requests built by `pay_for_offer` #3903

Allow setting an HRN in invoice_requests built by `pay_for_offer` #3903

ldk-reviews-bot commented Jul 1, 2025 •

edited

Loading

tnull left a comment •

edited

Loading

codecov bot commented Sep 3, 2025 •

edited

Loading

tnull Sep 11, 2025 •

edited

Loading

TheBlueMatt Sep 11, 2025 •

edited

Loading