lnbook/security_privacy_ln.asciidoc

[[security_and_privacy_of_ln]]
== Security and Privacy of the Lightning network
In this chapter, we look at the issues related to the security and privacy of the LN.

= Why privacy is important? =

The key value proposition of cryptocurrency is censorship resistant money.
It has been shown many times that the power of governments over money is often abused.
Bitcoin offers individuals a possibility of storing and transferring their wealth without restrictions.

Lightning continues this mission.
It aims at providing a better user experience with instant payments while not sacrificing censorship resistance.
However, the LN operates under a different security model, which introduces novel security and privacy challenges.

= Definitions of privacy =

Privacy is a complex topic.
It is hard to define precisely what we mean by privacy.
Therefore, the question: "Is Lightning private?" has no direct answer.
However, privacy researchers approach this question as follows.
First, they define a _security model_ that specifies what exactly an adversary is capable of and what they aim to achieve.
Then, they describe the relevant properties of the system and check whether it conforms to the relevant requirements.
A security model is based on a set of underlying _security assumptions_.
In cryptographic systems, they are often centered around the mathematical properties of the cryptographic primitives such as ciphers, signatures, and hash functions.
The security assumptions of the Lightning network are that the ECDSA signatures, SHA-256 hash function, and other cryptographic functions used in the protocol behave within their security definitions.
For example, we assume that it is practically impossible to find a pre-image of a hash function.
This allows the LN to rely on the HTLC mechanism for the atomicity of multi-hop payments: nobody except the final recipient can resolve the HTLC before the payment secret is revealed.
We also assume a degree of connectivity in the network: that Lightning channels form a connected graph (therefore, it is possible to find a path from any sender to any receiver), and that network messages get propagated within certain timeouts.

Here are some possible models of adversaries in the Lightning network.
A regular "honest-but-curious" forwarding node can observe payment amounts, the immediately preceding and following nodes, the graph of announced channels with their capacities.
A very well-connected node can do the same but to a larger extent: for example, a node belonging to a popular wallet may be responsible for routing a large share of payments to and from the users of that wallet.
An even stronger adversary model implies that multiple nodes are under adversarial control.
If it so happens that two colluding nodes are on the same payment path, they would be able to understand that they are forwarding HTLCs belonging to the same payment (they share the same payment hash).

What may be the goals of a Lightning attacker?
Information security is often described in terms of three main properties: confidentiality, integrity, and availability.
Confidentiality means that the information only gets to intended recipients.
Integrity implies that the information does not get altered in transit.
Availability ensures that users may expect the system to be functioning most of the time.

The important properties of the Lightning network are mostly centered around confidentiality and availability.
Here are some of the properties we may want to ensure:

* nobody except the sender and the receiver knows the payment amount
* nobody can link senders and receivers
* nobody can block an honest user from sending and receiving payments

For each privacy goal and security model, there is a certain probability that an attacker succeeds.
This probability depends on various factors, such as the size and the structure of the network.
Other things equal, it is generally easier to attack a small network rather than a large one.
Similarly, the more centralized the network is, the more capable an attacker can be, if "central" nodes are under their control.
Of course, the notion of "centralization" must be defined precisely to build security models around it, and there are many possible definitions of how centralized a network is.
Finally, as a payment network, the LN depends on economic stimuli.
The size and structure of fees affect the routing algorithm and, therefore, can either aid the attacker by forwarding most payments through their nodes, or prevent this from happening.


=== Anonymity set

What does it mean to deanonymize someone?
In simple terms, deanonymization implies linking some action with a person's "real world" identity, such as their name or physical address.
In privacy research, the notion of deanonymization is more nuanced.
First, we are not necessarily talking about names and addresses.
Discovering someone's IP address or telephone number may also be considered deanonymization.
A piece of information that allows linking a user's action to their previous actions is referred to as _identity_.
Second, deanonymization is not binary.
A user is not either fully anonymous or completely deanonymized.
Instead, privacy research looks at anonymity compared to the _anonymity set_.

The anonymity set is a central notion in privacy research.
It refers to the set of identities such that, from an attacker's viewpoint, a given action could correspond to any of them.
Consider a real-life example.
Imagine you meet a person on a city street.
What is their anonymity set from your point of view?
If you don't know them personally, and without any additional information, their anonymity set roughly equals the population of the city, including travelers.
If you consider additionally their appearance, you may be able to roughly estimate their age and exclude the city residents who are obviously older or younger than the person in question from the anonymity set.
Furthermore, if you notice that the person walks into the office of Company X using an electronic badge, the anonymity set shrinks to the number of Company X's employees and visitors.
Finally, you may notice the license number of the car they used to arrive at the place.
If you are a casual observer, this doesn't give you much.
However, if you are a city official and have access to the database that matches license plate numbers with names, you can narrow down the anonymity set to just a few people: the car owner and their closest friends and relatives.

This example illustrates a few important points.
First, every bit of information may bring the adversary closer to their goal.
It may not be necessary to shrink the anonymity set to the size of one.
For instance, if the adversary plans a targeted DoS attack and can take down 100 servers, the anonymity set of 100 suffices.
Second, the adversary can cross-correlate information from different sources.
Even if a privacy leak looks relatively benign, we never know what it can achieve in combination with other data sources.
Finally, especially in cryptographic settings, the attacker always has the "last resort" of brute force search.
Cryptographic primitives are designed so that it is practically impossible to guess a secret such as a private key.
Nevertheless, each bit of information brings the adversary closer to this goal, and at some point it becomes attainable.

In terms of Lightning, deanonymizing generally means deriving a correspondence between payments and users identified by node IDs.
Each payment may be assigned a sender anonymity set and a receiver anonymity set.
Ideally, the anonymity set consists of all the users of the network.
This assures that the attacker has no information whatsoever.
However, the real network leaks information that allows an attacker to narrow down the search.
The smaller the anonymity set, the higher the chance of successful deanonymization.


=== Differences between LN and Bitcoin in terms of privacy

Bitcoin was initially perceived as an anonymous currency.
Indeed, addresses are not linked to real identities.
However, all transactions are broadcast in cleartext and can be analyzed.
Multiple companies deanonymize users of Bitcoin and other cryptocurrencies.

At the first glance, Lightning provides better privacy than Bitcoin because Lightning payments are not broadcast to the whole network.
While this improves the privacy baseline, other properties of the Lightning protocol may make anonymous payments more challenging.
For instance, larger payments have fewer routing options.
This may allow an adversary who controls well-capitalized nodes to route most large payments and discover payment amounts and probably other details.
Another relevant difference between Lightning and Bitcoin is that Lightning nodes maintain a permanent identity, whereas Bitcoin nodes do not.
A Bitcoin user can easily switch nodes used to receive blockchain data and broadcast transactions.
A Lightning user, on the contrary, sends and receives payments through the nodes they have opened channels with.
Moreover, the Lightning protocol assumes that routing nodes announce their IP address in addition to their node ID.
This creates a permanent link between node IDs and IP addresses, which may be dangerous, considering that an IP address is often an intermediary step in anonymity attacks that is linked to the user's physical location and in most cases real-world identity.
It is possible to use Lightning over Tor, but a large portion of nodes does not use this functionality.

A Lightning user when sends a payment has its neighbors in its anonymity set.
Specifically, a router node does not know whether the payment originates from the sender or any of its neighbors, or from a neighbor of a neighbor etc.
Therefore, the anonymity set of a node in Lightning is roughly equals to its neighbors.
Similar logic applies to payment receivers.
Many users open only a handful of payment channels, therefore, limiting their anonymity sets.
Moreover, in Lightning, the anonymity set is static or at least slowly changing.
In contrast, one can achieve significantly larger anonymity sets in on-chain CoinJoin transactions.
CoinJoin transactions with anonimity sets larger than 50 are quite frequent and typically the anonymity sets in a CoinJoin transaction correspond to a dynamically changing set of users.


Finally, Lightning users can also be denied service, having their channels blocked by the attacker.
Forwarding payments requires capital - a scarce resource! - to be temporarily blocked in in-flight HTLCs along the route.
An attacker may send many payments but fail to finalize them, occupying honest user's capital for long periods.
This attack vector is not present (or at least not as obvious) in Bitcoin.

In summary, while some aspects of the Lightning network's architecture suggest that it is a step forward in terms of privacy compared to Bitcoin, other properties of the protocol may make attacks on privacy easier.
Thorough research is needed to evaluate which privacy guarantees Lightning provides and how to improve the state of affairs.
We are happy to report that multiple researchers teams are researching Lightning privacy.
This chapter is in part a summary of the research papers available at the time of writing, in late 2020.
Now let us review the attacks on the Lightning network privacy that have been described in academic literature.


= Attacks on Lightning =

Recent research describes various ways in which the security and privacy of the LN may be compromised.

== Observing payment amounts

One of the natural goals for a privacy preserving payment system is to hide payment amount from uninvolved parties.
Lightning network is an improvement over layer-one in this regard.
While Bitcoin transactions are broadcast in cleartext and can be observed by anyone, Lightning payments only travel through a few nodes along the payment path.
However, intermediary nodes do see the payment amount.
This is necessary to create a new HTLC at every hop.
The availability of payment amount to intermediary nodes does not present an immediate threat.
However, an _honest-but_curious_ intermediary node may use it as a part of a larger attack.


== Linking senders and receivers

An attacker might be interested in learning the sender and/or the receiver of a payment to reveal certain economic relationships.
This breach to privacy could harm censorship resistance, as an intermediary node could censor payments to/from certain receivers/senders.
Ideally, linking senders to receivers should not be possible to peers other than the sender or the receiver of the payment.
In the following, we will consider two types of adversaries: the off-path and the on-path adversary.
The off-path adversary tries to assess the sender/receiver of a payment without participating in the payment routing process.
On the other hand, an on-path adversary can leverage any information it might gain by routing the payment, she wants to learn more information about.

First, let us consider the *off-path adversary*.
In the first step of this attack scenario, a potent off-path adversary deduces the individual balances in each payment channels via probing and forms a network snapshot at time _t_.
It then runs the attack sometime later at time _t'_ and uses the differences between the two snapshots to infer information about payments that took place by looking at any paths that changed.
In the simplest case, if only a single payment occurred between time _t'_ and _t_, then the off-path adversary can see a single path in which the balances changed by some amount and thus learn everything about this payment: the sender, the recipient, and the amount.
If multiple payments overlap in the path they use, then the adversary needs to heuristically identify such overlap and separate the payments accordingly.

Now, we turn our attention to an *on-path adversary*.
Such an adversary might seem convoluted.
However, the single most central node is already capable of observing close to 50% of all payments in the network, while the four most central nodes observe an average of 72% payments.
These findings emphasize the relevance of the on-path attacker model.
Even though intermediaries in a payment path, only learn their successor and predecessor, there are several leakages that a malicious or honest but curious intermediary could use to infer the sender and/or receiver of a payment.

The on-path adversary can observe the amount of any payment routed through her, as well as time-lock deltas.
Hence, the adversary can exclude any nodes from a sender's/receiver's anonymity set with lower capacity, than the routed payment amount.
Therefore, we observe a tradeoff between privacy and payment amounts.
Typically, the larger the payment amount is, sender and/or receiver obtain smaller anonymity sets.
We note, that this leakage could be minimized with multi-part payments or with large capacity payment channels.
Similarly, payment channels with small time-lock 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 is larger than the time the forwarding node would be willing to accept.
This leakage could be evicted by adhering to the so-called shadow routes.

One of the most subtle and yet powerful leakage an on-path adversary can foster is the timing analysis.
An on-path adversary can log for every routed payment how much time it takes for a node to respond to an HTLC request.
Before starting the attack, the attacker learns latency characteristics of every node in the Lightning network by sending them requests.
Naturally, this can aid in establishing the adversary's precise position in the payment path.
Even more, as it was recently shown, an attacker can successfully determine the sender and the receiver of a payment from a set of possible senders and receivers using time-based estimators.

Last but not least, we remark that several, yet unknown, leakages might exist that can aid deanonymizing attempts, for instance, even the knowledge of the applied routing algorithm could help excluding certain nodes from being a sender and/or receiver of a payment.
We note, that different Lightning wallets apply different routing algorithms.
Likely, many more leakages exist.

== Revealing channel balances (probing)

The balances of Lightning channels are supposed to be private for privacy and efficiency reasons.
A Lightning node only knows the balances of its adjacent channels.
The protocol provides no standard way to query the balance of a remote channel.

However, an attacker can reveal the balance of a remote channel in a _probing attack_.
In information security, probing refers to the technique of sending requests to a targeted system and making conclusions about its private state based on the received responses.

Lightning channels are prone to probing.
Recall that a standard Lightning payment starts with the receiver creating a random payment secret and sending its hash to the sender.
Note for the intermediary nodes all hashes look random.
There is no way to tell whether a hash corresponds to a real secret or was generated randomly.

The probing attack proceeds as follows.
Say, the attacker Mallory wants to reveal Alice's balance of a public channel between Alice and Bob.
Suppose the total capacity of that channel is 1 million satoshis.
Alice's balance could be anything from zero to 1 million satoshis (to be precise, the estimate is a bit tighter due to channel reserve, but we don't account for it here for simplicity).
Mallory opens a channel with Alice with 1 million satoshis.
Mallory then sends a payment of 500 thousand satoshis to Bob via Alice using a _random number_ as the payment hash.
Of course, this number does not correspond to any known payment secret.
Therefore, the payment will fail.
The question is: how exactly will this payment fail?

There are two scenarios.
If Alice has more than 500 thousand satoshis on her side of the channel to Bob, she forwards the payment to him.
Bob decrypts the payment onion and realizes that the payment is intended for him.
He looks up his local store of payment secrets in search of the secret that corresponds to the payment hash but does not find one.
Following the protocol, Bob returns the "unknown payment hash" error to Alice, who relays it back to Mallory.
As a result, Mallory knows that the payment _could have succeeded_ if the payment hash was real.
Therefore, Mallory can update her estimation of Alice's balance from "between zero and 1 million" to "between 500 thousand and one million."
Another scenario happens if Alice's balance is lower than 500 thousand satoshis.
In that case, Alice is unable to forward the payment and returns the "insufficient balance" error to Mallory.
Mallory updates her estimation from "between zero and 1 million" to "between zero and 500 thousand."

Note that in any case, Mallory's estimation becomes twice as precise after just one probing!
She can continue probing, choosing the amount of the next fake payment such that it divides the current estimation interval in half.
This well-known search technique is called _binary search_.
With binary search, the number of probes is _logarithmic_ in the desired precision.
For example, to obtain Alice's balance in a channel of 1 million satoshis up to a single satoshi, Mallory would only have to perform log2(1000000) ~ 20 probings.
If one probing takes 3 seconds, one channel can be precisely probed in only about a minute!

Channel probing can be made even more efficient.
In its simplest variant, Mallory directly connects to the channel she wants to probe.
Is it possible to probe a channel without opening a channel to one of its endpoints?
Imagine Mallory now wants to probe a channel between Bob and Charlie but doesn't want to open another channel, which requires paying on-chain fees and waiting for confirmations of the funding transactions.
Instead, Mallory re-uses her existing channel to Alice and sends a probe along the route Mallory - Alice - Bob - Charlie.
Mallory can interpret the "unknown payment hash" error in the same way as before: the probe has reached the destination, therefore, all channels along the route have sufficient balances to forward it.
But what if Mallory receives the "insufficient balance" error?
Does it mean that the balance is insufficient between Alice and Bob or between Bob and Charlie?

In the current Lightning protocol, error messages report not only _which_ error occurred but _where_ it occurred as well.
So, with more careful error handling, Mallory now knows which channel failed.
If this is the target channel, she updates her estimates; if not, she chooses another route to the target channel.
Note that she even gets _additional_ information about the balances of intermediary channels, on top of that of the target channel.

The probing attack can be enhanced further.
Mallory can probe the network periodically and reveal the flow of individual payments in the Lightning network.
In the simplest case, Mallory observes only the following difference between two subsequent snapshots: the balances in a chain of channels have shifted in one direction by the same amount.
Therefore, Mallory can re-create the payment with high certainty.
This attack can break both the secrecy of payment amount as well as the sender-receiver relationship.
Of course, in the real network, multiple payments may happen along intersecting paths during the time between the snapshots.
Still, mathematical models allow to partially re-create payments even in that case.

At this point, you may ask: why does the Lightning network do such a poor job at protecting its users' private data?
Wouldn't it be better to not reveal to the sender why and where the payment has failed?
Indeed, this could be a potential countermeasure, but it has significant drawbacks.
Lightning has to strike a careful balance between privacy and efficiency.
Remember that regular nodes don't know balance distributions in remote channels.
Therefore, payments can (and often do) fail because of insufficient balance at an intermediary hop.
Error messages allow the sender to exclude the failing channel from consideration when constructing another route.
A popular Lightning wallet Zap even performs probing internally to check whether a constructed route can really handle a payment.

There are other potential countermeasures against channel probing.
First, it is hard for an attacker to target unannounced channels.
Second, nodes that implement JIT routing are less prone to the attack.
Finally, as multi-part payments make the problem of insufficient capacity less severe, the protocol developers may consider hiding some of the error details without harming efficiency.

References:

* Jordi Herrera-Joancomartí et al. [On the Difficulty of Hiding the Balance of Lightning Network Channels](https://eprint.iacr.org/2019/328)
* Nisslmueller et al. [Toward Active and Passive Confidentiality Attacks On Cryptocurrency Off-Chain Networks](https://arxiv.org/abs/2003.00003)
* Tikhomirov et al. [Probing Channel Balances in the Lightning Network](https://arxiv.org/abs/2004.00333)
* Kappos et al. [An Empirical Analysis of Privacy in the Lightning Network](https://arxiv.org/abs/2003.12470)
* [Zap source code with the probing function](https://github.com/LN-Zap/zap-desktop/blob/v0.7.2-beta/services/grpc/router.methods.js)

== Denial of service
When resources are made publicly available, there is a risk that attackers may attempt to make that resource unavailable by executing a denial-of-service attack.
Generally, this is achieved by the attacker bombarding a resource with requests, which are indistinguishable from legitimate queries.
The attacks seldom result in the target suffering financial loss aside from the opportunity cost of their service being down and are merely intended to grief the target.

Typical mitigations for denial-of-service attacks are to require authentication for requests to separate legitimate users from malicious ones, or to incur a cost that is trivial to regular users but will act as a sufficient deterrent to an attacker launching requests at scale.
Anti-denial-of-service measures can be seen everywhere on the internet - websites apply rate limits to ensure that no one user can consume all of their server’s attention, film review sites require login authentication to keep angry r/prequelmemes members at bay, and API keys are purchased to allow a limited number of hits.

=== DoS in Bitcoin
In Bitcoin, the bandwidth that nodes use to relay transactions and the space that they avail to the network in the form of their mempool are publicly available resources.
Any node on the network can consume bandwidth and mempool space by sending a valid transaction.
If this transaction is mined in a valid block, they will pay transaction fees, which adds a cost to using these shared network resources.

In the past, the Bitcoin network faced an attempted denial-of-service attack where attackers spammed the network with low-fee transactions.
Many of these transactions were not selected by miners, due to their low transaction fees, so the attackers were able to consume network resources without the full financial disincentive of fees in place.
To address this issue, a minimum transaction relay fee which set a threshold fee that nodes require to propagate transactions was set.
This measure largely ensured that the transactions that consume network resources will eventually pay their chain fees; a fee which is acceptable to regular users, but would hurt attackers financially if they tried to spam the network.
While some transactions may not make it into valid blocks during high fee environments, these measures have largely been effective at disincentivizing this type of spam.

=== DoS in Lightning
Similarly to Bitcoin, the Lightning Network charges fees for use of its public resources, but in this case, the resources are public channels and the fees come in the form of routing fees.
The ability to route payments through nodes in exchange for fees provides the network with a large scalability benefit - nodes that are not directly connected can still transaction - but it comes at the cost of exposing a public resource which must be protected against DoS attacks.

When a Lightning node forwards a payment on your behalf, it uses bandwidth to update its commitment transaction, and the amount of the payment is reserved in their channel balance until it is settled or failed.
In the case of successful payments, this is acceptable because the node is eventually paid out its fees.
Failed payments do not charge fees in the current protocol, which allows nodes to costlessly route failed payments through your node’s channels.
This is great for legitimate users, who wouldn’t like to pay for failed attempts, but also allows attackers to costlessly consume nodes resources - much like the low-fee transactions on Bitcoin that never ended up paying miner fees.

At the time of writing, a discussion is [ongoing](link?) on the lightning-dev mailing list as to how best address this issue.

=== Known DoS attacks
There are two known DoS attacks on public Lightning channels which render a target channel, or set of target channels unusable.
Both attacks involve routine payments through a public channel, then holding them until their timeout, thus maximizing the duration of the attack.
The requirement to fail payments so as not to pay fees is fairly simple to meet because malicious nodes can simply reroute payments to themselves.
In the absence of fees for failed payments, the only cost to the attacker is the on-chain cost of opening a channel to dispatch these payments through, which can be trivial in low fee environments.

==== Commitment jamming
Lightning nodes update their shared state through the use of asymmetric commitment transactions, on which HTLCs are added and removed to facilitate payments.
Each party is limited to a total of https://github.com/lightningnetwork/lightning-rfc/blob/c053ce7afb4cbf88615877a0d5fc7b8dbe2b9ba0/02-peer-protocol.md#the-open_channel-message[483] on the commitment at a time.
A channel jamming attack allows an attacker to render a channel unusable by routing 483 payments through the target channel and holding them until they timeout.

It should be noted that this limit is arbitrary, and was chosen in the specification to ensure that all the HTLCs can be swept in a [single justice transaction](ref?).
While this limit _may_ be increased, transactions are still limited by the block size, so the number of slots available is likely to remain limited.

==== Channel liquidity lockup
A channel liquidity attack is comparable to a channel jamming attack, in that it routes payments through a channel and holds them so that the channel is unusable.
Rather than locking up slots on the channel commitment, this attack routes large HTLCs through a target channel which consumes all the available bandwidth on the channel.
The capital commitment required for this attack is higher than the commitment jamming attack because the attacking node needs more funds to route failed payments through the target.

References:

* Mizrahi, A., Zohar, A. https://arxiv.org/abs/2002.06564[Congestion Attacks in Payment Channel Networks]

= Cross-layer deanonymization =

Computer networks are often layered. Layering allows for separation of concerns and makes the whole thing manageable.
No one could be able to design a website if it required understanding all the TCP/IP stack up to the physical encoding of bits in an optical cable.
Every layer is supposed to provide the functionality to the layer above in a clean way.
Ideally, the upper layer should perceive a lower layer as a black box.
In reality, though, implementations are not ideal and the details _leak_ into the upper layer.
This is the problem of leaky abstractions.

In the context of Lightning, the LN protocol relies on the Bitcoin protocol and the Lightning P2P network.
Up to this point, we only considered the privacy guarantees offered by LN in isolation.
However, creating and closing payment channels are inherently performed on the Bitcoin blockchain.
Consequently, for a complete analysis of LN's privacy provisions, one needs to consider every layer of the technological stack users might interact with.
Specifically, a deanonymizing adversary can and will use not only off-chain but also on-chain data to cluster or link LN nodes to corresponding Bitcoin addresses.

What might be the goals of a deanonymizing attacker in a cross-layer context?

  * Cluster Bitcoin addresses owned by the same user (layer-1). We call these Bitcoin entities.
  * Cluster LN nodes owned by the same user (layer-2).
  * Unambiguously link sets of Lightning nodes to the sets of Bitcoin entities that control them.

Hereby, we describe several heuristics, usage patterns, that allow an adversary to cluster Bitcoin addresses and LN nodes owned by the same LN users.
Moreover, these clusters can be linked across layers using other powerful cross-layer linking heuristics.
The last type of heuristics, cross-layer linking techniques, emphasize the need for a holistic view of privacy.


*On-Chain Bitcoin Entity Clustering*
LN-blockchain interactions are permanently reflected in the Bitcoin entity graph.
Therefore, even if a channel is closed, it can be observed which address funded the channel or where the coins are spent after closing the channel.
We differentiate between four entities.
Opening a channel causes a monetary flow from a _source entity_ to a _funding entity_; closing a channel causes a flow from a _settlement entity_ to a _destination entity_.

https://arxiv.org/pdf/2007.00764.pdf[Romiti et al.] identified four heuristics that allow the clustering of the aforementioned Bitcoin entities.
Two of them captures certain leaky funding behavior and two describes leaky settlement behaviors.

  * Star Heuristic (Funding): if a component contains one source entity that forwards funds to one or more funding entities, then these funding entities are likely controlled by the same user.
  * Snake Heuristic (Funding): if a component contains one source entity that forwards funds to one or more entities, which themselves are used as source and funding entities, then all these entities are likely controlled by the same user.
  * Collector Heuristic (Settlement): if a component contains one destination entity that receives funds from one or more settlement entities, then these settlement entities are likely controlled by the same user.
  * Proxy Heuristic (Settlement): if a component contains one destination entity that receives funds from one or more entities, which themselves are used as settlement and destination entities, then these entities are likely controlled by the same user.

It is worthwhile pointing it out that these heuristics might produce false positives.
For instance, if transactions of several unrelated users are combined in a CoinJoin transaction, then the Star or the Proxy heuristic can produce false positives.
This could happen if users are funding a payment channel from a CoinJoin transaction.
Another potential source of false positives could be that an entity could represent several users if clustered addresses are controlled by a service (e.g., exchange) or on behalf of their users (custodial wallet).
However, these false positives can effectively be filtered out.

_Countermeasures_: If outputs of funding transactions are not reused for opening other channels, the snake heuristic would not work.
If users refrain from funding channels from a single external source and avoid collecting funds in a single external destination entity, the other heuristics would not yield any significant results.

*Off-Chain Lightning Node Clustering*
LN nodes advertise aliases, for instance, _LNBig.com_.
Aliases can improve the usability of the system.
However, users tend to use similar aliases for their own different nodes.
For example, _LNBig.com Billing_  likely owned by the same user as the node with alias _LNBig.com_.
Given this observation, one can cluster LN nodes applying their node aliases.
Specifically, one clusters LN nodes into a single address if their aliases are similar with respect to some string similarity metric.

Another method to cluster LN nodes is applying their IP or Tor addresses.
If the same IP or Tor addresses correspond to different LN nodes, then these nodes are likely controlled by the same user.

_Countermeasures_: For more privacy, aliases should be sufficiently different from one another.
While the public announcement of IP addresses may be unavoidable for those nodes that wish to have incoming channels in the LN, linkability across nodes of the same user can be mitigated if the clients for each node are hosted with different service providers and thus IP addresses.

*Cross-Layer Linking: Lightning Nodes and Bitcoin Entities*
Associating LN nodes to Bitcoin entities is a serious breach to privacy, that is exacerbated by the fact that most LN nodes publicly expose their IP addresses.
Typically, an IP address can be considered as a unique identifier of a user.
There are two widely observed behavior patterns that reveal links between LN nodes and Bitcoin entities.

  * Coin reuse: whenever users close payment channels they get back their corresponding coins. However, many users reuse those coins in opening a new channel.
Those coins can effectively be linked to a common LN node.

  * Entity reuse: typically users fund their payment channels from Bitcoin addresses corresponding to the same Bitcoin entity.

These cross-layer linking algorithms could be foiled if users possess multiple unclustered addresses or use multiple wallets to interact with the LN.

The possible deanonymization of Bitcoin entities hereby presented shows that it is crucial to consider the privacy of both layers simultaneously instead of one of them at a time.

// maybe here we should/could include the corresponding figures from the Romiti et al. paper.
// it would greatly improve and help the understanding of the section

= Lightning graph =

The Lightning network, as its name already suggests, is a network.
It is a peer-to-peer network of nodes that manage payment channels between each other.
Therefore, many of its properties (privacy, robustness, connectivity, routing efficiency), are influenced and characterized by its network nature.

In this section, we discuss and analyse the LN from a network scientific point of view.
Particularly, we are interested in understanding the LN channel graph, its robustness, connectivity and other important characteristics.

== What is a graph anyway?
A graph is a mathematical model that consists of nodes and edges (connections between nodes).
In the LN, nodes represent LN nodes and edges represent payment channels between them.
In many cases, just like in LN, edges can have attributes, for instance, numerical values.
In case of LN, these numerical attributes of the edges can represent the capacity of a payment channel.
We call the degree of a node the number of edges/payment channels it has.

== How does the Lightning graph look like in reality?
One could have expected that the LN is a random graph, where edges are randomly formed between nodes.
If this was the case, then the degree distribution of the LN would follow a Gaussian normal distribution.
In particular, most of the nodes would have approximately the same degree and we would not expect nodes with extraordinarily large degrees.
This is because the normal distribution exponentially decreases for values not lying in the neighborhood of the average value of the distribution.
The depiction of a random graph looks like a mesh network topology.
It looks decentralized and non-hierarchical, namely, every node seems to have equal importance.
Additionally, random graphs have a large diameter.
In particular, routing in such graphs is challenging as the shortest path between any two nodes are moderately long.

However, in stark contrast, the LN graph is completely different.

=== Lightning graph today
Lightning is essentially a financial network.
Thus, the growth and formation of the network is also influenced by economic incentives.
Whenever a node joins the LN, it may want to maximise its connectivity to other nodes in order to increase its routing efficiency.
Initially, many Lightning clients were favoring nodes with high degrees in channel establishment.
By the result of this, it will be even more likely that newly joining nodes will connect to high-degree nodes.
This phenomenon is called preferential attachment.
These economic incentives result in a fundamentally different network than a random graph.

Based on snapshots of publicly announced channels, the degree distribution of the LN follows a power-law function.
In such a graph the vast majority of nodes have very few connections to other nodes, while only a handful of nodes have numerous connections.
At a high-level, this topology resembles a star topology, in which there are a well-connected core and a loosely connected periphery.
Networks with power-law degree distribution are also called scale-free networks.
This topology is advantageous for routing payments efficiently, however, it is prone to certain topology-based attacks.

=== Topology-based attacks

An adversary might want to disrupt the Lightning network.
Its goal is to dismantle the whole network into many smaller components, making payment routing practically impossible in the whole network.
A less ambitious, but still malicious and severe goal might be to only take down certain nodes of the network.
Such a disruption might occur on the node-level or on the edge-level.

Let's suppose an adversary is capable of taking down any node in the LN, for instance, it can DDoS them or make them unoperational by any means.
It turns out that if the adversary chooses nodes randomly, then scale-free networks like the LN are robust against node-removal attacks.
This is because a random node lies on the periphery with a small number of connections, therefore playing a negligible role in the network's connectivity.
However, if the adversary is more prudent, then it can target the most well-connected nodes and only take those down.
Not surprisingly, the LN and other scale-free networks are _not_ robust against such targeted node-removal attacks.

On the other hand, the adversary could be more stealthy in its attack.
There are several known topology-based attacks, that target a single node or a single payment channel.
For example, an adversary might be interested in exhausting the capacity on a certain payment channel on purpose.
More generally, an adversary can deplete all the outgoing capacity of a node to knock it down from the routing market.
This could be easily obtained by routing payments through the victim node with amounts equalling to the outgoing capacity of each payment channel.
After the completion of this so-called node isolation attack, the victim cannot send or route payments anymore, unless it receives a payment or rebalances its channels.

To conclude, even by design, it is possible to remove edges and nodes from the routable LN.
However, depending on the utilized attack vector, the adversary may have to provide more or fewer resources to carry out the attack.

=== Temporality of the LN

The LN is a dynamically changing, permissionless network.
Nodes can freely join or leave the network as well as they can open and create payment channels anytime they want.
Therefore, it is essential to not only consider a single static snapshot of the LN graph but rather one needs to take into consideration the temporality and ever-changing nature of the network.
We can assert that the LN graph is growing in terms of the number of nodes and payment channels.
Its effective diameter is also shrinking, that is, nodes become closer to each other.

In social networks, triangle closing behavior is common.
Specifically, in a graph where nodes represent people and friendships are represented as edges, it is somewhat expected that triangles will emerge in the graph.
A triangle in this case represents pairwise friendships betwee three people.
For instance, if Alice knows Bob and Bob knows Charlie, then it is likely that at some point Bob will introduce Alice to Charlie.
However, this behavior would be strange in the LN.
Nodes are simply not incentivised to close triangles as they could have just routed payments instaed of opening a new payment channel.
Surprisingly, in the LN triangle closing is a common practice.
The number of triangles was steadily growing prior to the implementation of multi-part payments.
This is counterintuitive and surprising given that nodes could have just routed payments through the two sides of the triangle instead of opening the third channel.
This may mean that recently there were many routing inefficiencies that incentivised users to close triangles and not fall back on routing.
Hopefully, multi-part payments help to increase the effectiveness of payment routing.

In general, our understanding is rather limited about the dynamic nature of the LN channel graph.
It is fruitful to analyse how protocol changes like multi-part paymets, can effect the dynamics of the LN.
It would be beneficial to explore this area in more depth.

//shall we talk about centrality measures?
the centrality metrics are as follows.
This means that Lightning is (very? Moderately? Not very?) centralized.
The tendency goes towards (more? less?) centralization.
This may lead to (more? fewer?) attacks of these types...

=== Economic incentives and graph structure
The Lightning graph forms spontaneously.
Nodes connect to each other based on mutual interest.
As a result, incentives drive graph development.
Let’s describe some of the relevant incentives:

  * Rational incentives.
    - Nodes establish channels to send, receive, and route payments (earn fees).
    - What makes a channel more likely to be established between two nodes that act rationally?
  * Altruistic incentives.
    - Nodes establish channels “for the good of the network”.
    - While we should not base our security assumptions on altruism, to a certain extent altruistic behavior drives Bitcoin (accepting incoming connections, serving blocks).
    - What role does it play in Lightning?

How rational are Lightning users now?
How will the LN graph evolve?
Can the LN be a mesh-like network? Are there examples of successful mesh networks?

= Practical advice for users to protect their privacy =

Now you may be wondering: how do I protect my privacy as a Lightning user today?
Here are some tips.
== Who should I open channels to?
Should I connect to a large hub? Multiple hubs? Some random small nodes? I want my payments to be reliable but don’t want to contribute to LN centralization - what is the trade-off?

== Accepting incoming channels
Can it be a bad idea to accept an incoming channel? I’m happy that people want to route through my node! What do I have to lose?

== Setting parameters for routing payments
The number of allowed HTLCs, the minimal payment amount, trade-offs involved.

= Future of privacy in the LN =
The Lightning network is an exciting technology but there may be economic forces that drive it to a centralization.
One paper claims that…