Introduce ManualRoutingParameters #3342
Conversation
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, `ManualRoutingParameters`, 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 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 that all manual routing parameters are available when finding the payment route.
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 `ManualRoutingParameters`, users gain greater control over the routing process.
In addition to using PaymentParameters from the invoice, this commit enables the creation of RouteParameters using the values optionally set in ManualRoutingParameters.
|
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! |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3342 +/- ##
==========================================
+ Coverage 89.65% 89.76% +0.10%
==========================================
Files 126 126
Lines 102750 104115 +1365
Branches 102750 104115 +1365
==========================================
+ Hits 92123 93460 +1337
- Misses 7904 7929 +25
- Partials 2723 2726 +3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
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
|
|
||
| impl ManualRoutingParameters { | ||
| /// Initates an empty set of [`ManualRoutingParameters`] | ||
| pub fn new() -> Self { |
There was a problem hiding this comment.
Random though: We would like to use an fn empty name for this and keep the new for a common constructor (that I do not know what common in this case means 😄 )
There was a problem hiding this comment.
That makes sense!
I noticed, in the codebase, we're using fn new more often for blank initialization, though, so to keep things consistent, it might be a good idea to stick with new. Lemmino what you think! :)
| @@ -2238,7 +2244,7 @@ impl_writeable_tlv_based_enum_upgradable!(PendingOutboundPayment, | |||
| (5, AwaitingInvoice) => { | |||
| (0, expiration, required), | |||
| (2, retry_strategy, required), | |||
| (4, max_total_routing_fee_msat, option), | |||
There was a problem hiding this comment.
Is this breaking backward compatibility?
Matt taught me how this works a few weeks ago, but I’m not completely sure if I’m understanding it correctly, so please bear with me.
The old LDK node has stored a u64 with the type 4. So, if you now change the format, there will be a type mismatch between what LDK 124 has stored and what the future LDK is expecting.
If I’m understanding this correctly, you need a new type (a new number) for manual_routing_params. When upgrading, the max_total_routing_fee_msat will have a value, and from that, you can create the manual_routing_params. Then, you will store manual_routing_params as Some or None, depending on the value.
| @@ -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> { | |||
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
Partially addresses #3262
ManualRoutingParametersthat optionally takes the parameter to set for routing.pay_for_offerto use it along with the invoice's payment parameter to set route parameters.