Update onion-routing-htlc-forwarding.asciidoc

onion-routing-htlc-forwarding.asciidoc

@@ -37,8 +37,8 @@ Let us now consider the adverse case, where the packet size is NOT fixed i.e. ev
 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).
+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.
 
 We can extend this example.