-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
routing: if MaxShardAmt is set, then use that as a ceiling for our splits, use default of 16 for MaxParts #5017
routing: if MaxShardAmt is set, then use that as a ceiling for our splits, use default of 16 for MaxParts #5017
Conversation
8688f8c
to
1b098d4
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.
concept ACK
1b098d4
to
5909b7a
Compare
53cbd34
to
ea1bf09
Compare
In this commit, we raise the default value for the `MaxParts` field from 1 to 16. This change was motivated by the fact that many users either forget, or don't even know this field is there in the first place. A value of 16 was chosen rather arbitraliy (other than power of 2). In the future, we should tune this value based on the expected number of payment attempts for a given payment amount.
…lits In this commit, we thread through the necessary state to allow users to set a max shard amount. If this value is set, then this'll effectively serve as a ceiling for all our split attempts. If we need to split, we'll first try to use `paymentAmt/2`, if that's bigger than `MaxShardAmt, then we'll use the latter instead. Ideally in the future we have a dynamic way to automatically set both the `MaxShardAmt` as well as `MaxParts` for users. Until then exposing these two new fields will allow us to experiment with setting them automatically using the RPC interface, and also give users a bit more control over how we attempt to route payments, akin to coin control for on-chain payments. Fixes lightningnetwork#4730
ea1bf09
to
db69331
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.
LGTM 💯
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.
LGTM 🚀
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.
LGTM
Thanks for building this! I'm confused why the name is different though. Why not |
In this commit, we thread through the necessary state to allow users to
set a max shard amount. If this value is set, then this'll effectively
serve as a ceiling for all our split attempts. If we need to split,
we'll first try to use
paymentAmt/2
, if that's bigger than`MaxShardAmt, then we'll use the latter instead.
Ideally in the future we have a dynamic way to automatically set both
the
MaxShardAmt
as well asMaxParts
for users. Until then exposingthese two new fields will allow us to experiment with setting them
automatically using the RPC interface, and also give users a bit more
control over how we attempt to route payments, akin to coin control for
on-chain payments.
Fixes #4730