It is an anonymous key agreement protocol that allows two parties, each having an elliptic-curve public–private key pair, to establish a shared secret over an insecure communication channel.
This shared secret may be directly used as a key, or to derive another key.
The key, or the derived key, can then be used to encrypt subsequent communications using a symmetric-key cipher.
An example of the derived key would be the ephemeral key used by the SPHINX Mix Format.
An example of the derived key would be the shared secrete between the ephemeral session key of a sender of an onion with the nodes public key of a hop of the onion as described and used by the SPHINX Mix Format.
Via https://en.wikipedia.org/w/index.php?title=Elliptic-curve_Diffie%E2%80%93Hellman&oldid=836070673
@ -349,39 +349,79 @@ Error handling and encryption for HTLCs
So far you have learnt that payment channels can be connected to a network which can be utilized to send payment from one participant to another one through a path of payment channels.
You have seen that with the use of HTLCs the intemediary nodes along the path are not able to steal any funds that they are supposed to forward and you have also learnt how a node can set up and settle an HTLC.
While this is all great it leaves a 2big questions open:
While this is all great it leaves a couple of questions open:
- How is it decided which path is selected to route a payment?
- Who choses the path and which nodes will know about the path?
- How is it decided which path is selected along which the HTLCs for a payment to be routed are set up?
- Who chooses the path?
- Which nodes will know about the path?
The first question is still not answered in an optimal way and became a serious research topic.
However there is an approach that currently works fair enough and we will explain it, with its up and downsides and potential different approaches and enhancements in the next chapter about pathfinding.
Here we will focus on the seconds question.
Despite the fact that the Lightning Network is currently running the first question is still not answered in an optimal way and became a serious research topic.
We explore and explain the current approach which seems to work good enough most of the time and some potential improvements that are currently being researched in the chapter about path finding.
Here we will focus on the second and thrid questions.
The short answer to the question is that only the sender decides which path to choose and no other node in the network learns about this path.
We exepect you to be surprised that this is actually possible which is why we devote the remainder of this chapter to talk about source based onion routing.
This is a technique which is fundamentally different to the best effort routing approach implemented on the internet protocol and can be to a first approximation best be compared with Onion routing that is well known from the TOR network.
The short answer to the questions is that only the sender decides which path to choose and no other node in the network learns about this path.
Nodes along the path only learn on which channel they received a payment and on which channel they are supposed to forward it.
Neither do they know of the peer on the receiving channel initiated the payment nor do they know whether the peer on the outgoing channel is the final recipient of the payment.
We exepect you to be surprised that it is actually possible to create such an algorithm with modern cryptography.
This is why we will now devote quite some space to write and discuss about source based onion routing.
This is a technique which is fundamentally different to the best effort routing approach implemented on the internet protocol which is know to have poor privacy protection of the transfered data and needs end to end encryption on the upper layers to be secure.
Very roughly speaking the routing of payments on the Lightning Network can be compared with Onion routing that is well known from the TOR network.
So lets stick with our example that Alice still wants to tip Gloria and has decided to use the path via Bob and Wei.
[NOTE]
====
While the Lightning Network also uses an onion routing it is actually very differnt to the onion routing scheme in the TOR network.
The biggest difference is that TOR is being used for arbitrary data to be exchanged between two participants where on the Lightning Network the main usecase is to pay people.
For example on the Lightning Network there is no analogy to the exit nodes of the Tor Network which produce a security risk. However since nodes forward funds and with the cheap fees have to see almost the exact payment amount they can make a good guess about the content of the package (not about the sender or recipient though).
In tor the security can be compromised if all randomly chosen tor hops are acting together. In Lightning the payment hash identifies a payment and thus not every node along the path needs to be compromised in order to attack the security.
With TOR nodes are basically connected via a full graph as every node could create an encrypted connection with every other node on top of the Internet Protocol almost instantaneously and at no cost. On the Lightning Network payments can only flow along existing payment channels. Removing and adding of those channels is a slow and expensive process as it requires on chain bitcoin transactions.
On the Lightnign Network nodes might not be able to forwad a payment package because they do not own enough funds on their side of the payment channel. On the other hand there are hardly any plausible reasons other then its wish to act malliciously why a TOR node might not be able to forward an onion.
Last but not least the Lightning Network can actuly run on TOR.
This means that all connections of a node with its peers and the resulting communication will by obfuscated once more through the TOR network.
====
Lets stick to our example that Alice still wants to tip Gloria and has decided to use the path via Bob and Wei.
We note that there might have been alternative paths from Alice to Gloria but for now we will just assume it is this path that Alice has decided to use.
You have already learnt that Alice needs to set up an HTLC with Bob via and `update_add_htlc` message.
If you recall the `update_add_htlc` message you will remember that it containes a data field of 1366 Bytes in length that is the Onion Package.
This onion cointains all the information about the path that Alice intends to use to send the paymen to Gloria.
This onion cointains all the information about the path that Alice intends to use to send the payment to Gloria.
However Bob who receives the Onion cannot read all the information about the path as most of the onion is hidden from him through a sequence of encryptions.
The name onion comes from the analogy to an onion that consits of several layers where in our example every layer corresponds to an encryption.
The encryption keys are chosen in a way that the recipient can only peel (decrypt) the top layer of the onion.
Bob will only see the information that he is supposed to Forward the payment to Wei.
The name onion comes from the analogy to an onion that consits of several layers where in our example every layer corresponds to one round of encryption.
Each round of encryption uses different encryption keys.
They are chosen in a way that the recipient can only peel (decrypt) the top layer of the onion.
Bob will only see the information that he is supposed to forward the onion to Wai.
After Boab saw this he will modify the onion a little bit to remove his information from it and pass it a long to Wei.
Wei in turn is only able to see that he is supposed to forwad the package to Gloria.
Wai knows he recieved the onion from Bob but has no clue that it was actually Alice who initiated the onion in the first place.
In this way every participant can peel of one layer of the onion by encrypting it and only learn the information it has to learn to fullfil the routing request.
For example Bob will only know that Alice offered him an HTLC and send him an onion and that he is supposed to offer an HTLC to Wei and forward a slightly modified onion.
Bob does not know if Alice is the originator of this payment as she could also just have forwarded the payment to him.
Due to the layered encryption he cannot see th inside of Weis, and Glorias Layer and can thus not know that Gloria is the final destination of the payment.
Due to the layered encryption he cannot see the inside of Wei's, and Gloria's Layer and can thus does not know that Gloria is the final destination of the payment.
The only thing Bob knows is that he was involved in a path that involved Alice, him and Wei.
Interestingly enough Alice can construct the onion with different encryption keys for Bob, Wei and Gloria without the necessity to estable a peer connection with them.
She only needs a Public key from each participant which is the public `node_id` of the lightning node and known to Alice.
She only needs a public key from each participant which is the public `node_id` of the lightning node and known to Alice.
As other nodes she has learnt about the existance of public payment cannels and the public `node_id` of other participants via the gossip protocol which we described in its own chapter.
In order to have a different encryption key for every layer Alice produces a shared secrete with each hop using the public `node_id` of each node and conduct an Elliptic Curve Diffi Hellmann Key exchange (ECDH).
She starts by generating a temporary session key.
This key will also be called the ephemeral key.
This private key multiplied with the generator Point of the Elliptic curve that is being used in Bitcoin produces a public key.
This happens in the same way how the nodes public key is generated from the secrete private key of the node.
Alice could use this session keys to conduct the diffi hellmann key exchange if she would send the public key with the onion.
However she wishes to use a different session key to conduct the diffie Hellmann key exchange with each of the nodes along the path.
**TODO**: WHY?!
Yet she does not want to add a public key (which consumes quite some space) into every layer of the onion.
Luckily there is a nice deterministic way in which she can derive different sessions keys for every hop and execute the Diffi Hellmann and allow the hops to use their shared secrete to derieve the next session public key.
Lets explore this in detail with the following example:
[Note]
====
Of course the Lightning Network protocol could have been designed in a way that Alice will only use her node's key to conduct the ECDH with every nodes public key.
However she would have to put her public key in the header of the onion.
This is necessary for nodes to be able to execute an ECDH and produce the same shared secrete that Alice used for the respective layer of the Onion.
However with that information nodes would know that Alice was the originator of the payment lifting the anonymity of the payer by design.
====
Let us now look at the construction of the Onion that Alice has to follow and at the exact information that is being put inside each layer of the onion.
Rene Pickhardt
4 years ago