routing: if MaxShardAmt is set, then use that as a ceiling for our splits, use default of 16 for MaxParts #5017
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Roasbeef
added
enhancement
Roasbeef
force-pushed
the
default-max-parts
branch
from
8688f8c
to
1b098d4
Compare
bhandras
requested changes
Feb 12, 2021
Roasbeef
force-pushed
the
default-max-parts
branch
from
1b098d4
to
5909b7a
Compare
Roasbeef
force-pushed
the
default-max-parts
branch
2 times, most recently
from
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
Roasbeef
force-pushed
the
default-max-parts
branch
from
ea1bf09
to
db69331
Compare
Merged
|
Thanks for building this! I'm confused why the name is different though. Why not |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
MaxShardAmtas well asMaxPartsfor 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