By Ayelet Mizrahi and Aviv Zohar

In a new paper (video link) we discuss a fundamental vulnerability that arises in payment channel networks as part of the construction of trustless multi-hop payments. We present three modes of attack: the first aims to lock as many high liquidity channels as possible for an extended period, the second disconnects as many pairs of nodes as it can, and the third 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 spending less than half a bitcoin.

Payment channel networks are a second layer off-chain solution to the scalability problems of blockchains. As of October 2020, Bitcoin’s Lightning Network has more than 14k nodes and 37k channels and a total capacity of around 1100 BTC (~11,700,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 low: spending less than half a bitcoin, the attacker can indefinitely lock up most of the network’s channels.

The Attack:

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.

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 (~91%).

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):

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 830 BTC of liquidity in the Lightning Network for 3 days spending less than 0.25 BTC. The attacker needs to hold an additional amount locked in its channels - this amount is not spent, and will return to the attacker once it completes the attack.

We show how the attack affects connectivity between nodes in the network. We explored several algorithms to select the attacked routes and present them in the following graph:

Attacking Hubs:

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 a significant share of the network’s capacity in multiple channels.

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.

Mitigation techniques

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.

For more see the full paper, published in ‘Financial Cryptography and Data Security 2021’.

Video versions of the paper are available on our YouTube channel.