@ -482,9 +482,11 @@ She truncates 65 Bytes from the end of the encrypted onion and prepends the trun
The per hop data follows the same structure as the per hop data for David.
Thus she starts with the Realm Byte that she will set to 0 again.
Then comes the short channel id.
This is set to 452 as Wei is supposed to use that channel to forward the onion.
This is set to 452 as Wei is meant to use the channel with this channel ID as the next outgoing channel.
She sets the amount to 3000 satoshi as this is the amount that David is supposed to receive.
Finally she uses the CLTV delta that was announced for this channel on the gossip protocol and that Wei should use for the HTLC when he forwards the Onion.
Finally she uses the CLTV delta added to the current height that was announced for this channel on the gossip protocol and that Wei should use for the HTLC when he forwards the Onion.
Notice how this CTLV expiry (the expiry is the current height plus the delta) increase as we travel forwards (towards the sender) in the route.
As we'll see later, this series of decrementing time-locks must carefully be set in order to avoid time-based race conditions in the created contracts.
Again 12 Bytes of zeros are padded and an HMAC is computed.
Note that she did not have to compute filler this time as she already has too much data with the encrypted inner onion.
That is why the inner onion had to be truncated at the end.
@ -494,10 +496,10 @@ This is the plain text version of Weis Onion payload and can be seen in the foll
.`per_hop` payload of Glorias onion and the encrypted
image:images/routing-onion-4.png[]
We emphasize that Wei has no chance to decrypt the inner part of the onion.
We emphasize that Wei cannot decrypt the inner part of the onion (that's still encrypted from his PoV), as he cannot derive the encryption keys.
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 ephemeral keypair that she has generated particularly for Wei.
This time with Wei's public key and the randomized ephemeral key pair.
She uses the shared secret to encrypt the onion payload.
She would be able to construct the entire onion for Wei - which actually Bob does while he forwards the onion.
The Onion that Wei would receive can be seen in the following diagram:
@ -507,16 +509,15 @@ The Onion that Wei would receive can be seen in the following diagram:
image:images/routing-onion-5.png[]
Note that in the entire onion there will be Wei's ephemeral public key.
David ephemeral public key is not stored anywhere in the onion.
Neither in the header, nor in the payload data.
However we have seen that David needed to have this key in the header of the Onion that he received.
We've omitted the details here for brevity, but notice how only a single ephemeral key is communicated.
During processing each node will re-randomize the ephemeral key for the following node.
Luckily the ephemeral keys that Alice used for the ECDH with David can be derived from the ephemeral key that she used for Wei.
Thus after Wei decrypts his layer he can use the shared secret and his ephemeral public key to derive the ephemeral public key that David is supposed to use and store it in the header of the Onion that he forwards to David.
The exact progress to generate the ephemeral keys for every hope will be explained at the very end of the chapter.
Similarly it is important to recognize that Alice removed data from the end of Davids onion payload to create space for the per hop data in Wei's onion.
Thus when Wei has received his onion and removed his routing hints and per hop data the onion would be to short and he somehow needs to be able to append the 65 Bytes of filled junk data in a way that the HMACs will still be valid.
This process is of filler generation as well as the process of deriving the ephemeral keys is described in the end of this 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.
What is important to know is that every hop 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.
@ -529,8 +530,7 @@ Bob on the other hand will only forward the onion if the difference between the
====
We have not discussed the exact cryptographic algorithms and schemes that are being used to compute the ciphertext 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 truncated 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.
For readers seeking more details with respect to the cryptographic algorithms used, we invite them to review BOLT 04 itself in full.
====
TODO: everything from here on will most likely change and could even be redundant.
Olaoluwa Osuntokun
4 years ago