Today I decided to analyze a paper discussing attacks against the privacy of the lightning network.

The paper is here: https://arxiv.org/pdf/2003.12470 and it is called “An Empirical Analysis of Privacy in the Lightning Network.”

It analyzes a number of attacks on LN privacy, including one I found particularly interesting, the discussion of which contains this sentence: “We thus developed a tracing heuristic, which follows the “peeling chain” initiated at the opening and closing of public channels to identify any associated private channels.” (page 6)

The Peeling Attack (page 6)

The peeling attack is designed to identify unannounced channels on the lightning network. As part of the attack (the name for which I made up), they identified all outputs on the blockchain that could feasibly be channel opening transactions on the lightning network, and then checked how those outputs were spent.

Some of them were “channel closure” transactions, confirmed by this method: they observed that the transaction sent money to a lightning node who had public channels, and they confirmed *that* by observing that the recipient *spent* the money to open a “public” channel, which showed up in the public channel graph. Since they identified channel closure transactions of a channel that was not announced on the public graph, they knew it must be an unannounced channel.

A particularly poignant sentence is this one: “Out of the 27,183 transactions we identified as representing the opening of private channels, we were able to identify both participants in 2,035 (7.5%), one participant in 21,557 (79.3%), and no participants in 3,591 (13.2%).”

By identifying many unannounced channels via their opening and closing transactions, they could get the total capacity of those channels, as well as the “final” balance of both parties when the channel closed.

What are the weaknesses of this attack? Some are: it only finds unannounced channels if they are in a peel chain, that is, a series of transactions that keep opening and closing channels using a particular utxo and its change; it does not identify unannounced channels that are not part of a peel chain; it does not get anyone’s channel balance while the channel is open, only its total channel capacity; when it identified a channel closure, it only learned the “final” balance of the two nodes, not their transaction history.

The Targeted Probing Attack (page 8)

Regarding balances, they also have an attack for guessing the internal balances of an individual announced channel, though the attack has weaknesses. The attack is discussed in section 4, page 8 of the paper. It’s similar to Rene Pickhardt’s channel probing attack, but I will dub the new method the “targeted probing attack,” as opposed to Rene’s attack, which I dub the “dragnet probing attack.”

The targeted probing attack requires identifying a channel, which they call B -> C, where B and C are lightning nodes and the arrow is the channel between them. Then the attacker must open two “attacker” channels (the dragnet method requires only one channel), one with B and another with C. Then the attacker sends a series of payment probes, such that their channel with B is always the “from” channel and their channel with C is always the “to” channel. By only having those two channels, they know the payment probe must pass through B and C.

If the payment makes it to the destination node, then they infer that the capacity of B -> C is split up in such a way that B has at least that much money on his side of the channel; then they cancel the payment and try again with a higher amount, and keep doing they reach the channel’s capacity or the payment fails. (That’s a bit simplified; they optimize the number of transactions they must try by doing a binary search, but whatever.) At that point, they infer that the internal balance of node B in the channel B -> C is just below whatever amount failed (if there was a failure), or is just the entire capacity of the channel (if there never was a failure), and the balance of C is whatever’s leftover of the capacity of the channel.

They admit that the targeted probing attack has a weakness: “[In] the case in which there is more than one intermediate channel between the two attacker nodes…the above method identifies the bottleneck balance in the entire path, rather than the balance of an individual channel.” (page 9) Consequently, B and C may have channels between them that the attackers don’t know about (e.g. unannounced channels that weren’t in a peel chain), and thus this attack does not for-sure discern the internal balance of B for a particular channel, it only finds that he has *at most* whatever amount they got through. E.g. if they got a payment of $500 through, maybe B only had $200 on his side of the B -> C channel they were probing, but he had $300 or more in another channel with C that they didn’t know about, and routed the remainder through that channel.

The AOH Attack (Assume One Hop - page 10)

The paper discusses an attack for guessing the senders and recipients in a lightning payment, in section 5, “Path Discovery,” on page 10. They describe their attack thusly: “The strategy of our…adversary is simple: they always guess that their immediate predecessor is the sender. … Similarly, they always guess that their immediate successor is the recipient.”

Their attack relies on the assumption that most nodes will try to pass their payment through the shortest possible route to the destination, and that this means most payments will actually only have one hop: “the route to the destination in LN is constructed solely by the payment sender. All clients generally aim to find the shortest path in the network, meaning the path with the lowest amount of fees.” (page 11)

They simulate this attack in section 5.1 (page 11), where they say they took “snapshots” of the lightning network’s public nodes and channels (specifically, they say their methodology for getting the snapshot is outlined in section 3.1 on page 5, and that section only mentioned public nodes and channels – unannounced ones are only discussed later, in section 3.2). Then they assigned a routing algorithm semi-randomly to each node on this network, where the algorithms were re-written versions of the routing algorithms used by LND, CLN, and Eclair. Then they pretended these nodes sent simulated payments to one another at random, and checked how often a routing node was right if a payment passed through it and it guessed that the node before it was the sender and the node after it was the recipient. They were correct 56.65% of the time.

What are the weaknesses of this attack? Well, they were *wrong* about a single hop 43.35% of the time, so that’s already pretty damaging to their case. But also, they were working on a constrained network: they completely excluded private nodes as possible senders, and it is a lot easier to guess the sender/recipient when your simulator excludes, right at the start, a huge number of nodes that could otherwise be the sender/recipient.