Track Channel Liquidity History in ProbabilisticScorer (routing, ProbabilisticScorer)

Host: ariard  -  PR author: TheBlueMatt

The PR branch HEAD was 09a1788 at the time of this review club meeting.


  • LDK scoring infrastructure was introduced in #1507. Previous attempts to capture a flexible scoring API have been explored in #626.
  • Numerous improvements have been added to this subsystem with #1197, #1227, #1347, #1375 and #1555.
  • This PR introduces the notion of historical tracking of the channel liquidity balances.


  1. What’s the general steps of our routing algorithm get_route() ? At which step the scoring penalty interfers ?
  2. What’s the current scoring strategy implemented by ProbabilisticScorerUsingTime ? What are the key findings of Optimically Reliable & Cheap Payment Flows on the Lightning Network ? What are the limitations ?
  3. How the current penalty_msat() is computed ? How the bounds min_liquidity_offset_msat / max_liquidity_offset_msat applied in function of the routed amount_msat influence the result ?
  4. What’s the new HistoricalBucketRangeTracker aims to achieve in terms of payment reliability ?
  5. How the current LDK probing interface send_probe() works ? What could be a LDK automatic probing strategy ? What are the limits of probing ?
  6. ProbabilisticScorerUsingTime works well for high-payment volume or actively probing nodes. This is limited for low-payment volume nodes. How this can be solved today ? Can we imagine a distributed and trust-minimized scoring algorithm in the future for such nodes ?