Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce RouteParametersConfig #3342

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

Conversation

shaavan
Copy link
Contributor

@shaavan shaavan commented Sep 26, 2024

Partially addresses #3262

  • Introduce a struct that allows the user to configure the parameters for routing the payment.
  • Use the struct for BOLT12 payment flow.

@shaavan
Copy link
Contributor Author

shaavan commented Sep 26, 2024

Hey @TheBlueMatt @tnull,

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!

Copy link

codecov bot commented Sep 26, 2024

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.

Copy link
Contributor

@vincenzopalazzo vincenzopalazzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Show resolved Hide resolved
lightning/src/ln/outbound_payment.rs Show resolved Hide resolved
@@ -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> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No strong opinions.

lightning/src/ln/outbound_payment.rs Outdated Show resolved Hide resolved
lightning/src/ln/outbound_payment.rs Show resolved Hide resolved
Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

High-level design looks right to me.

@@ -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> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No strong opinions.

lightning/src/routing/router.rs Outdated Show resolved Hide resolved
lightning/src/routing/router.rs Outdated Show resolved Hide resolved
lightning/src/routing/router.rs Outdated Show resolved Hide resolved
lightning/src/routing/router.rs Show resolved Hide resolved
lightning/src/ln/outbound_payment.rs Outdated Show resolved Hide resolved
@shaavan
Copy link
Contributor Author

shaavan commented Oct 13, 2024

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

Changes:

  1. Rebase on main

@shaavan
Copy link
Contributor Author

shaavan commented Oct 13, 2024

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

Changes:

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

@shaavan shaavan changed the title Introduce ManualRoutingParameters Introduce RouteParametersOverride Oct 14, 2024
lightning/src/routing/router.rs Outdated Show resolved Hide resolved
lightning/src/ln/outbound_payment.rs Show resolved Hide resolved
Comment on lines 64 to 67
// 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>,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done! 🚀 Thanks a lot!

@TheBlueMatt
Copy link
Collaborator

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

@shaavan shaavan force-pushed the i3262 branch 2 times, most recently from 7cdb03f to 63b08a4 Compare October 18, 2024 12:58
@shaavan
Copy link
Contributor Author

shaavan commented Oct 18, 2024

Updated from pr3342.03 to pr3342.04 (diff):
Addressed @TheBlueMatt’s comments:

Changes:

Update Role of RouteParamsOverride:

  1. Instead of presenting this new struct as just overriding the PaymentParams, it is now structured as allowing the user to set configuration parameters.
  2. This brings some changes to the struct:
    • It has been renamed from RouteParamsOverride to RouteParamsConfig.
    • The parameters are now required rather than optional.
    • Documentation has been expanded to make the struct stand independently of {Route, Payment} Params.

Cleanups:

  1. Introduced a new separate function, with_user_config, in PaymentParams, making the function more modular and focused.
  2. RouteParamsConfig is now a required field in AwaitingInvoice and InvoiceReceived, initialized with default values if absent. This eliminates redundant optioning and switches to default values where necessary.

@shaavan
Copy link
Contributor Author

shaavan commented Oct 18, 2024

@TheBlueMatt

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

Hey Matt, I’m really sorry for missing your previous comments – not sure how that slipped through! I've gone through everything now and made sure to address them all in the latest update. Thanks so much for your patience! 🌟

@shaavan shaavan changed the title Introduce RouteParametersOverride Introduce RouteParametersConfig Oct 18, 2024
lightning/src/ln/outbound_payment.rs Outdated Show resolved Hide resolved
lightning/src/ln/outbound_payment.rs Outdated Show resolved Hide resolved
lightning/src/ln/outbound_payment.rs Outdated Show resolved Hide resolved
lightning/src/ln/outbound_payment.rs Show resolved Hide resolved
lightning/src/ln/outbound_payment.rs Outdated Show resolved Hide resolved
@TheBlueMatt
Copy link
Collaborator

Okay, I probably spent a bit too long on it, but #3378 should let us drop the legacy fields in outbound_payment.rs at de-serialization time.

@shaavan
Copy link
Contributor Author

shaavan commented Oct 22, 2024

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

Changes:

  1. Rebase on main. Rest no changes.

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, `RouteParametersConfig`,
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
`RouteParametersConfig` 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` &
   `InvoiceReceived`**

   This field is retained to ensure downgrade support.

2. **Introduction of `route_params_config` 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
Copy link
Contributor Author

shaavan commented Oct 22, 2024

Updated from pr3342.05 to pr3342.06 (diff):
Addressed @jkczyz, @TheBlueMatt comments

Changes:

  1. Fix the comment regarding supporting standard behaviour during upgrade.
  2. Set the max_total_routing_fee_msat along with route_params config to support downgrade.
  3. Fix the fn static_invoice_received to ensure proper compilation and behaviour async_payment case as well.
  4. Refactor the code to use if let instead of map for better readability.
  5. Introduce the full config parameter for create_refund_builder as well.
  6. Structured the commits slightly to have better logical progression.

@TheBlueMatt
Copy link
Collaborator

Lets get a review pass or two on #3378 and see if we want to move forward with it. If we do, we should rebase this on that and do the conversion in outbound_payment.rs at deserialization time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants