((("security and privacy","importance of privacy")))The key value proposition of cryptocurrency is censorship resistant money. Bitcoin offers participants the possibility of storing and transferring their wealth without interference by governments, banks, or corporations. The Lightning Network continues this mission.
((("security and privacy","importance of privacy")))The key value proposition of cryptocurrency is censorship resistant money. Bitcoin offers participants the possibility of storing and transferring their wealth without interference by governments, banks, or corporations. The Lightning Network continues this mission.
Unlike trivial scaling solutions like custodial Bitcoin banks, the Lightning Network aims to scale Bitcoin without compromising on self-custody, which should lead to greater censorship resistance in the Bitcoin ecosystem. However, the Lightning Network operates under a different security model, which introduces novel security and privacy challenges.
Unlike trivial scaling solutions like custodial Bitcoin banks, the Lightning Network aims to scale Bitcoin without compromising on selfcustody, which should lead to greater censorship resistance in the Bitcoin ecosystem. However, the Lightning Network operates under a different security model, which introduces novel security and privacy challenges.
=== Definitions of Privacy
=== Definitions of Privacy
((("security and privacy","definitions of privacy", id="ix_16_security_privacy_ln-asciidoc1", range="startofrange")))The question: "Is Lightning private?" has no direct answer. Privacy is a complex topic; it is often difficult to precisely define what we mean by privacy, particularly if you are not a privacy researcher. Fortunately, privacy researchers use processes to analyze and evaluate the privacy characteristics of systems, and we can use them too! Let's look at how a security researcher might seek to answer the question, "Is Lightning private?" in two general steps.
((("security and privacy","definitions of privacy", id="ix_16_security_privacy_ln-asciidoc1", range="startofrange")))The question, "Is Lightning private?" has no direct answer. Privacy is a complex topic; it is often difficult to precisely define what we mean by privacy, particularly if you are not a privacy researcher. Fortunately, privacy researchers use processes to analyze and evaluate the privacy characteristics of systems, and we can use them too! Let's look at how a security researcher might seek to answer the question, "Is Lightning private?" in two general steps.
First, a privacy researcher would define a _security model_ that specifies what an adversary is capable of and aims to achieve.
First, a privacy researcher would define a _security model_ that specifies what an adversary is capable of and aims to achieve.
Then, they would describe the relevant properties of the system and check whether it conforms to the requirements.
Then, they would describe the relevant properties of the system and check whether it conforms to the requirements.
@ -18,10 +18,10 @@ Then, they would describe the relevant properties of the system and check whethe
==== Process to Evaluate Privacy
==== Process to Evaluate Privacy
((("security and privacy","evaluation process for privacy")))((("security assumptions")))A security model is based on a set of underlying _security assumptions_.
((("security and privacy","evaluation process for privacy")))((("security assumptions")))A security model is based on a set of underlying _security assumptions_.
In cryptographic systems, these assumptions are often centered around the mathematical properties of the cryptographic primitives such as ciphers, signatures, and hash functions.
In cryptographic systems, these assumptions 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.
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 preimage (and second preimage) of a hash function.
For example, we assume that it is practically impossible to find a preimage (and second preimage) of a hash function.
This allows the LN to rely on the HTLC mechanism (which uses the preimage of a hash function) for the atomicity of multihop payments: nobody except the final recipient can reveal the payment secret and resolve the HTLC.
This allows the Lightning Network to rely on the HTLC mechanism (which uses the preimage of a hash function) for the atomicity of multihop payments: nobody except the final recipient can reveal the payment secret and resolve the HTLC.
We also assume a degree of connectivity in the network, namely that Lightning channels form a connected graph. Therefore, it is possible to find a path from any sender to any receiver. Finally, we assume network messages are propagated within certain timeouts.
We also assume a degree of connectivity in the network, namely that Lightning channels form a connected graph. Therefore, it is possible to find a path from any sender to any receiver. Finally, we assume network messages are propagated within certain timeouts.
Now that we've identified some of our underlying assumptions, let's consider some possible adversaries.
Now that we've identified some of our underlying assumptions, let's consider some possible adversaries.
@ -58,18 +58,18 @@ Other things being equal, it is generally easier to successfully attack a small
Similarly, the more centralized the network is, the more capable an attacker can be if "central" nodes are under their control.
Similarly, the more centralized the network is, the more capable an attacker can be if "central" nodes are under their control.
Of course, the term centralization must be defined precisely to build security models around it, and there are many possible definitions of how centralized a network is.
Of course, the term 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 Lightning Network depends on economic stimuli.
Finally, as a payment network, the Lightning Network 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.(((range="endofrange", startref="ix_16_security_privacy_ln-asciidoc1")))
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.(((range="endofrange", startref="ix_16_security_privacy_ln-asciidoc1")))
=== Anonymity Set
=== Anonymity Set
((("anonymity set")))((("deanonymization")))((("security and privacy","anonymity set")))What does it mean to deanonymize someone?
((("anonymity set")))((("de-anonymization")))((("security and privacy","anonymity set")))What does it mean to de-anonymize someone?
In simple terms, deanonymization implies linking some action with a person's real-world identity, such as their name or physical address.
In simple terms, de-anonymization 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.
In privacy research, the notion of de-anonymization is more nuanced.
First, we are not necessarily talking about names and addresses.
First, we are not necessarily talking about names and addresses.
Discovering someone's IP address or telephone number may also be considered deanonymization.
Discovering someone's IP address or telephone number may also be considered de-anonymization.
A piece of information that allows linking a user's action to their previous actions is referred to as _identity_.
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 neither fully anonymous nor completely deanonymized.
Second, de-anonymization is not binary; a user is neither fully anonymous nor completely de-anonymized.
Instead, privacy research looks at anonymity compared to the anonymity set.
Instead, privacy research looks at anonymity compared to the anonymity set.
The _anonymity set_ is a central notion in privacy research.
The _anonymity set_ is a central notion in privacy research.
@ -90,22 +90,22 @@ It may not be necessary to shrink the anonymity set to the size of one.
For instance, if the adversary plans a targeted denial-of-service (DoS) attack and can take down 100 servers, the anonymity set of 100 suffices.
For instance, if the adversary plans a targeted denial-of-service (DoS) attack and can take down 100 servers, the anonymity set of 100 suffices.
Second, the adversary can cross-correlate information from different sources.
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.
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.
Finally, especially in cryptographic settings, the attacker always has the "last resort" of a brute-force search.
Cryptographic primitives are designed so that it is practically impossible to guess a secret such as a private key.
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.
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.
In terms of Lightning, de-anonymizing 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.
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.
Ideally, the anonymity set consists of all the users of the network.
This assures that the attacker has no information whatsoever.
This assures that the attacker has no information whatsoever.
However, the real network leaks information that allows an attacker to narrow down the search.
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.
The smaller the anonymity set, the higher the chance of successful de-anonymization.
=== Differences Between the Lightning Network and Bitcoin in Terms of Privacy
=== Differences Between the Lightning Network and Bitcoin in Terms of Privacy
((("security and privacy","differences between Lightning Network and Bitcoin in terms of privacy", id="ix_16_security_privacy_ln-asciidoc2", range="startofrange")))While it's true that transactions on the Bitcoin network do not associate real-world identities with Bitcoin addresses, all transactions are broadcast in cleartext and can be analyzed.
((("security and privacy","differences between Lightning Network and Bitcoin in terms of privacy", id="ix_16_security_privacy_ln-asciidoc2", range="startofrange")))While it's true that transactions on the Bitcoin network do not associate real-world identities with Bitcoin addresses, all transactions are broadcast in cleartext and can be analyzed.
Multiple companies have been established to deanonymize users of Bitcoin and other cryptocurrencies.
Multiple companies have been established to de-anonymize users of Bitcoin and other cryptocurrencies.
At first glance, Lightning provides better privacy than Bitcoin because Lightning payments are not broadcast to the whole network.
At 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.
While this improves the privacy baseline, other properties of the Lightning protocol may make anonymous payments more challenging.
@ -125,7 +125,7 @@ The routing node does not know whether its immediate neighbors in the payment ro
Therefore, the anonymity set of a node in Lightning roughly equals its neighbors (see <<anonymity_set>>).
Therefore, the anonymity set of a node in Lightning roughly equals its neighbors (see <<anonymity_set>>).
[[anonymity_set]]
[[anonymity_set]]
.The anonymity set of Alice and Bob constitutes their neighbors.
.The anonymity set of Alice and Bob constitutes their neighbors
image::images/mtln_1601.png["The anonymity set of Alice and Bob constitutes their neighbors"]
image::images/mtln_1601.png["The anonymity set of Alice and Bob constitutes their neighbors"]
Similar logic applies to payment receivers.
Similar logic applies to payment receivers.
@ -147,7 +147,7 @@ The issues discussed in this part of the chapter summarize research available in
Now let's review some of the attacks on LN privacy that have been described in academic literature.(((range="endofrange", startref="ix_16_security_privacy_ln-asciidoc2")))
Now let's review some of the attacks on LN privacy that have been described in academic literature.(((range="endofrange", startref="ix_16_security_privacy_ln-asciidoc2")))
=== Attacks On Lightning
=== Attacks on Lightning
((("security and privacy","attacks on Lightning", seealso="breaches of privacy", id="ix_16_security_privacy_ln-asciidoc3", range="startofrange")))Recent research describes various ways in which the security and privacy of the Lightning Network may be compromised.
((("security and privacy","attacks on Lightning", seealso="breaches of privacy", id="ix_16_security_privacy_ln-asciidoc3", range="startofrange")))Recent research describes various ways in which the security and privacy of the Lightning Network may be compromised.
@ -185,12 +185,12 @@ However, in June 2020, researchers noted that the single most central node https
These findings emphasize the relevance of the on-path attacker model.
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 might use to infer the sender and the receiver.
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 might use to infer the sender and the receiver.
The on-path adversary can observe the amount of any routed payment as well as time-lock deltas (see <<onion_routing>>).
The on-path adversary can observe the amount of any routed payment as well as timelock deltas (see <<onion_routing>>).
Hence, the adversary can exclude any nodes from the sender's or the receiver's anonymity set with capacities lower than the routed amount.
Hence, the adversary can exclude any nodes from the sender's or the receiver's anonymity set with capacities lower than the routed amount.
Therefore, we observe a trade-off between privacy and payment amounts.
Therefore, we observe a trade-off between privacy and payment amounts.
Typically, the larger the payment amount is, the smaller the anonymity sets are.
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.
We note that this leakage could be minimized with multipart payments or with large capacity payment channels.
Similarly, payment channels with small time-lock deltas could be excluded from a payment path.
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.
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.
This leakage could be evicted by adhering to the so-called shadow routes.
This leakage could be evicted by adhering to the so-called shadow routes.
@ -200,7 +200,7 @@ Before starting the attack, the attacker learns every node's latency characteris
Naturally, this can aid in establishing the adversary's precise position in the payment path.
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.
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.
Finally, it's important to recognize that unknown or unstudied leakages probably exist that could aid deanonymizing attempts. For instance, because different Lightning wallets apply different routing algorithms, even knowing the applied routing algorithm could help exclude certain nodes from being a sender and/or receiver of a payment.(((range="endofrange", startref="ix_16_security_privacy_ln-asciidoc4")))
Finally, it's important to recognize that unknown or unstudied leakages probably exist that could aid de-anonymizing attempts. For instance, because different Lightning wallets apply different routing algorithms, even knowing the applied routing algorithm could help exclude certain nodes from being a sender and/or receiver of a payment.(((range="endofrange", startref="ix_16_security_privacy_ln-asciidoc4")))
==== Revealing Channel Balances (Probing)
==== Revealing Channel Balances (Probing)
@ -218,24 +218,24 @@ Note that 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.
There is no way to tell whether a hash corresponds to a real secret or was generated randomly.
The probing attack proceeds as follows.
The probing attack proceeds as follows.
Say, the attacker Mallory wants to reveal Alice's balance of a public channel between Alice and Bob.
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.
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).
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 and sends 500 thousand satoshis to Bob via Alice using a _random number_ as the payment hash.
Mallory opens a channel with Alice with 1 million satoshis and sends 500,000 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.
Of course, this number does not correspond to any known payment secret.
Therefore, the payment will fail.
Therefore, the payment will fail.
The question is: how exactly will it fail?
The question is: how exactly will it fail?
There are two scenarios.
There are two scenarios.
If Alice has more than 500 thousand satoshis on her side of the channel to Bob, she forwards the payment.
If Alice has more than 500,000 satoshis on her side of the channel to Bob, she forwards the payment.
Bob decrypts the payment onion and realizes that the payment is intended for him.
Bob decrypts the payment onion and realizes that the payment is intended for him.
He looks up his local store of payment secrets and searches for the preimage that corresponds to the payment hash, but does not find one.
He looks up his local store of payment secrets and searches for the preimage 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.
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.
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."
Therefore, Mallory can update her estimation of Alice's balance from "between zero and 1 million" to "between 500,000 and 1 million."
Another scenario happens if Alice's balance is lower than 500 thousand satoshis.
Another scenario happens if Alice's balance is lower than 500,000 satoshis.
In that case, Alice is unable to forward the payment and returns the "insufficient balance" error to Mallory.
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."
Mallory updates her estimation from "between zero and 1 million" to "between zero and 500,000."
Note that in any case, Mallory's estimation becomes twice as precise after just one probing!
Note that in any case, Mallory's estimation becomes twice as precise after just one probing!
She can continue probing, choosing the next probing amount such that it divides the current estimation interval in half.
She can continue probing, choosing the next probing amount such that it divides the current estimation interval in half.
@ -279,12 +279,12 @@ Finally, as multipart payments make the problem of insufficient capacity less se
((("breaches of privacy","denial-of-service attacks", id="ix_16_security_privacy_ln-asciidoc9", range="startofrange")))((("denial-of-service (DoS) attacks", id="ix_16_security_privacy_ln-asciidoc10", range="startofrange")))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 (DoS) attack.
((("breaches of privacy","denial-of-service attacks", id="ix_16_security_privacy_ln-asciidoc9", range="startofrange")))((("denial-of-service (DoS) attacks", id="ix_16_security_privacy_ln-asciidoc10", range="startofrange")))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 (DoS) attack.
Generally, this is achieved by the attacker bombarding a resource with requests, which are indistinguishable from legitimate queries.
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 aggrieve the target.
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 aggrieve the target.
Typical mitigations for DoS attacks require authentication for requests to separate legitimate users from malicious ones. These mitigations incur a trivial cost to regular users but will act as a sufficient deterrent to an attacker launching requests at scale.
Typical mitigations for DoS attacks require authentication for requests to separate legitimate users from malicious ones. These mitigations incur a trivial cost 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 (Reddit group) members at bay, and data services sell API keys to limit the number of queries.
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 (Reddit group) members at bay, and data services sell API keys to limit the number of queries.
===== Dos in bitcoin
===== DoS in bitcoin
((("Bitcoin (system)","DoS attacks")))((("denial-of-service (DoS) attacks","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.
((("Bitcoin (system)","DoS attacks")))((("denial-of-service (DoS) attacks","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.
Any node on the network can consume bandwidth and mempool space by sending a valid transaction.
@ -295,7 +295,7 @@ Many of these transactions were not selected by miners due to their low transact
To address this issue, a minimum transaction relay fee that set a threshold fee that nodes require to propagate transactions was set.
To address this issue, a minimum transaction relay fee that 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.
This measure largely ensured that the transactions that consume network resources will eventually pay their chain fees.
The minimum relay fee is acceptable to regular users but would hurt attackers financially if they tried to spam the network.
The minimum relay fee 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 within high-fee environments, these measures have largely been effective at disincentivizing this type of spam.
While some transactions may not make it into valid blocks within high-fee environments, these measures have largely been effective at deterring this type of spam.
===== DoS in Lightning
===== DoS in Lightning
@ -310,7 +310,7 @@ This is great for legitimate users, who wouldn't like to pay for failed attempts
At the time of writing, a discussion is https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002734.html[ongoing] on the lightning-dev mailing list as to how best address this issue.
At the time of writing, a discussion is https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002734.html[ongoing] on the lightning-dev mailing list as to how best address this issue.
===== Known dos attacks
===== Known DoS attacks
((("denial-of-service (DoS) attacks","known DoS attacks")))There are two known DoS attacks on public LN channels which render a target channel, or a set of target channels, unusable.
((("denial-of-service (DoS) attacks","known DoS attacks")))There are two known DoS attacks on public LN channels which render a target channel, or a set of target channels, unusable.
Both attacks involve routing payments through a public channel, then holding them until their timeout, thus maximizing the attack's duration.
Both attacks involve routing payments through a public channel, then holding them until their timeout, thus maximizing the attack's duration.
@ -332,9 +332,9 @@ While this limit _may_ be increased, transactions are still limited by the block
Rather than locking up slots on the channel commitment, this attack routes large HTLCs through a target channel, consuming all the channel's available bandwidth.
Rather than locking up slots on the channel commitment, this attack routes large HTLCs through a target channel, consuming all the channel's available bandwidth.
This attack's capital commitment is higher than the commitment jamming attack because the attacking node needs more funds to route failed payments through the target.(((range="endofrange", startref="ix_16_security_privacy_ln-asciidoc3")))
This attack's capital commitment is higher than the commitment jamming attack because the attacking node needs more funds to route failed payments through the target.(((range="endofrange", startref="ix_16_security_privacy_ln-asciidoc3")))
=== Cross-Layer Deanonymization
=== Cross-Layer De-Anonymization
((("breaches of privacy","cross-layer deanonymization", id="ix_16_security_privacy_ln-asciidoc11", range="startofrange")))((("cross-layer deanonymization", id="ix_16_security_privacy_ln-asciidoc12", range="startofrange")))((("security and privacy","cross-layer deanonymization", id="ix_16_security_privacy_ln-asciidoc13", range="startofrange")))Computer networks are often layered.
((("breaches of privacy","cross-layer de-anonymization", id="ix_16_security_privacy_ln-asciidoc11", range="startofrange")))((("cross-layer de-anonymization", id="ix_16_security_privacy_ln-asciidoc12", range="startofrange")))((("security and privacy","cross-layer de-anonymization", id="ix_16_security_privacy_ln-asciidoc13", range="startofrange")))Computer networks are often layered.
Layering allows for separation of concerns and makes the whole system manageable.
Layering allows for separation of concerns and makes the whole system manageable.
No one could design a website if it required understanding all the TCP/IP stack up to the physical encoding of bits in an optical cable.
No one could 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.
Every layer is supposed to provide the functionality to the layer above in a clean way.
@ -345,10 +345,10 @@ This is the problem of leaky abstractions.
In the context of Lightning, the LN protocol relies on the Bitcoin protocol and the LN P2P network.
In the context of Lightning, the LN protocol relies on the Bitcoin protocol and the LN P2P network.
Up to this point, we only considered the privacy guarantees offered by the Lightning Network in isolation.
Up to this point, we only considered the privacy guarantees offered by the Lightning Network in isolation.
However, creating and closing payment channels are inherently performed on the Bitcoin blockchain.
However, creating and closing payment channels are inherently performed on the Bitcoin blockchain.
Consequently, for a complete analysis of the LIghtning Network's privacy provisions, one needs to consider every layer of the technological stack users might interact with.
Consequently, for a complete analysis of the Lightning Network'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 off-chain and on-chain data to cluster or link LN nodes to corresponding Bitcoin addresses.
Specifically, a de-anonymizing adversary can and will use off-chain and on-chain data to cluster or link LN nodes to corresponding Bitcoin addresses.
Attackers attempting to deanonymize LN users may have various goals, in a cross-layer context:
Attackers attempting to de-anonymize LN users may have various goals, in a cross-layer context:
* Cluster Bitcoin addresses owned by the same user (Layer 1). We call these Bitcoin entities.
* 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).
* Cluster LN nodes owned by the same user (Layer 2).
@ -360,7 +360,7 @@ The last type of heuristics, cross-layer linking techniques, emphasizes the need
==== On-Chain Bitcoin Entity Clustering
==== On-Chain Bitcoin Entity Clustering
((("Bitcoin entities","entity clustering")))((("cross-layer deanonymization","on-chain Bitcoin entity clustering")))((("on-chain Bitcoin entity clustering")))LN-blockchain interactions are permanently reflected in the Bitcoin entity graph.
((("Bitcoin entities","entity clustering")))((("cross-layer de-anonymization","on-chain Bitcoin entity clustering")))((("on-chain Bitcoin entity clustering")))Lightning Network blockchain interactions are permanently reflected in the Bitcoin entity graph.
Even if a channel is closed, an attacker can observe which address funded the channel and where the coins are spent after closing it.
Even if a channel is closed, an attacker can observe which address funded the channel and where the coins are spent after closing it.
For this analysis, let's consider four separate entities.
For this analysis, let's consider four separate 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_.
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_.
@ -374,7 +374,7 @@ Collector heuristic (settlement):: If a component contains one destination entit
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.
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 out that these heuristics might produce false positives.
It is worthwhile pointing 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.
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.
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).
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.
However, these false positives can effectively be filtered out.
@ -384,7 +384,7 @@ If outputs of funding transactions are not reused for opening other channels, th
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.
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.
However, users tend to use similar aliases for their own different nodes.
However, users tend to use similar aliases for their own different nodes.
For example, _LNBig.com Billing_ is likely owned by the same user as the node with alias _LNBig.com_.
For example, _LNBig.com Billing_ is likely owned by the same user as the node with alias _LNBig.com_.
@ -399,9 +399,9 @@ 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 Lightning Network, 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.
While the public announcement of IP addresses may be unavoidable for those nodes that wish to have incoming channels in the Lightning Network, 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
==== Cross-Layer Linking: Lightning Nodes and Bitcoin Entities
((("Bitcoin entities","cross-layer linking to Lightning nodes")))((("breaches of privacy","cross-layer linking: Lightning nodes and Bitcoin entities")))((("cross-layer deanonymization","cross-layer linking: Lightning nodes and Bitcoin entities")))((("Lightning node operation","cross-layer linking to Bitcoin entities")))Associating LN nodes to Bitcoin entities is a serious breach of privacy that is exacerbated by the fact that most LN nodes publicly expose their IP addresses.
((("Bitcoin entities","cross-layer linking to Lightning nodes")))((("breaches of privacy","cross-layer linking: Lightning nodes and Bitcoin entities")))((("cross-layer de-anonymization","cross-layer linking: Lightning nodes and Bitcoin entities")))((("Lightning node operation","cross-layer linking to Bitcoin entities")))Associating LN nodes to Bitcoin entities is a serious breach of 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.
Typically, an IP address can be considered as a unique identifier of a user.
Two widely observed behavior patterns reveal links between LN nodes and Bitcoin entities.
Two widely observed behavior patterns 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.
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.
Those coins can effectively be linked to a common LN node.
@ -410,7 +410,7 @@ Entity reuse:: Typically, users fund their payment channels from Bitcoin address
These cross-layer linking algorithms could be foiled if users possess multiple unclustered addresses or use multiple wallets to interact with the Lightning Network.
These cross-layer linking algorithms could be foiled if users possess multiple unclustered addresses or use multiple wallets to interact with the Lightning Network.
The possible deanonymization of Bitcoin entities illustrates how important it is to consider the privacy of both layers simultaneously instead of one at a time.(((range="endofrange", startref="ix_16_security_privacy_ln-asciidoc13")))(((range="endofrange", startref="ix_16_security_privacy_ln-asciidoc12")))(((range="endofrange", startref="ix_16_security_privacy_ln-asciidoc11")))
The possible de-anonymization of Bitcoin entities illustrates how important it is to consider the privacy of both layers simultaneously instead of one at a time.(((range="endofrange", startref="ix_16_security_privacy_ln-asciidoc13")))(((range="endofrange", startref="ix_16_security_privacy_ln-asciidoc12")))(((range="endofrange", startref="ix_16_security_privacy_ln-asciidoc11")))
//TODO from author: 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
//TODO from author: 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
@ -463,7 +463,7 @@ On the other hand, the adversary could be more stealthy.
Several topology-based attacks target a single node or a single payment channel.
Several topology-based attacks target a single node or a single payment channel.
For example, an adversary might be interested in exhausting a certain payment channel's capacity on purpose.
For example, an adversary might be interested in exhausting a certain payment channel's capacity on purpose.
More generally, an adversary can deplete all the outgoing capacity of a node to knock it down from the routing market.
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.
This could be easily obtained by routing payments through the victim node with amounts equalling the outgoing capacity of each payment channel.
After completing this so-called node isolation attack, the victim cannot send or route payments anymore unless it receives a payment or rebalances its channels.
After completing 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 Lightning Network.
To conclude, even by design, it is possible to remove edges and nodes from the routable Lightning Network.
@ -499,7 +499,7 @@ Hopefully, multipart payments will help increase the effectiveness of payment ro
For a precise definition of central point dominance, the reader is referred to https://doi.org/10.2307/3033543[Freeman's work].
For a precise definition of central point dominance, the reader is referred to https://doi.org/10.2307/3033543[Freeman's work].
The larger the central point dominance of a network is, the more centralized the network is.
The larger the central point dominance of a network is, the more centralized the network is.
We can observe that the Lightning Network has a greater central point dominance (i.e., it is more centralized) than a random graph (Erdős–Rényi graph) or a scale-free graph (Barabási-Albert graph) of equal size.
We can observe that the Lightning Network has a greater central point dominance (i.e., it is more centralized) than a random graph (Erdős–Rényi graph) or a scale-free graph (Barabási–Albert graph) of equal size.
In general, our understanding of the dynamic nature of the LN channel graph is rather limited.
In general, our understanding of the dynamic nature of the LN channel graph is rather limited.
It is fruitful to analyze how protocol changes like multipart payments can affect the dynamics of the Lightning Network.
It is fruitful to analyze how protocol changes like multipart payments can affect the dynamics of the Lightning Network.
@ -507,14 +507,14 @@ It would be beneficial to explore the temporal nature of the LN graph in more de
=== Economic Incentives and Graph Structure
=== Economic Incentives and Graph Structure
((("Lightning graph","economic incentives and graph structure")))((("security and privacy","economic incentives and graph structure")))The LN graph forms spontaneously and nodes connect to each other based on mutual interest.
((("Lightning graph","economic incentives and graph structure")))((("security and privacy","economic incentives and graph structure")))The LN graph forms spontaneously, and nodes connect to each other based on mutual interest.
As a result, incentives drive graph development.
As a result, incentives drive graph development.
Let's look at some of the relevant incentives:
Let's look at some of the relevant incentives:
* Rational incentives.
* Rational incentives:
- Nodes establish channels to send, receive, and route payments (earn fees).
- 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?
- What makes a channel more likely to be established between two nodes that act rationally?
* Altruistic incentives.
* Altruistic incentives:
- Nodes establish channels "for the good of the network."
- 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).
- 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?
- What role does it play in Lightning?
@ -533,8 +533,8 @@ In the meantime, there are some measures that you can take to guard your node ag
=== Unannounced Channels
=== Unannounced Channels
((("payment channel","unannounced channels")))((("security and privacy","unannounced channels")))((("unannounced channels")))If you intend to use the Lightning Network to send and receive funds between nodes and wallets you control, and have no interest in routing other users' payments, there is little need to announce your channels to the rest of the network.
((("payment channel","unannounced channels")))((("security and privacy","unannounced channels")))((("unannounced channels")))If you intend to use the Lightning Network to send and receive funds between nodes and wallets you control, and have no interest in routing other users' payments, there is little need to announce your channels to the rest of the network.
You could open a channel between, say, your desktop PC running a full node and your mobile phone running a Lightning wallet and simply forgo the channel announcement discussed in <<ch03_How_Lightning_Works>>.
You could open a channel between, say, your desktop PC running a full node and your mobile phone running a Lightning wallet, and simply forgo the channel announcement discussed in <<ch03_How_Lightning_Works>>.
These are sometimes called "private" channels, however it is more correct to refer to them as "unannounced" channels because they are not strictly private.
These are sometimes called "private" channels; however, it is more correct to refer to them as "unannounced" channels because they are not strictly private.
Unannounced channels will not be known to the rest of the network and won't normally be used to route other users' payments.
Unannounced channels will not be known to the rest of the network and won't normally be used to route other users' payments.
They can still be used to route payments if other nodes are made aware of them; for example, an invoice could contain routing hints which suggests a path with an unannounced channel.
They can still be used to route payments if other nodes are made aware of them; for example, an invoice could contain routing hints which suggests a path with an unannounced channel.
@ -559,7 +559,7 @@ Hence, while unannouned channels are not completely private, they do provide som
=== Routing Considerations
=== Routing Considerations
((("denial-of-service (DoS) attacks","protecting against")))((("routing","security/privacy considerations")))((("security and privacy","routing considerations")))As covered in <<denial_of_service>>, nodes that open public channels expose themselves to the risk of a series of attacks on their channels.
((("denial-of-service (DoS) attacks","protecting against")))((("routing","security/privacy considerations")))((("security and privacy","routing considerations")))As covered in <<denial_of_service>>, nodes that open public channels expose themselves to the risk of a series of attacks on their channels.
While mitigations are being developed on the protocol level, there are many steps that a node can take to protect against denial of service attacks on their public channels.
While mitigations are being developed on the protocol level, there are many steps that a node can take to protect against denial of service attacks on their public channels:
Minimum HTLC size:: On channel open, your node can set the minimum HTLC size that it will accept.
Minimum HTLC size:: On channel open, your node can set the minimum HTLC size that it will accept.
Setting a higher value ensures that each of your available channel slots cannot be occupied by a very small payment.
Setting a higher value ensures that each of your available channel slots cannot be occupied by a very small payment.
@ -591,7 +591,7 @@ Our suggestion is not to set an exclusive list of "mega-hubs" from which you wil
Some potential strategies are:
Some potential strategies are:
No risk:: Do not accept any incoming channels.
No risk:: Do not accept any incoming channels.
Low risk:: Accept channels from a known set of nodes that you have previously had successful channels open with
Low risk:: Accept channels from a known set of nodes that you have previously had successful channels open with.
Medium risk:: Only accept channels from nodes that have been present in the graph for a longer period and have some long-lived channels.
Medium risk:: Only accept channels from nodes that have been present in the graph for a longer period and have some long-lived channels.
Higher risk:: Accept any incoming channels, and implement the mitigations described in <<routing_considerations>>.
Higher risk:: Accept any incoming channels, and implement the mitigations described in <<routing_considerations>>.
@ -604,11 +604,11 @@ In this chapter, we used many references from ongoing research on Lightning secu
===== Privacy and probing attacks
===== Privacy and probing attacks
* Jordi Herrera-Joancomartí et al. https://eprint.iacr.org/2019/328["On the Difficulty of Hiding the Balance of Lightning Network Channels"], _Asia CCS '19: Proceedings of the 2019 ACM Asia Conference on Computer and Communications Security_ (July 2019): 602–612.
* Jordi Herrera-Joancomartí et al. https://eprint.iacr.org/2019/328["On the Difficulty of Hiding the Balance of Lightning Network Channels"]. _Asia CCS '19: Proceedings of the 2019 ACM Asia Conference on Computer and Communications Security_ (July 2019): 602–612.
* Utz Nisslmueller et al. "Toward Active and Passive Confidentiality Attacks on Cryptocurrency Off-Chain Networks." arXiv preprint, https://arxiv.org/abs/2003.00003[] (2020).
* Utz Nisslmueller et al. "Toward Active and Passive Confidentiality Attacks on Cryptocurrency Off-Chain Networks." arXiv preprint, https://arxiv.org/abs/2003.00003[] (2020).
* Sergei Tikhomirov et al. "Probing Channel Balances in the Lightning Network." arXiv preprint, https://arxiv.org/abs/2004.00333[] (2020).
* Sergei Tikhomirov et al. "Probing Channel Balances in the Lightning Network." arXiv preprint, https://arxiv.org/abs/2004.00333[] (2020).
* George Kappos et al. "An Empirical Analysis of Privacy in the Lightning Network." arXiv preprint, https://arxiv.org/abs/2003.12470[] (2021).
* George Kappos et al. "An Empirical Analysis of Privacy in the Lightning Network." arXiv preprint, https://arxiv.org/abs/2003.12470[] (2021).
* https://github.com/LN-Zap/zap-desktop/blob/v0.7.2-beta/services/grpc/router.methods.js[Zap source code with the probing function]
* https://github.com/LN-Zap/zap-desktop/blob/v0.7.2-beta/services/grpc/router.methods.js[Zap source code with the probing function].
kristen@oreilly.com
3 years ago