copy from ch03

onion-routing-htlc-forwarding.asciidoc

@@ -0,0 +1,66 @@
+Chapter overview:
+  * introduce multi-hop HTLC forwarding + onion routing at a lower level
+
+Relevant questions to answer:
+  * Onion Routing:
+    * What is onion routing? What security guarantees does it offer?
+    * What is the Sphinx format? How does it differ from prior mixnet packet formats?
+    * How does DH randomization work? (possibly too low-level)
+    * Why is it important to keep the packet fixed sized at all times?
+    * What routing information is contained in the payload for an node?
+    * How can the routing information be extended in the future?
+  * HTLC Forwarding:
+    * How does a node gain fees when it forwards a payment?
+    * What is the "cltv delta" why does it matter? 
+    * What does a successful HTLC forwarding look like?
+    * How can a node cancel back an HTLC off-chain?
+    * What is a typical network switch/hub? How can a similar analogy be applied to forwarding HTLCs?
+    * What is the circuit map, why does a node need to maintain this?
+    * Can fails or settles be safely pipelined on the network?
+    * How does a node send an error back to the sender without knowing who they are?
+    * What dangers exist w.r.t time-locks and timely on-chain confirmation?
+
+
+=== Why is it important to keep the packet fixed sized at all times?
+
+As we have already discussed earlier in the chapter, the "onion" packet transmitted via the routing nodes has multiple layers.
+The packet starts at the sender of the payment and reaches the first routing node, who peels off the first layer.
+This layer gives it information about the payment being transmitted, such as who is the next routing node to pass it to.
+It then passes this packet to the second routing note, who peels off the second layer, and so on until the final routing node (i.e. the recipient of the payment) is reached.
+
+We know from the current design of the Lightning Network that there can be a maximum of 20 hops per Lightning payment.
+We can think of the data relating to each of these possible 20 hops as one of 20 "layers" of the packet.
+If there are 6 hops in the payment, then the first 6 layers of the packet contain information about the first six routing nodes, and the remaining 14 layers contain junk.
+If there are 20 hops in the payment, then all 20 layers of the packet contain information about the twenty routing nodes.
+
+Let us now consider the adverse case, where the packet size is NOT fixed i.e. every time a layer is peeled off of the packet, the size of the packet reduces.
+If a malicious routing node receives a packet, it can use the size of the packet to estimate how many "layers" are left in this packet.
+If it receives a packet and estimates that there are 20 layers left, i.e. a full packet, then it knows that the node who sent it the packet is the originator of the payment.
+If it receives a packet and estimates that there is 1 layer left, then it knows that the node that it is sending the packet to is the final recipient of the payment.
+Even if it receives a packet and estimates that there are 2 layers left, then it knows that it is either transmitting the packet to the last routing node (i.e. the payment recipient) or it is transmitting the packet to the second last routing node before the recipient.
+It can graph out all the channels of the second last routing node and it knows that the final recipient of the payment is either the second last routing node itself, or one of their channel partners (we ignore the case of private channels).
+In all cases, some privacy of the payer and the recipient are lost.
+
+[[malicious-routing-diagram]]
+.If the Malicious node knows there are 2 layers left, then it knows that the payment recipient is either Node 19 (and there were only 19 hops) or one of Node 19's channel partners
+image:images/malicious-routing-diagram.PNG["If the Malicious node knows there are 2 layers left, then it knows that the payment recipient is either Node 19 (and there were only 19 hops) or one Node 19's channel partners"]
+
+We can extend this example.
+Imagine a malicious entity sets up multiple Lightning nodes connected to other well-connected nodes, and it also connects itself across popular payment routes.
+These malicious Lightning nodes would then be popular routing choices for those wanting to send payments, especially if they set their routing fees low.
+The malicious nodes can then capture the data of all packets that pass through their routing nodes.
+With additional information, such as the names of the other routing nodes, it could infer who is making these payments, who is receiving them, and for what amounts.
+footnote:[Note that not all Lightning nodes are anonymous.
+It is known, for example, that the nodes "aantonop" and "1.ln.aantonop.com" are owned by the author of this book Andreas Antonopolous.
+Furthermore, companies and businesses in this space can claim ownership of a node by publicizing their node's alias and pubkey on their website or social media
+If we see, for example, a payment with destination "Bitrefill" with a node pubkey that matches Bitrefill's publicized pubkey, we could infer that someone is making a purchase from Bitrefill.
+If we know the prices of their services, we could even infer what they purchased. ]
+If it has multiple routing nodes connected to each other, it might even be responsible for transmitting several of the hops in a single payment and could form a more complete picture of the route.
+We see this example as spiritually similar to the chain analysis already performed on the Bitcoin network; even an incomplete picture of payments can be used to infer things about the parties involved and potentially de-anonymize them.
+
+Fixing the packet size solves the problem of routing nodes knowing how far a packet is along the route.
+Whenever a routing node peels off a layer, it adds another layer of junk data to the end, restoring the packet to its "full" size.
+In this way, even if a packet has already been transmitted 18 hops, the 19th routing node would still see that the packet contains enough data for up to 20 hops.
+The packet size would not provide useful information to the 19th routing node for it to determine if it was the first routing node or the second last routing node.
+If it is not the recipient itself, then it knows only that the recipient is someone it is connected to by up to 20 hops.
+Assuming a sufficiently complex network with a large number of nodes, the size of the packet then gives them no useful information about the source or the destination of the payment.

path-finding.asciidoc

@@ -34,3 +34,26 @@ While this is not optimal and certainly can be improved, it should be noted that
 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.
+=======
+=== 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.
+It is for this reason that the sender probes various paths until it finds a satisfactory path, and then sends the payment.
+The payment may fail along the way if one of the nodes becomes unreachable, doesn't have the channel balance or required, 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.