@ -351,31 +351,37 @@ So far you have learnt that payment channels can be connected to a network which
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 couple of questions open:
- 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?
- How is it decided which path is selected along which the HTLCs for a payment to be routed are set up?
- Which nodes will know about the path?
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 first questions is that only the sender decides which path to choose.
Despite the fact that the Lightning Network is currently running the second question is still not answered in an optimal way and became a serious research topic.
For now we will only say that in the standard case the sender more or less randomly selects and tries paths of channels until it is possible to send the amount along that selected path.
With multi path payments the sender can split the amount and use the same strategy with multiple pahts.
More deails will be discuss in the advanced section about path finding.
There we explore and explain the current approach which seems to work good enough most of the time.
You will also learn about potential improvements that are currently being researched in that chapter.
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.
The short answer to the third question is that 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 whether 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 is fundamentally different to the best effort routing approach implemented on the internet protocol.
This technique is fundamentally different to the best effort routing approach that is implemented on the internet protocol.
Best effort routing is know to have poor privacy protection of the transfered data and needs end to end encryption on the upper layers to be secure.
To get rid of these problems the Lightning Network utilizes a sourced base onion routing based on the SPHINX Mix format.
Very roughly speaking the SPHINX Mix format can be compared with the onion routing that is well known from the TOR network.
As many upper layer protocols did not include end to end encryption we learnt from the Snoweden revelations that spying agencies have been massivily collecting data that was transfered over the internet together with the meta data like IP addresses of senders and recipients.
To get rid of these problems the Lightning Network utilizes a sourced base onion routing based on the SPHINX Mix format.
The SHINX mix format was originally designed to allow email remails to offer the possability to send an answer without creating a security threat of the remailer service being able to know who was communicating with whom.
In that sense and very roughly speaking the SPHINX Mix format can be compared with the onion routing that is well known from the TOR network.
[NOTE]
====
While the Lightning Network also uses an onion routing scheme 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 onchain bitcoin transactions.
While the Lightning Network also uses an onion routing scheme it is actually very differnt to the onion routing scheme that is used 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 and transfer data that encodes monitary value.
On the Lightning Network there is no analogy to the exit nodes of the Tor Network which on the TOR network produce a security risk. Lightning user should still not get theimpression that their data and information is perfectly secure. Knowing the announced fee rates and CLTV deltas a node might be able to guess the destination of an onion.
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.
On the TOR network 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 onchain 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.
@ -394,8 +400,8 @@ They are chosen by Alice in a way that only the rightful recipient of an onion c
For example after Bob received the onion from Alice he will be able to decrypt the first layer and he will only see the information that he is supposed to forward the onion to Wai by setting up an HTLC with Wei.
The HTLC with Wei should use the same Payment Hash as the receiving HTLC from Alice.
The amount of the forwarded HTLC was specified in Bob decrypted layer of the onion.
It will be slightly smaller the the imount of his incoming HTLC from Alice.
The difference of these two amounts has to be at least as big as to cover the routing fees that Bob's node announced earlier.
It will be slightly smaller than the imount of his incoming HTLC from Alice.
The difference of these two amounts has to be at least as big as to cover the routing fees that Bob's node announced earlier on the gossip protocol.
In order to set up the HTLC Bob will modify the onion a little bit.
He removes the information that he could read from it and passes it along to Wei.
@ -406,17 +412,18 @@ In this way every participant is only able to peel of one layer of the onion by
Each participant will 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 sent 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 the inside of Wei's, and Gloria's Layer and can thus does 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.
Thus he cannot know that Gloria is the final destination of the payment. **TODO: Is this actually true, given the CLTV deltas?** )
The only thing Bob knows is that he was involved in a path that involved Alice, him and Wei.
While the Onion is decrypted layer by layer it while it travels along the path from Alice via Bob and Wei to Gloria it is created from the inside layer to the outside layers via several rounds of encryption.
While the Onion is decrypted layer by layer while it travels along the path from Alice via Bob and Wei to Gloria it is created from the inside layer to the outside layers via several rounds of encryption.
Being created from the inside means that the construction starts with the Onion Package that Gloria is supposed to receive in plain text.
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.
The onions are a data structure that consists of four parts:
The onions are a data structure that at every hop consists of four parts:
1. The Version byte
2. The header sonsisting of a public key that can be used by the recipient to produce the shared secret for decrypting the outer layer and to derieve the public key for the next recipient.
1. The version byte
2. The header consisting of a public key that can be used by the recipient to produce the shared secret for decrypting the outer layer and to derieve the public key that has to be put in the header of the modified onion for the next recipient.
3. The payload
4. an authentication via an HMAC.
@ -427,14 +434,15 @@ This data can come in two formats the legacy one and the Type Length Value (TLV)
While the TLV format offers more flexability in both cases the routing information that is encoded into the onion is the same for every but the last hop.
On the last hop the TLV information departs from the legacy information as it allows to include a preimage.
This is nice as it allow a payer to initiate a payment without the neccessity to ask the payer for an invoice and payment hash first.
We will this feature called key send in a different chapter.
A node needs three pieces of information to forward the package:
1. The short channel id of the next channel along which it is supposed to forward the onion by setting up an HTLC with the same payment hash.
2. The amount that it is supposed to be forwarded and thus being used in the HTLC.
3. Timelock information is the last piece of information that is needed as HTLCs are hashed time locked contracts.
3. Timelock information encoded to a `cltv_delta` is the last piece of information that is needed as HTLCs are hashed time locked contracts.
For easier readability we have used shorts as `short_channel_ids` in the following example and graphics.
For easier readability we have used just a mall integer as `short_channel_ids` in the following example and graphics.
[[routing-onion-1]]
.`per_hop` payload of Glorias onion and the encrypted
We can see that Alice has created some per hop data for David.
The short channel id is set to 0 signaling David that this payment is intended to be for him.
The amount to forward is set to 300.
On the incoming HTLCs David should have seen the same amount.
The amount to forward is set to 3000.
On the incoming HTLCs David should have seen that exact amount.
Usually this amount is intended to say how many satoshis should be forwarded.
Since the short channel id was set to zeor in this particular case it is interpreted as the payment amount.
Since the short channel id was set to zero in this particular case it is interpreted as the payment amount.
Finally the CLTV delta which David should to forward the payment is also set to zero as David is the final hop.
According to the protocol the per hop data can have up to 20 Byte as this is not used up the remaining space will be filled with zeros which we did not depict in the picture.
On important feature to protect the privacy is to make sure that onions are always of equal length independ of their position along the payment path.
Thus onions are always expected to contain 20 entries with fields of per hop data.
As David is the final recipient there is onlye reasonable data for one field with per hop data.
This is not a problem as the other 19 fields are filled with junk data.
After Alice has set all the data she needs to encrypt the onion payload.
For this she derives a shared secret between Davids public node key and the private secrete that she generated for David.
This process is also well known as an Elliptic Curve Diffie Hellmann key exchange and a standard technique in cryptography and Bitcoin.
TODO: does it really need an outgoing CLTV value on the last hop or does it have to match the CLTV value of the last offered HTLC... details :(
ALice puts the encrypted payload inside the full Onion Package which contains a the public keys from the secrete key that she used to derive the shared secrete.
When David receives the Onion package he will extract the public key from the unencrypted part of the onion package.
The property of the Elliptic Curve Diffie Hellmann key exchange is that if he multiplies this public key with his private node key he will get the same shared secret as a result as Alice did.
However others cannot derive the same shared secrete as they neither know Alice's nor David's private key.
[Note]
====
Let `(d,D)` be the secret and Public key of David and let G be the generator point of the elliptic curve so that `D = d*G`.
similarily let `(ek_d, EPK_D)` the ephemeral keys that Alice has generated for David such that the Publikc ephemeral Key `EPK_D = ek_d*G`.
Alice computed the shared secret as ss_`d = ek_d*D`.
Using the definition of public keys this is the same as `ek_d*(d*G)=(ek_d*d)*G`.
Since multiplication with the generator point is a group homomorphism we can apply the law of associativity.
And because the secretes are just numbers modulo some prime we can change the order of the multiplication resulting in `ss_d = (d*ek_d)*G`.
With the same argument as before we apply the law of associativity and apply the definition of public keys resulting in `(d*ek_d)*G = d*(ek_d*G) = d*EPK_D`.
We just saw why `ek_d*D = d*EPK_D = ss_d` and why Alice and Davide will be able to derive the same shared secrete if Alice puts the ephmeral pubilic key inside the onion.
====
Alice now creates the Onion for Wei.
Again she starts with the obviously necessary data which are the short channel id, the amount to forward and the CLTV delta that Wei should use when he forwards the Onion.
This data is stored as the per hop data and is appened with a few padding zeros and the onion payload that Alice previously computed for David.
As the onions have to be of equal length Alice will not Use the entire payload data that she has computed for David but she will trunkate the last couple bytes and throw them away.
this is the plaintext version of Weis Onion payload.
We emphasize that Wei has no chance to decrypt the inner part of the onion.
However the information for Wei should also be protected from others.
Thus Alice conducts another ECDH.
This time with Wei's public key and and emphemeral keypair that she has generated particularly for Wei.
She uses the shared secret to encrypt the onion payload and would be able to construct the entire onion.
Note that in the entire onion there will be Wei's empheral public key and in the encrypted inside part Davids ephemeral public key is not stored.
After Wei decrypts his layer he can use the shared secrete and his Emphermal public key to derrive the Empheral public key that David is supposed to use.
The exact progress to generate the empheral keys for every hope will be explained at the very end of the chapter.
What is important to know is that every hope can derive the Ephemeral Public key that is necessary for the next hop and that the onions save space by always storing only one ephemeral key instead of all the keys for all the hops.
Finally after Alice has computed the encrypted version for Wei she will use the exact same process to compute the encrypted version for Bob.
For Bobs onion she actually computes the header and provides the emphemeral public key herself.
Note how Wei was still supposed to forward 3000 satoshis but How Bob was supposed to forward a different amount.
The difference is the routing fee for Wai.
Bob on the other hand will only forward the onion if the difference between the mount to forward and the HTLC that Alice sets up while transfering the Onion to him is large enough to cover for the fees that he would like to earn.
[NOTE]
====
We have not discussed the exact cryptographic algorithms and schemes that are being used to compute the cypthertext from the plain text.
Also we have not discussed how the HMACs are being computed at every step and how everything fits together while the Onions are always being trucated and modified on the outer layer.
If everything until here made perfect sense to you and you want to learn about those details we believe that you have all the necessary tools at hand to read BOLT 04 which is why we decided not to include all those technical details here in the book.
BOLT 04 is the open source specification of the onion routing scheme that is being used on the Lightning Network and a perfect resource for the missing details.
====
TODO: everything from here on will most likely change and could even be redundant.
Rene Pichardt
4 years ago