Wrote up this section, describing how the onion layers are peeled as it moves across the route, as well as giving examples of how malicious entities could potentially use packet size to spy on and de-anonymize users
* 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 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 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 one of the channel partners of the second last routing node (we ignore the case of private channels).
In all cases, some privacy of the payer and the recipient are lost.
We can extend this example.
Imagine a malicious entity sets up multiple Lightning nodes connected to well-connected nodes, as well as 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, many companies and businesses in this space use a publicly known name for their routing nodes.
If we see, for example, a payment with destination "Bitrefill", 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 and could form a more complete picture of the payment.
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.
It would have no way of determining 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 it is not the recipient and that the recipient is someone it is connected to by up to 20 hops.
Imran
4 years ago