Edited 12_path_finding.asciidoc with Atlas code editor

12_path_finding.asciidoc

@@ -71,10 +71,12 @@ Liquidity:: The available (subset) balance that can actually be sent across the
 
 The only value known to the network (via gossip announcements) is the aggregate capacity of the channel. Some unknown portion of that capacity is distributed as each partner's balance. Some subset of that balance is available to send across the channel in one direction:
 
-----
-capacity = balance(A) + balance(B)
-liquidity(A) = balance(A) - channel_reserve(A) - pending_HTLCs(A)
-----
+++++
+<ul class="simplelist">
+<li>capacity = balance(A) + balance(B)</li>
+<li>liquidity(A) = balance(A) - channel_reserve(A) - pending_HTLCs(A)</li>
+</ul>
+++++
 
 ==== Uncertainty of Balances
 
@@ -84,16 +86,20 @@ Balances are not announced in channel updates for two reasons: privacy and scala
 
 The uncertainty problem can be described mathematically as a _range of liquidity_, indicating the lower and upper bounds of liquidity based on the information that is known. Since we know the capacity of the channel and we know the channel reserve balance (the minimum allowed balance on each end), the liquidity can be defined as:
 
-----
-min(liquidity) = channel_reserve
-max(liquidity) = capacity – channel_reserve
-----
+++++
+<ul class="simplelist">
+<li>min(liquidity) = channel_reserve</li>
+<li>max(liquidity) = capacity – channel_reserve</li>
+</ul>
+++++
 
 or as a range:
 
-----
-channel_reserve <= liquidity <= (capacity – channel_reserve)
-----
+++++
+<ul class="simplelist">
+<li>channel_reserve <= liquidity <= (capacity – channel_reserve)</li>
+</ul>
+++++
 
 Our channel liquidity uncertainty range is the range between the minimum and maximum possible liquidity. This is unknown to the network, except the two channel partners. However, as we will see, we can use failed HTLCs returned from our payment attempts to update our liquidity estimate and reduce uncertainty. If for example we get an HTLC failure code that tells us that a channel cannot fulfill an HTLC that is smaller than our estimate for maximum liquidity, that means the maximum liquidity can be updated to the amount of the failed HTLC. In simpler terms, if we think the liquidity can handle an HTLC of _N_ satoshis and we find out it fails to deliver _M_ satoshis (where _M_ is smaller), then we can update our estimate to __M__–1 as the upper bound. We tried to find the ceiling and bumped against it, so it's lower than we thought!
 
@@ -252,7 +258,7 @@ From the equation we see that if the amount is close to 0, the probability is cl
 
 In other words: "Smaller payments have a better chance of successful delivery" or "Larger capacity channels give us better chances of delivery for a specific amount" and "You can't send a payment on a channel with insufficient capacity."
 
-Now let's think about the probability of success across a path made of several channels. Let's say our first channel has 50% chance of success (P = 0.5). Then if our second channel has 50% chance of success (P = 0.5), it is intuitive that our overall chance is 25% (P = 0.25).
+Now let's think about the probability of success across a path made of several channels. Let's say our first channel has 50% chance of success (_P_ = 0.5). Then if our second channel has 50% chance of success (_P_ = 0.5), it is intuitive that our overall chance is 25% (_P_ = 0.25).
 
 We can express this as an equation that calculates the probability of a payment's success as the product of probabilities for each channel in the path(s):