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).
.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"]
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 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.
