Introduce RouteParametersOverride #3342

shaavan · 2024-09-26T12:33:19Z

Partially addresses #3262

Introduce a new struct RouteParametersOverride that optionally takes the parameter to override for routing params.
Pass it to pay_for_offer to use it along with the invoice's payment parameter to set route parameters.

shaavan · 2024-09-26T12:38:02Z

A gentle ping! Would love to get your feedback or approach ACK before moving forward with testing and applying a similar approach on the BOLT11 side.

Thanks a lot!

codecov · 2024-09-26T12:40:07Z

Codecov Report

Attention: Patch coverage is 82.14286% with 10 lines in your changes missing coverage. Please review.

Project coverage is 89.61%. Comparing base (ad19d93) to head (a608b55).

Files with missing lines	Patch %	Lines
lightning/src/ln/outbound_payment.rs	82.14%	3 Missing and 2 partials ⚠️
lightning/src/routing/router.rs	85.00%	0 Missing and 3 partials ⚠️
lightning/src/ln/channelmanager.rs	75.00%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3342      +/-   ##
==========================================
- Coverage   89.61%   89.61%   -0.01%     
==========================================
  Files         127      127              
  Lines      103533   103569      +36     
  Branches   103533   103569      +36     
==========================================
+ Hits        92785    92811      +26     
- Misses       8051     8053       +2     
- Partials     2697     2705       +8

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

vincenzopalazzo

LGTM overall.

However I am not the right person to judge if the PR is what the ldk team is looking for.

For instance the following is confusing me :) but I think this is a discussion to be done inside the issue

They also don't really make sense in a BOLT 11 world if we pass a Bolt11Invoice directly to ChannelManager (which we should do now that lightning depends on lightning-invoice).

BTW Nice git history!

P.S: I left some API idea comment in some commit review, idk if they are useful or not. probably they will remove a lot of map(_ {}) code, but I had to write the code to confirm

lightning/src/routing/router.rs

lightning/src/ln/outbound_payment.rs

vincenzopalazzo · 2024-10-02T16:13:15Z

lightning/src/ln/channelmanager.rs

@@ -9303,7 +9309,7 @@ where
 	pub fn pay_for_offer(
 		&self, offer: &Offer, quantity: Option<u64>, amount_msats: Option<u64>,
 		payer_note: Option<String>, payment_id: PaymentId, retry_strategy: Retry,
-		max_total_routing_fee_msat: Option<u64>
+		manual_routing_params: Option<ManualRoutingParameters>
 	) -> Result<(), Bolt12SemanticError> {


OK no needed option here but: what do you think about having the function call like pay_for_offer(offer, OfferParams::default()) where OfferParams is something like that

struct OfferParams { quantity: Option<u64>, amount_msats: Option<u64>, manual_routing_params: Option<ManualRoutingParameters>, }

I think is a lot of more verbose in this way, but I also this that this will be a lot of cleaner.

Now I do not think this will fit well in this PR maybe can be a followup one, but with this patter, it is possible to hide future updates to offers (e.g: recurrence or market place feature) without breaking too much the code

I think this is a great improvement! It will help keep the function signature cleaner while remaining maintainable for future parameter increases.

Maybe we can take this in a follow-up. @TheBlueMatt, what do you think?

No strong opinions.

lightning/src/ln/outbound_payment.rs

TheBlueMatt

High-level design looks right to me.

TheBlueMatt · 2024-10-08T18:16:09Z

lightning/src/ln/channelmanager.rs

@@ -9303,7 +9309,7 @@ where
 	pub fn pay_for_offer(
 		&self, offer: &Offer, quantity: Option<u64>, amount_msats: Option<u64>,
 		payer_note: Option<String>, payment_id: PaymentId, retry_strategy: Retry,
-		max_total_routing_fee_msat: Option<u64>
+		manual_routing_params: Option<ManualRoutingParameters>
 	) -> Result<(), Bolt12SemanticError> {


No strong opinions.

TheBlueMatt · 2024-10-08T18:24:55Z

lightning/src/routing/router.rs

@@ -962,6 +980,43 @@ impl PaymentParameters {
 	}
 }

+/// Information manually provided by the user to route the payment
+#[derive(Clone, Copy)]
+pub struct ManualRoutingParameters {


A bit of a weird name, IMO. This object will be the parameters when sending a payment (BOLT 11 or BOLT 12 offer) when the route-finding is automatic, so kinda weird to call it "manual" :). Maybe PaymentRouteFindingParams or PaymentRouteParams, I dunno they're all super confusing with RouteParams and PaymentParams already existing...I don't have good ideas, but we should come up with something.

How about RouteParameterOverrides, RouteParametersConfig, or CustomizedRouteParameters? Most fields are for overriding PaymentParameters, but that is a part of RouteParameters one of which can be overridden, too.

Updated the name to RouteParametersOverride in pr3342.03 as it sounded to me the most optimum for now.

Thanks, @jkczyz for the suggestion on names!

@TheBlueMatt
Let me know if the name looks good to you! Thanks!

TheBlueMatt · 2024-10-08T18:25:14Z

lightning/src/routing/router.rs

+	/// Same as [`PaymentParameters::max_path_count`]
+	pub max_path_count: Option<u8>,
+	/// Same as [`PaymentParameters::max_channel_saturation_power_of_half`]
+	pub max_channel_saturation_power_of_half: Option<u8>,


Why is this an Option?

I’ve made all the fields optional, so they act as overrides. If left as None, the values from PaymentParameters (created using the invoice and default settings) will be used. I’ve also updated the docs to make this clearer for this struct.

Would love to hear your feedback on this API design! Thanks so much!

TheBlueMatt · 2024-10-08T18:25:41Z

lightning/src/routing/router.rs

+	/// Same as [`RouteParameters::max_total_routing_fee_msat`]
+	pub max_total_routing_fee_msat: Option<u64>,
+	/// Same as [`PaymentParameters::max_total_cltv_expiry_delta`]
+	pub max_total_cltv_expiry_delta: Option<u32>,


This probably shouldn't be an Option, we should define something.

TheBlueMatt · 2024-10-08T18:26:18Z

lightning/src/routing/router.rs

+#[derive(Clone, Copy)]
+pub struct ManualRoutingParameters {
+	/// Same as [`RouteParameters::max_total_routing_fee_msat`]
+	pub max_total_routing_fee_msat: Option<u64>,


What happens if this is None, should be described in the docs. I assume it picks a default not allows any fee?

lightning/src/ln/outbound_payment.rs

shaavan · 2024-10-13T13:31:59Z

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

Changes:

Rebase on main

With the current architecture, `pay_for_offer` only allows setting `max_total_routing_fee_msat` as a route parameter. However, it doesn't provide users the flexibility to set other important parameters. This commit introduces a new struct, `RouteParametersOverride`, that optionally allows users to set additional routing parameters. In later commits, this struct will be utilized when paying BOLT12 invoices.

When `pay_for_offer` is called, it creates a new `PendingOutboundPayment` entry with relevant values that will be used when the corresponding invoice is received. This update modifies `AwaitingInvoice` to include the entire `ManualRoutingParameters` struct instead of just `max_total_routing_fee_msat`. This change ensures all manual routing parameters are available when finding payment routes. Decisions & Reasoning: 1. **Retention of `max_total_routing_fee_msat` in `AwaitingInvoice`:** This field is retained to ensure downgrade support. However, it is removed from `InvoiceReceived` since it was never used, thereby helping to clean up the code while still supporting downgrading. 2. **Introduction of `route_params_override` in `InvoiceReceived`:** This was added for the same reason that `max_total_routing_fee_msat` was originally introduced in PR lightningdevkit#2417. The documentation has been updated to reflect this, based on [this comment](lightningdevkit@d7e2ff6#r1334619765).

This update allows users to call `pay_for_offer` with a set of parameters they wish to manually set for routing the corresponding invoice. By accepting `RouteParametersOverride`, users gain greater control over the routing process.

shaavan · 2024-10-13T15:30:12Z

Updated from pr3342.02 to pr3342.03 (diff):
Addressed @vincenzopalazzo, @jkczyz, @TheBlueMatt comments

Changes:

Renamed ManualRoutingParameters -> RouteParametersOverride
Reintroduce the max_total_routing_fee_msat in AwaitingInvoice to support downgrading.
Update API, so that the PaymentParameters are created using the Overrides, and then the RouteParameters are created using it.

TheBlueMatt · 2024-10-16T23:43:17Z

lightning/src/routing/router.rs

@@ -962,6 +970,46 @@ impl PaymentParameters {
 	}
 }

+/// A struct for overriding specific [`RouteParameters`] values created


Its a bit weird, IMO, to document/name this in relation to RouteParameters when most users will never even see a RouteParameters (once we do #3375) and will only ever see this.

TheBlueMatt · 2024-10-16T23:44:03Z

lightning/src/ln/outbound_payment.rs

 	},
 	(7, InvoiceReceived) => {
 		(0, payment_hash, required),
 		(2, retry_strategy, required),
-		(4, max_total_routing_fee_msat, option),


Removing an even value will result in failure to decode on upgrade - we will get an unknown even value which is a failure ("its okay to be odd")

TheBlueMatt · 2024-10-16T23:48:21Z

lightning/src/ln/outbound_payment.rs

+		// Deprecated: Retained for backward compatibility.
+		// If set during read, this field overrides `RouteParameters::max_total_routing_fee_msat`
+		// instead of `RouteParametersOverride::max_total_routing_fee_msat`.
 		max_total_routing_fee_msat: Option<u64>,


Ugh, I really prefer to handle this kind of thing at the serialization layer rather than in our logic. It'll be pretty annoying to break out impl_writeable_tlv_based_enum_upgradable! here, though....I wonder if we shouldn't try to (yet again) expand the featureset of our enum-deser logic. Lets get this PR ready in every other way and then I can play with it, maybe in a followup.

TheBlueMatt · 2024-10-16T23:51:25Z

Looks like most of my previous comments went unaddressed? Just checking cause I interpreted your comment as you addressing them.

vincenzopalazzo reviewed Oct 2, 2024

View reviewed changes

vincenzopalazzo mentioned this pull request Oct 2, 2024

BOLT12 sending doesn't allow to override {Route,Payment}Parameters #3262

Open

jkczyz self-requested a review October 3, 2024 16:03

jkczyz reviewed Oct 8, 2024

View reviewed changes

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

lightning/src/ln/outbound_payment.rs Show resolved Hide resolved

TheBlueMatt reviewed Oct 8, 2024

View reviewed changes

shaavan force-pushed the i3262 branch from 271522d to 0fc35e1 Compare October 13, 2024 13:31

shaavan added 4 commits October 13, 2024 20:56

Extend pay_for_offer to accept RouteParametersOverride

04da57c

This update allows users to call `pay_for_offer` with a set of parameters they wish to manually set for routing the corresponding invoice. By accepting `RouteParametersOverride`, users gain greater control over the routing process.

Use RouteParametersOverride to create new RouteParameters

a608b55

shaavan force-pushed the i3262 branch from 0fc35e1 to a608b55 Compare October 13, 2024 15:30

shaavan changed the title ~~Introduce ManualRoutingParameters~~ Introduce RouteParametersOverride Oct 14, 2024

TheBlueMatt reviewed Oct 16, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce RouteParametersOverride #3342

Introduce RouteParametersOverride #3342

shaavan commented Sep 26, 2024 •

edited

Loading

shaavan commented Sep 26, 2024

codecov bot commented Sep 26, 2024 •

edited

Loading

vincenzopalazzo left a comment

vincenzopalazzo Oct 2, 2024

shaavan Oct 3, 2024

TheBlueMatt Oct 8, 2024

TheBlueMatt left a comment

TheBlueMatt Oct 8, 2024

TheBlueMatt Oct 8, 2024

jkczyz Oct 11, 2024

shaavan Oct 13, 2024

TheBlueMatt Oct 8, 2024

shaavan Oct 13, 2024

TheBlueMatt Oct 8, 2024

TheBlueMatt Oct 8, 2024

shaavan commented Oct 13, 2024

shaavan commented Oct 13, 2024

TheBlueMatt Oct 16, 2024

TheBlueMatt Oct 16, 2024

TheBlueMatt Oct 16, 2024

TheBlueMatt commented Oct 16, 2024

Introduce RouteParametersOverride #3342

Are you sure you want to change the base?

Introduce RouteParametersOverride #3342

Conversation

shaavan commented Sep 26, 2024 • edited Loading

shaavan commented Sep 26, 2024

codecov bot commented Sep 26, 2024 • edited Loading

Codecov Report

vincenzopalazzo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheBlueMatt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shaavan commented Oct 13, 2024

shaavan commented Oct 13, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheBlueMatt commented Oct 16, 2024

shaavan commented Sep 26, 2024 •

edited

Loading

codecov bot commented Sep 26, 2024 •

edited

Loading