f address docs feedback

Author: TheBlueMatt

lightning/src/routing/scoring.rs

@@ -314,23 +314,23 @@ type ConfiguredTime = Eternity;
 
 /// [`Score`] implementation using channel success probability distributions.
 ///
-/// Channels are tracked with upper- and lower- liquidity bounds - when an HTLC fails at a channel,
+/// Channels are tracked with upper and lower liquidity bounds - when an HTLC fails at a channel,
 /// we learn that the upper-bound on the available liquidity is lower than the amount of the HTLC.
 /// When a payment is forwarded through a channel (but fails later in the route), we learn the
 /// lower-bound on the channel's available liquidity must be at least the value of the HTLC.
 ///
 /// These bounds are then used to determine a success probability using the formula from
 /// *Optimally Reliable & Cheap Payment Flows on the Lightning Network* by Rene Pickhardt
-/// and Stefan Richter [[1]] (i.e. `(payment amount + lower-bound) / (upper-bound - lower-bound)`).
+/// and Stefan Richter [[1]] (i.e. `(upper_bound - payment_amount) / (upper_bound - lower_bound)`).
 ///
-/// This probability is converted into a linear score and multiplying it with the
+/// This probability is converted into a linear score and multiplied with the
 /// [`liquidity_penalty_multiplier_msat`] and [`liquidity_penalty_amount_multiplier_msat`]
-/// parameters to get a concrete msat value. See the documentation for those parameters for the
+/// parameters to get a concrete msat penalty. See the documentation for those parameters for the
 /// exact formulas.
 ///
 /// The liquidity bounds are then decayed by halving them every [`liquidity_offset_half_life`].
 ///
-/// Further, we track the history of our upper- and lower- liquidity bounds for each channel,
+/// Further, we track the history of our upper and lower liquidity bounds for each channel,
 /// allowing us to assign a second penalty (using [`historical_liquidity_penalty_multiplier_msat`]
 /// and [`historical_liquidity_penalty_amount_multiplier_msat`]) based on the same probability
 /// formula, but using the history of a channel rather than our latest estimates for the liquidity
@@ -406,15 +406,16 @@ pub struct ProbabilisticScoringParameters {
 	/// [`liquidity_offset_half_life`]: Self::liquidity_offset_half_life
 	pub liquidity_penalty_multiplier_msat: u64,
 
-	/// We track upper and lower bounds on the available liquidity in a channel in order to
-	/// calculate success probability given recent successes and failures. In order to ensure we do
-	/// not get stuck avoiding channels which only failed once, we decay these bounds over time.
-	///
 	/// Whenever this amount of time elapses since the last update to a channel's liquidity bounds,
 	/// the distance from the bounds to "zero" is cut in half. In other words, the lower-bound on
 	/// the available liquidity is halved and the upper-bound moves half-way to the channel's total
 	/// capacity.
 	///
+	/// Because halving the liquidity bounds grows the uncertainty on the channel's liquidity,
+	/// penalties for payments that are within the liquidity bounds will be decreased. See the
+	/// [`ProbabilisticScorer`] struct documentation for more info on the way the liquidity bounds
+	/// are used.
+	///
 	/// For example, if the channel's capacity is 1 million sats, and the current upper- and lower-
 	/// liquidity bounds are 200,000 sats and 600,000 sats, after this amount of time the upper-
 	/// and lower- liquidity bounds will be decayed to 100,000 and 800,000 sats.