Re: [Lightning-dev] Payment correlation attacks
Hi g0b1e, I wanted to add to this excellent summary that there is a trade off here. The harder you make payment correlation the easier you make channel jamming. If payments can not be correlated at all it's possible to make payment paths that cycle through the same nodes many times over. This allows an adversary to lock up e.g. 10x the channel capacity on a target channel than the coins they commit to the attack. See: https://bitcoinproblems.org/problems/ptlc-cycle-jamming.html Cheers, LL On Mon, 27 Mar 2023 at 10:26, g0b1el via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > > 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
[Lightning-dev] Payment correlation attacks
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
