Skip to content

Conversation

@moisesPompilio
Copy link
Contributor

@moisesPompilio moisesPompilio commented Oct 24, 2025

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:

  • load_target(&mut self): loads or refreshes available targets before a new probing cycle.
  • next_target(&mut self, params: ProbingParameters) -> PublicKey: selects the next target for a probe.

Two strategies are currently supported:

  • Custom strategy: via set_probing_service_with_custom_strategy, allowing users to define custom target selection logic.
  • High-capacity strategy: via set_probing_service_with_high_capacity_strategy, which selects nodes with the highest channel capacities in the network.

The high-capacity strategy includes a caching mechanism to reuse targets for several cycles (e.g., 10), improving efficiency and reducing redundant network scans.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Oct 24, 2025

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@tnull tnull self-requested a review October 24, 2025 19:14
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Copy link
Collaborator

@tnull tnull left a 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`
@moisesPompilio
Copy link
Contributor Author

I added the ProbingStrategy trait to allow customizable target selection strategies. I also kept the high-capacity target selection as a separate, optional strategy that users can choose instead of implementing their own. Additionally, I updated the PR description to reflect these changes.

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) {

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.

Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants