-
Notifications
You must be signed in to change notification settings - Fork 113
Add ProbingService: optional service for periodic probe payments
#678
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
base: main
Are you sure you want to change the base?
Add ProbingService: optional service for periodic probe payments
#678
Conversation
|
👋 Thanks for assigning @tnull as a reviewer! |
|
🔔 1st Reminder Hey @tnull! This PR has been waiting for your review. |
|
🔔 2nd Reminder Hey @tnull! This PR has been waiting for your review. |
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!
Hmm, I think it makes sense to start out with a very simple strategy, but we should set this up to be more generic so that the ProbingService can handle a variety of different strategies going forward, ie., for example by adding a trait ProbingStrategy that the different strategies can implement. Such trait could have a simple fn next_target(probing_params: ProbingParameters) -> PublicKey method or similar.
- Add optional ProbingService to run periodic probe payments for liquidity checks. - Configure probing behavior by providing a public `ProbingStrategy` trait implementation. - Targets and selection logic are fully customizable by the user via the trait (no fixed target count is passed by the node).
- Add `HighCapacityStrategy` that selects top-N nodes by aggregate capacity from `NetworkGraph`. - Add lightweight caching with configurable reuse limit to avoid frequent graph scans. - Wireable from builder via `set_probing_service_with_high_capacity_strategy`
5b5f32c to
fd8ab95
Compare
|
I added the |
| loop { | ||
| if let Some(target) = self.strategy.next_target() { | ||
| let spontaneous_payment = self.spontaneous_payment(); | ||
| match spontaneous_payment.send_probes(self.probing_amount_msat, target) { |
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.
We probably want to be setting https://docs.rs/lightning/0.2.0-rc1/lightning/routing/scoring/struct.ProbabilisticScoringFeeParameters.html#structfield.probing_diversity_penalty_msat to something non-0 when doing background probing. Sadly the LDK ChannelManager::send_spontaneous_preflight_probes API used under the hood here doesn't allow overriding the scoring parameters, but calling ChannelManager:send_probe directly should be pretty easy, I think.
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.
Yes, I agree that this code should probably use the 'raw' LDK API here rather than reusing the LDK Node APIs. We might want to expose the diversity penalty, as well as the liquidity multiplier from send_preflight_probes (https://github.com/lightningdevkit/rust-lightning/blob/7177cfc958bd54e12fff730d337630131679b066/lightning/src/ln/channelmanager.rs#L5971-L6049) to be used.
This introduces the ProbingService, an optional background task that periodically sends probe payments to selected network targets.
It supports customizable probing strategies through the new ProbingStrategy trait, which defines two methods:
Two strategies are currently supported:
The high-capacity strategy includes a caching mechanism to reuse targets for several cycles (e.g., 10), improving efficiency and reducing redundant network scans.