* minor improvements to chapter "Onion Routing"
- improvement of English
- some additions
- etc.
* removed portion that is in doubt
* put TOR stuff into footnote
* clarified analogy
* removed extreme, setting more realistic expectations
- https://github.com/lnbook/lnbook/pull/201#discussion_r420513603
* added the two requested changes
Co-authored-by: Rene Pickhardt <r.pickhardt@gmail.com>
@ -445,18 +445,47 @@ This includes currently known public payment channels, known nodes, known topolo
==== Onion routing
If the sending node of a payment has selected a path that is supposed to be used to make the payment, the Lightning Network uses an onion routing scheme similar to the famous TOR-network.
The routing scheme is called the SPHINX mixformat and will be explained in detail in a later chapter.
For now we want to focus on its properties for the transport of payments which we also call onions.
1. The most important property is that a routing node can only see on which channels it received an onion and on which channel to set up an HTLCs and thus to which peer to forward the onion. This means that no routing node can know who initiated the payment and for whom the payment is supposed to be. The exception of course would be if the node is the recipient. In that case it would know that it was the final destination.
2. The onions are small enough to fit into a single TCP/IP package and actually even a link layer frame. This will make traffic analysis for intruding the privacy of the payments almost impossible.
3. The onions are constructed in a way that they will always have the same length independent of the position of the processing node along the path.
4. Onions can have up to 20 hops included allowing for sufficiently long paths.
5. The encryption of the onion for every hop uses different ephemeral encryption keys with every single onion. Should a key (in particular the private key of the public node key) leak at some point in time an attacker who collected onions cannot decrypt the other onions that have been stored.
The routing scheme is called the "SPHINX mixformat" and will be explained in detail in a later chapter.
Note that Lightning Onion routing via "SPHINX mixformat" is only similar to the TOR network routing in conecpt, but as a protocol as well as in implementation it is definitely different from the TOR network.
For now we want to focus on its properties for the transport of payments.
A payment package used for routing is called an "onion".
footnote:[The term "onion" was originally used by the TOR project.
The acronym TOR stands for "The Onion Router".
Moreover, the Tor network is also called the Onion network.
The Tor project uses an onion as its logo and the top level domain name used by TOR services on the internet is ".onion".]
As a simplified physical analogy imagine the payment package as a sealed box with a onion inside.
On its route from payer to payee the sealed box is handed from node to node.
Sealed just means that the box is encrypted and only the receiving node can open it.
As will be explained, each node opens the box, takes out the onion, and peals off the outermost layer of this onion by using a cryptographic key.
The receiving node can only read this outermost layer, no further layers, achieved through cryptography.
This outermost layer tells the node if the box needs to be routed further and along which channel which implies the next node.
The node than places the remaining, but one layer smaller, onion into the box and sends the box to the next node on the routing path.
This continues until the receiving node is the payee and the routing stops and the payee can read the information encrypted in the innermost layer of the onion.
Why use a box?
The box is used in this analogy to express that the size of the "package" sent along the route is always the same.
The first recipient receives a box of the same size as the last recipient, the payee.
This is done to create privacy.
If not done, an observer could analyze the size of the communication and deduce how many hops there are on the route.
If the size does not change there is no way to tell if this is the first or the last hop in the route.
The box in our analogy is what technically is called an "onion" in the Lightning network.
1. The most important property is that a routing node can only see on which channel it received an onion and on which channel to set up an HTLCs and thus to which peer to forward the onion.
This means that no routing node can know who initiated the payment and to whom the payment is destined.
The exception is the payee.
The payee knows that it is the final destination.
This is one of the many factors that help in the quest for a high degree of privacy.
2. The onions are small enough to fit into a single TCP/IP package and actually even a link layer frame.
This will make traffic analysis of the payments significantly more difficult, increasing privacy further.
3. The onions are constructed in a way that they will always have the same length independent of the position of the processing node along the path.
This is also done to augment privacy.
4. Onions can have up to 20 hops or onion layers if you prefer. This allows for sufficiently long paths.
5. The encryption of the onion for every hop uses different ephemeral encryption keys with every single onion. Should a key (in particular the private key of the public node key) leak at some point in time an attacker who collected onions cannot decrypt other onions.
In simpler terms, keys are never reused in order to achieve more security.
6. Errors can be sent back from the erring node in an encrypted way to the original sender. This is particularly useful as we have seen that Lightning nodes who initiate the onions select a path without knowing whether every node has enough liquidity along their channels to forward the payment.
As mentioned we will discuss the details of the Onion Format later but we note already that the `Payment Hash`, while needed to set up the HTLCs for the payment, is not transported within the onions.
The `Payment Hash` is rather included in the Lightning Message that also transports the onion.
We will discuss the details of the Onion Format later. But we note already that the `Payment Hash` which is required to set up the HTLCs for the payment is not transported within the onions.
The `Payment Hash` is rather included in the Lightning Message alongside the onion.
This makes the Payment Hash obtainable without the need to decrypt any onion.
8go
4 years ago
committed by
GitHub