-
Notifications
You must be signed in to change notification settings - Fork 91
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
Add SendingParameters
struct for customizable payments
#336
Add SendingParameters
struct for customizable payments
#336
Conversation
2729da1
to
63fc07d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking into this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we could also expose max_path_count
and max_channel_saturation_power_of_half
fields? Although, for the latter I wonder if we could come up with a bit more user-friendly format.
FWIW, I wonder the same for the max_total_routing_fee_msat
(e.g., could allow to set it in percent)?
Moreover, should we allow to set a default/node-wide PaymentParameters
(or whatever we want to call it) as part of Config
?
For fedimint just having max_total_routing_fee_msat as an absolute value would be the most user friendly. |
Thanks, good to know! |
PaymentParameters
struct for customizable payments SendingParameters
struct for customizable payments
0179893
to
9242342
Compare
Ah, seems this needs a rebase to make CI pass (which we just fixed, excuse the inconvenience!) |
9242342
to
7bfed68
Compare
done! |
rebased! |
You'll also need to account for the new |
86a07a4
to
7a0d5a1
Compare
@tnull I could use some advice on how to go about overriding routing params in the bolt12 methods. In bolt11/spontaneous send methods I could access the route parameters so it was a bit easier. But when paying offers I can't find where/how to override the existing routing params. Any thoughts? |
7a0d5a1
to
75cf55c
Compare
rebased |
I think unfortunately LDK currently doesn't provide a way to override all of the fields, now opened the issue here: lightningdevkit/rust-lightning#3262 Let's keep this PR BOLT11/Spontaneous only and I'll open a tracking issue to make sure we won't forget to add |
I think CI fails as you haven't updated the Kotlin tests in Could you also try to clean up the commit history a bit? Seems there are a few overlapping / back-and-forth commits going on. |
Okay, sounds good. |
72775c3
to
850b9d3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, could we either split this in one commit per field, or add all fields at once? In any case this split of "initial" and "new" fields doesn't make too much sense, given that they are not new. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that during the commit history cleanup yesterday, I accidentally included some code in the wrong commits. I’m still working on my skills with interactive rebasing 😅. But, I’ve restructured the commits so that they should make more sense now. I squashed all the fields into one commit and then implemented SendingParameters
in each method in the following commits.
1fac6dd
to
0b9f3cd
Compare
`SendingParameters` allows users to override opinionated values while routing a payment such as `max_total_routing_fees`, `max_path_count` `max_total_cltv_delta`, and `max_channel_saturation_power_of_half` Updated docs for `max_channel_saturation_power_of_half` for clarity.
Introduced `sending_parameters_config` to `Config` for node-wide routing and pathfinding configuration. Also, added default values for `SendingParameters` to ensure reasonable defaults when no custom settings are provided by the user.
Updated `Bolt11Payment` `send` method to accept `SendingParameters`, as a parameter. If the user provided sending params the default values are overridden.
Added the optional `SendingParameters` to `send_using_amount` in `Bolt11Payment`. If the user provides sending params the values will be overridden otherwise they'll use the default values.
Added optional SendingParameters to the send method in SpontaneousPayment. If the user provides sending params the values will be overridden otherwise they remain the same.
0b9f3cd
to
4822336
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, LGTM.
As I only have a few minor nits/comments I'm going to land this and solve them in a brief follow-up.
Based on #166 and #328
This PR introduces a
PaymentParameters
struct to allow users to override fields likemax_total_cltv_expiry_delta
,max_total_routing_fee_msat
, andexpiry_time
. I'd appreciate suggestions on other useful fields to include as well.I've added the optional
PaymentParameters
param to the send methods for both BOLT11 and Spontaneous payments. But, I need advice on whether we should be including it in the send methods for BOLT12 payments when paying for an offer. Specifically, I'm uncertain if values likemax_total_cltv_expiry_delta
orexpiry_time
can be overridden in this context.