Using payment correlation attacks adversary can try to link the sender and receiver of payment by observing traffic from the potential sender to the potential receiver. Such observations can be made by the adversary nodes if they are present on the payment path or if the adversary is able to monitor the network traffic of the potential sender and receiver. In some circumstances, the adversary can detect not only his presence on the payment path, but also if the monitored nodes are the sender and receiver.
___ ____ ____ ___ | | | | | | | | --| S |->| A1 |--> ......... -->| A2 |->| R |-- |___| |____| |____| |___| S - potential sender R - potential receiver A1, A2 - adversary surveillance node For big well-distributed networks, these forms of attacks are very costly and can be economically applied only on a small set of nodes. However, if a network is centralized, with the majority of traffic passing through a small number of big nodes, an adversary's job is much easier. An adversary can monitor traffic on those nodes, or in the case of a state-funded surveillance adversary, an adversary can acquire a court order to get complete access to big nodes routing information. The adversary job can be simplified if: - A1 and A2 are the same nodes. The sender and receiver are connected through a single node, the adversary node. - A2 and R are the same nodes. The receiver is some form of custodial wallet, directly controlled or in collusion with the adversary. The adversary is going to be aware of all income transactions. The only thing left is to find out who the sender is. - S and A1 are the same nodes. If the sender is some form of custodial wallet, directly controlled or in collusion with the adversary, the sender has no privacy, so correlation attacks are unnecessary. - S->A1 is an unpublished channel. An adversary can identify S as the sender for all payments originating from S and passing through A1. - A2->R is an unpublished channel. An adversary can identify R as the receiver for all payments destined for R and passing through A2. The most notable LN payment correlations in order of severity are: * Hash correlation * Amount correlation * CLTV correlation * Timing correlation Hash correlation ================ Hash correlation is the most straightforward to detect for surveillance nodes. If adversary nodes A1 and A2 observe a payment with the same hash, they can confidently conclude that they are on the payment path. However, the adversary cannot yet determine with enough certainty whether S is the sender and R the receiver. Yet, when combined with other correlation attacks or network topology examination, the adversary can establish such a conclusion with enough probability. Fortunately, payment hash correlation is soon expected to be fixed with point time lock contracts (PTLCs)[1]. Each payment hop will use a unique lock contract point, so there will be no information that can correlate different payments. Amount correlation ================== Payment amount correlation is only slightly better than hash correlation in terms of privacy because the receiver amount on each hop is mixed with the fees of all the downstream nodes. Fees on LN are just a tiny fraction of the amount, so for the attacker fees are not an issue, especially in combination with timing correlation attacks. Single-path payments are the most vulnerable to amount correlation attacks. Besides the fact that nodes A1 and A2 will see a payment with roughly the same amount, node A2 depending on the payment amount, can conclude that R is a receiver. For instance, if the receiver is a shop that sells some product for X satoshis, and if the attacker sees a payment of around X satoshis, he can be sure that this payment goes to that shop node. Multi-path payments have better privacy because the amount is now split into multiple parts. The attacker can not easily find out what product the sender is buying. But there is still a potential correlation factor, depending on how we split the payment amount. If we split the payment into equal parts, the attacker still can find out if a partial payment is multiple of the price of some of the shop products. Also, those sub-payment paths will be easily distinguishable by the amount, just like in the case of single-path payment. So, what can be done to de-correlate sub-path payment amounts? Rather than splitting the payment amount into equal parts, we split it into predefined values. For instance: 10k, 20k, 50k, 100k, 200k, 500k, 1000k, ... satoshis. Just like physical cash. By doing so, every individual payment is part of a much larger anonymity set consisting of all the payments at that moment. Using this approach, we can split a payment into as many paths as needed until we get to the exact number of satoshis. Splitting the payment amount into enough sub-paths to get an exact amount might be an overhead if current satoshi value, fees, and latencies are taken into account. Depending on user privacy preference, the wallet can create a payment path with exact change or overpay to the closest predefined value. For instance, if there is a payment of 459,645 satoshis. Users not that interested in privacy can split: 200k + 200k + 50k + 9,645. While privacy-oriented users would overpay slightly: 200k + 200k + 50k + 10k. Now sub-payments of privacy-oriented users are mixed with all other privacy-oriented and non-privacy-oriented users. Thus, the anonymity set is increased subsectional, especially if LN is processing a huge amount of transactions per second. The drawback in splitting payment amounts into predefined values is that we might create more redundant payment[2] routes to match the reliability of sub-payments split into equal parts. When we split into equal parts, every redundant payment path can be used to replace any other failed paths. But in the case of predefined values, redundant sub-payment can replace only the sub-path with the same payment amount. CLTV correlation ================ CLTV correlation is not as serious as hash or amount correlation because it doesn't explicitly connect payment routes through adversary nodes. CLTV value does give a sense of closeness to either sender or receiver. However, if hop CLTV delta values used are exactly as the one nodes gossiped, then an attacker can potentially determine the payment path as well. This is especially true when CLTV deltas are used in combination with timing correlation, allowing the attacker to calculate all cltv path combinations between A1 and A2 and deduce if they are on the payment path. With payment route reservation [2], CLTV delta gets shuffled thanks to the payment route split. If there is no route split node can return a random CLTV value around some predefined value. Thus for the attacker's job to correlate payment with payment route reservation, using only CLTV gets much harder. Timing correlation ================== Every low-latency network is susceptible to timing correlation attacks. The adversary observes the network traffic between the potential sender and receiver, and the time of the transactions is used to make correlations. This type of attack can be carried out even without LN node if the adversary can monitor the surveilled node's network traffic. Low-traffic networks are more vulnerable to timing attacks than high-traffic networks. As the number of LN users and payments continues to grow, the potential payment set will increase, making it increasingly difficult to correlate payments using only timing analysis. To mitigate timing correlation attacks, a possible solution is to introduce a small random delay for privacy-oriented payments. This approach can make the attacker's job somewhat harder. What the attacker would most likely do is use a combination of amount, cltv, and timing correlation attacks. Each correlation attack will give some probability, and cumulative probability might reveal the payment route and, in the worst case, the sender and receiver. Therefore, it is crucial to minimize the probability of success for each attack to ensure the highest possible payment privacy. [1] https://bitcoinops.org/en/topics/ptlc/ [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003867.html Best Regards, g0b1el _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
