Correct the on-path timelock delta explanation

Channels cannot be excluded from the anonymity set based on *small*
timelock deltas, but rather based on large deltas.

The original wording seems to suggest that channels could be excluded
based on their max-cltv-expiry values
(https://www.lightningnode.info/advanced-tools/lnd.conf).  But these
values are not currently broadcast like cltv_expiry_deltas are, so I'm
guessing the author simply confused the concepts.

Additionally, the shadow routes described in BOLT 7 mitigate the
cltv_expiry_delta de-anonymization problem, not the max-cltv-expiry one.

16_security_privacy_ln.asciidoc

@@ -191,8 +191,8 @@ Hence, the adversary can exclude any nodes from the sender's or the receiver's a
 Therefore, we observe a trade-off between privacy and payment amounts.
 Typically, the larger the payment amount is, the smaller the anonymity sets are.
 We note that this leakage could be minimized with multipart payments or with large capacity payment channels.
-Similarly, payment channels with small timelock deltas could be excluded from a payment path.
-More precisely, a payment channel cannot pertain to a payment if the remaining time the payment might be locked for is larger than what the forwarding node would be willing to accept.
+Similarly, payment channels with large timelock deltas could be excluded from a payment path.
+More precisely, a payment channel cannot pertain to a payment if the remaining time the payment might be locked for is less than the timelock delta required by the forwarding node.
 This leakage could be evicted by adhering to the so-called shadow routes.
 
 One of the most subtle and yet powerful leakages an on-path adversary can foster is the timing analysis.