-
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
Skip channels used for probing based on available liquidity #156
Conversation
2dfa7bf
to
9c92be3
Compare
9c92be3
to
7d52209
Compare
ACK |
Since |
Sure, happy to. |
So are we closing this PR in favor of upstream PR or we will upstream separately later? |
Nah, as we'd want to expose the same API anyways I'd just land this and migrate to use upstream's version after 0.0.117 is released. |
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 for squash.
Do we want to add testcases for this ? |
src/lib.rs
Outdated
if *remaining_liquidity | ||
< path_value * self.config.probing_liquidity_limit_multiplier |
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.
You'll have the same problem as before because the way the division is moved to the other side of the inequality as a multiplication. From the previous example:
remaining_liquidity
: 100, 81, 62
path_value * self.config.probing_liquidity_limit_multiplier
: 19 * 3 = 57
Time to write a test? 😅
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.
Grrr, my bad. 🤦♂️
Now dropped the commit in question and replaced it with the additive approach you originally suggested.
In regard to testing: as this requires a non-trivial topology I took this as an opportunity to finally introduce a multi-hop testing scenario with #157 based on which I'll be able to check that the probe will indeed not obstruct payment sending. However, still running into some gossip issues there (as these need to be announced channels) which I'm investigating. Happy to wait until this is resolved before landing this, or landing this as is and adding testing later, your call. I'll also add unit tests when upstreaming this logic.
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.
I'm fine with testing upstream. Indifferent on whether you want to land this first.
2f4690e
to
bd9f1ae
Compare
Yes, however, see #156 (comment). |
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.
Feel free to squash.
As pre-flight probes might take up some of the available liquidity, we here introduce that channels whose available liquidity is less than the required amount times `Config::probing_liquidity_limit_multiplier` won't be used to send pre-flight probes.
bd9f1ae
to
758f91b
Compare
Squashed without further changes. |
Fixes #155.
As pre-flight probes might take up some of the available liquidity, we here introduce that channels whose available liquidity is less than the required amount times
Config::probing_liquidity_limit_multiplier
won't be used to send pre-flight probes.(cc @TonyGiorgio)