In a new paper we discuss a fundamental vulnerability that arises in payment channel networks as part of the construction of trustless multi-hop payments. We present two modes of attack: the first aims to lock as many high liquidity channels as possible for an extended period, and the second isolates hubs from the rest of the network. In this post, we present the evaluation of these attacks over the Lightning Network. We will examine the network’s properties and different parameters set by the three main implementations of the Lightning Network and show how recent changes in default parameters agreed upon by Lightning Devs made the attack easier to carry out. Our results show that it is possible to disrupt the Lightning Network by locking most of its liquidity using less than half a bitcoin.
Payment channel networks are a second layer off-chain solution to the scalability problems of blockchains. Bitcoin’s Lightning Network currently has more than 11k nodes and 35k channels and a total capacity of around 880 BTC (~9,000,000 USD).
The basic idea of the attack we explore was mentioned back in August 2015 in a correspondence in the Lightning-dev list and in May 2017 as a git issue in the BOLT. No full evaluation of the consequences of this attack was ever given and its costs turn out to be extremely low: with less than half a bitcoin, the attacker can indefinitely lock up most of the network’s channels.
In order to paralyze channels, the attacker opens channels with the source and target of a route, and requests many small payments through this path, exhausting the number of simultaneously open HTLCs (each of the main implementations of Lightning limits the number of concurrent HTLCs differently). The attacker is both the source and destination of this payment and can severely delay the final execution of the payment (up to several days). The attacker can then re-run the attack once again and lock the same path for an additional period of time.
An attacker creates two long routes to paralyze
We studied the main implementations of the Lightning protocol. Here are the default values they use for relevant parameters (most nodes do use these defaults — see details in the paper). Most nodes on the network nowadays are actually LND nodes (~90%).
The diagram below illustrates how a single payment is executed along a path (the attacker repeats this many times on each path until no more HTLCs are available):
The process of route establishment and the elimination of HTLCs
We evaluate the consequence of running this massively on the entire Lightning Network.
Attacking the Entire Network:
When using a greedy algorithm in order to pick routes and paralyze as much liquidity as possible we get the following results. The graph below shows what fraction of the total capacity currently locked in Lightning we manage to paralyze (for 3 days at a time).
It is possible to lock the network quite effectively for different periods of time:
The total cost of the attack is low. The costs are made up of two main factors: the cost of opening channels (non-refundable) and the cost of provisioning channels with liquidity (this money remains in the hands of the attacker).
Our results show that the attacker can paralyze 650 BTC of liquidity in the Lightning Network for 3 days using less than 0.25 BTC.
In order to disconnect a single node from the network for an extended period of time, the adversary connects to the victim node and paralyzes its adjacent channels. To do so, it makes multiple payment requests over a path going back and forth through the victim’s channels (this is surprisingly allowed in Lightning implementations).
Here are some prominent nodes, and how much it would cost to attack them:
The last entry in the table relates to an isolation attack on all 25 nodes belonging to LNBIG, which hold 47.3% of all liquidity in Lightning.
If you want to attack smaller nodes, the cost is usually proportional to their degree (but not exactly):
We note that the vulnerability is relatively hard to fix since it arises from three fundamental properties of off-chain payment networks:
1. Payments are executed in a trustless manner, using conditional payment contracts (in the form of transactions with HTLCs) that are exchanged between parties and are only sent to the blockchain if disputes arise. These contracts grow in size as more conditional payments are pending, and so the total number of pending payments is limited by transaction sizes that can be placed on the blockchain.
2. Expiration times are long. To allow nodes to recover their funds if a malicious partner closes a channel that is part of a pending payment, HTLC expiration times have been set to allow nodes sufficient time to appeal such closures. In Bitcoin’s Lightning Network, due to lower expressiveness of its scripting language, HTLC expiration times accumulate over the length of the path, reaching up to 2016 blocks — which typically take the Bitcoin network two weeks to produce.
3. The privacy of payments. Payment Channel Networks utilize onion routing that does not allow intermediate nodes on the path to recognize where payments originate and where they are going, allowing the attacker to act with impunity.
Recent changes to the defaults have in fact made our attack easier to carry out: LND changed their cltv_expiry_delta default from 144 to 40 blocks (on 12 Mar 2019) which allows chaining more nodes in each path without reaching the locktime_max limit. Additionally, a max locktime of 2016 (max_cltv) was agreed upon by Lightning developers in the 2018 Adelaide meeting to set the BOLT 1.1 specs. This is an increase of previous values used in some implementations. Again, this allows for longer routes and longer expiration delays that make the attack more damaging and easier to carry out.
Enforcing fast HTLC resolution. While HTLC expiration times allow nodes to remain secure and provide sufficient time to publish transactions to the network, we propose the addition of another time-out mechanism. Specifically, if HTLC secrets are not propagated fast enough from one’s neighbor the channel with this neighbor should be closed. This mechanism is a way to disconnect misbehaving peers from the network in order to prevent them from repeating the attack many times at no cost.
Reducing route length. We suggest lowering the maximum allowed route length (currently 20 hops). The network graph is highly connected, and a smaller number of hops should still suffice: paths between nodes in the network have an average of less than 3 hops and that the network diameter is ~6.
Setting the number of max concurrent payments based on trust level and Loop Avoidance are two more ways to slightly mitigate the attack.
Further work must be conducted in order to secure the network. Since the attack relies on fundamental mechanisms in payment channels, more consideration is warranted.
“You are living in an echo chamber my friend! You know not everyone thinks like you do, right?” The term “echo chamber” has recently become part of our daily lexicon, although the concept has existed for close to 20 years, with the publication of Cass Sunstein’s Republic.com 2.0, followed by #Republic, keeping up with internet trends of course. The echo chamber generally refers to a network that can be characterized as highly insular and one-sided; a place in which confirmation bias, polarization, and opinion extremism find fertile ground. To some degree or another we are all living in echo chambers, at least with regards to some topic or issue that is important to us – perhaps a sports team, a political issue, or a religious belief.
Some have suggested that a network can be characterized as an echo chamber when the information spread within it on a given topic is 95% one-sided. However, there is certainly nothing wrong with a network where 95% of the information agrees that the world is indeed round, or that poverty is bad. Beyond this, given the masses of content, and the subjectivity of assessing the bias of each piece of content and each post, how would such analysis ever be possible? Rather, the network structure characteristics, such as density, insularity/inwardness, centrality, and reciprocity, which are common metrics used by social network analysts, provide the most assessable and theoretically-based proxies by which to measure the echo chamber.
While the echo chamber generally refers to any type of social network, it is more commonly used to refer to online networks. Indeed, the echo chamber effect is stronger online than it is offline. To explain why this may be the case, we need only to turn to Eli Pariser’s now famous “Filter Bubble” hypothesis. According to Pariser, the personalization algorithms that control our online lives, dictate what information we will and will not see, including recommendations for content, purchases, and friends, act as an environmental factor, shaping and determining network structures. While there has been a tendency to use the filter bubble and echo chamber interchangeably, this is clearly incorrect. The echo chamber is a type of network, while the filter bubble is a process which impacts it.
In a recent study we randomly allocated new Twitter users to a treatment of “filter bubble suppression,” whereby users used new email addresses, declined all automated recommendations, and disabled personalization algorithms. After three months of using Twitter, participants from both the treatment and control groups completed a survey that assessed their justification and support for terrorism. The study found a significant interaction effect between the treatment and network inwardness – the primary proxy for the echo chamber – as well as network density, whereby being in the treatment group and having a more outwardly-focused network decreased the odds of justifying terrorism.
Criminologists have long regarded the role of individuals within networks as the source from which deviant beliefs and attitudes are learned. However, one small group of researchers has long suggested that network structure characteristics may be more important determinants of deviant beliefs and attitudes than the identity of the network members themselves. The findings of the Twitter experiment may serve to support this theoretical perspective and suggest that while echo chambers can be incubators of radicalization, it is also possible to burst their bubble.