mirror of https://github.com/lnbook/lnbook
You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
80 lines
6.4 KiB
Plaintext
80 lines
6.4 KiB
Plaintext
Chapter overview:
|
|
* How path finding works in the network
|
|
|
|
Relevant questions to answer:
|
|
* What is packet switching? What is circuit switching? Which one does LN use today?
|
|
* In the abstract what is path finding?
|
|
* What is dijkstra's? What modifications need to be made to apply it to this domain?
|
|
* Why must path finding happen backwards (receiver to sender)?
|
|
* How is the information contained in a channel update used in path finding?
|
|
* How can errors sent during payment routing help the sender to narrow their search space?
|
|
* What is payment splitting? How does it work?
|
|
* What information can be sent to intermediate and the final node aside from the critical routing data?
|
|
* What are multi-hop locks? What addition privacy and security guarantees to they offer?
|
|
* How can the flexible onion space be used to enabled packet switching in the network?
|
|
|
|
|
|
|
|
|
|
==== Finding a path
|
|
|
|
Payments on the Lightning Network are forwarded along a path of channels from one participant to another.
|
|
Thus, a path of payment channels has to be selected.
|
|
If we knew the exact channel balances of every channel we could easily compute a payment path using any of the standard path finding algorithms taught in any computer science program.
|
|
This could even be done in a way to optimize the fees that would have to be paid by the payer to the nodes that kindly forward the payment.
|
|
However, as discussed the balance information of all channels is and cannot be available to all participants of the network.
|
|
Thus, we need to have one or more innovative path finding strategy.
|
|
These strategies must relate closely to the routing algorithm that is used.
|
|
As we will see in the next section, the Lightning Network uses a source based onion routing protocol for routing payments.
|
|
This means in particular that the sender of the payment has to find a path through the network.
|
|
With only partial information about the network topology available this is a real challenge and active research is still being conducted into optimizing this part of the Lightning Network implementations.
|
|
The fact that the path finding problem is not fully solved for the case of the Lightning Network is a major point of criticism towards the technology.
|
|
The path finding strategy currently implemented in Lightning nodes is to probe paths until one is found that has enough liquidity to forward the payment.
|
|
While this is not optimal and certainly can be improved, it should be noted that even this simplistic strategy works well.
|
|
This probing is done by the Lightning node or wallet and is not directly seen by the user of the software.
|
|
The user might only realize that probing is taking place if the payment is not going through instantly.
|
|
The algorithm currently also does not necessarily result in the path with the lowest fees.
|
|
|
|
=== Things we know about path finding
|
|
From a computer science knowledge we know that this is a maxflow problem.
|
|
|
|
|
|
=== What is "Source-Based" routing and why does the Lightning Network use it?
|
|
|
|
Source-based routing is a method of path-finding where the sender (i.e. the source) plans the route from itself, through the intermediary nodes, and finally to the destination.
|
|
Once a path has been selected, the sender sends the payment to the first intermediary node, who sends it to the second intermediary node and so on, until it reaches the destination.
|
|
While a payment is in-flight along a path, the path typically does not get changed by any of the intermediary nodes, even if a shorter path or a cheaper path (in terms of routing fees) exists.
|
|
|
|
|
|
The Lightning Network uses source-based routing at the time of writing in order to protect user privacy.
|
|
As discussed in the chapter on Onion Routing, the intermediary nodes transmitting the payment are not aware of the full path of the payment; they only know the node they received it from and the node they are sending it to.
|
|
|
|
We also cannot expect the destination to find a path.
|
|
Even if it specifies a path in the invoice, that path may no longer be viable by the time the invoice is paid, which could be several minutes or several days later.
|
|
The recipient can, however, specify "routing hints" in the invoice that may assist the sender in finding a possible path.
|
|
|
|
Furthermore, source-based routing comes with some inherent drawbacks.
|
|
The sender chooses the path based on their current understanding of the topological map of the Lightning network.
|
|
As discussed in previous chapters, this map is necessarily incomplete; the sender may not be aware of all the channels, and even if they are they will almost certainly not know the latest balances in each of the channels.
|
|
And even if the sender did have a complete topological map at one point in time, the balances of channels change with every payment, and so in a short space of time the map would become obsolete.
|
|
The standard path finding mechanism with source based onion routing that is implemented in all Lightning Network implementations is the following:
|
|
|
|
1. Select an arbitrary path of payment channels which connects sender and receiver of the payment and for which all channels have a capacity of at least the payment amount and accept HTLCs of this amount.
|
|
2. Construct the onion according to the meta data (basefee, feerate, CLTV delta) of the channels.
|
|
3. Send out the onion and see if the payment settles by nodes sending back preimages or if the payment fails.
|
|
4. If the payment fails use this knowledge to select a different path by starting at step 1.
|
|
|
|
This means that with every attampted payment nodes actually probe the network and will also learn some information about how balances are distributed.
|
|
Implementations will usually prioritice cheaper paths or exclude channels which recently have failed.
|
|
In that sense the selection is not completely arbitrary.
|
|
Still even with such heuristics in place it could still be considered as a random process or random walk through the channel graph.
|
|
There can be several reasons why the payment may fail along the way.
|
|
For example one of the nodes becomes unreachable, doesn't have the channel balance, can't accept new htlcs, has updated its fees to a higher amount, or the channel is closed in the interim.
|
|
Furthermore, there is no guarantee that the route chosen was the cheapest in terms of fees, or if a shorter path existed.
|
|
As at the time of writing, this is a design trade-off made to protect user privacy.
|
|
|
|
=== Improvements on Source based onion routing
|
|
One improvement that can be implemented is to introduce concurrency.
|
|
|
|
|