Introduction: Ayelet Mizrah and Aviv Zohar, professors of Hebrew University, jointly published the paper " Congestion Attacks in Payment Channel Networks. " This paper discusses a basic loophole in the payment channel network when building multi-hop payments with trust. This article proposes two attack methods: the first is to lock as many high-fluidity channels as possible for a long time, and the second is to try to isolate a single node from the network and evaluate the lightning network's ability to withstand these attacks. By examining the three main implementations of Lightning Network for setting network properties and different parameters, this article proves that recent changes to Lightning Network's default parameters will make attacks more prone. The results show that by using less than 0.5 bitcoins, the liquidity of most Lightning Networks can be locked, which may damage the Lightning Network.
Author: Ayelet Mizrah and Hebrew University professor Aviv Zohar
- Innisfil becomes the first city in North America to accept bitcoin municipal taxation
- Free and easy week review 丨 AI algorithm cross-border participation in Bitcoin mining? Ethereum successfully completes Istanbul upgrade
- As the price of the currency rises, the lemon essence is ready to move?
- Featured on Twitter | Controversy: BCH receives 12.5% miner tax to fund development, and V is opposed to calling this a mandatory soft fork
- Wikipedia Lightning Network Entry Critical? Bitcoin was deleted 9 years ago
- Babbitt column | Payment or stored value? BTC's future value path
In a new paper , we discussed a basic loophole in the process of building trustless multi-hop payments in a payment channel network. We propose two attack methods: the first is to lock as many high-fluidity channels as possible for a long time, and the second is to isolate the hubs from the rest of the network. In this article, we describe these assessments of Lightning Network attacks. We will examine the three main implementations of the Lightning Network for setting the properties of the network and different parameters, and show how recent changes to the default parameters agreed by the Lightning developers make the attack easier to implement. Our results show that by using less than 0.5 bitcoins to lock most of the Lightning Network's liquidity, this can disrupt the Lightning Network.
The payment channel network is a second-tier off-chain solution to the blockchain scalability problem. The Lightning Network, which is a Layer 2 network of Bitcoin, currently has more than 11,000 nodes and 35,000 channels, with a total capacity of approximately 880 BTC (about $ 9,000,000).
The basic concept of the attack we explored can be traced back to the corresponding content in the Lightning-dev list in August 2015, and a git issue in BOLT mentioned in May 2017. The consequences of such an attack have never been fully evaluated, but its cost is very low: an attacker can lock most of the network's channels indefinitely with less than 0.5 Bitcoin.
In order to paralyze the channel, the attacker uses a set of paths to the source and target to open the channel and requests many small payments through the path, thereby depleting the number of HTLCs that are opened at the same time. Have different limits). The attacker is both the source and the destination of the payment, and may severely delay the final execution time (up to a few days) of the payment. The attacker can then re-run the attack again and lock the same path for an additional period of time.
The attacker created two long-distance routes to paralyze the channel
We studied the main implementation of the Lightning Protocol. This is the default value they use for related parameters (most nodes do use these default values-see details in this article). Today, most nodes on the network are actually LND nodes (about 90%).
The following figure illustrates how to perform a single payment along a path (the attacker repeats multiple times on each path until no more HTLC is available):
Route establishment and HTLC elimination process
We evaluated the consequences of running this operation on a large scale across the Lightning Network.
Attack the entire network:
When using a greedy algorithm to choose a route and paralyze as much liquidity as possible, we get the following results. The figure below shows a portion of the total capacity currently locked by the Lightning Network we managed to paralyze (3 consecutive days at a time).
Networks can be locked down very effectively during different time periods:
The total cost of the attack is low. Cost consists of two main factors: the cost of opening a channel (non-refundable) and the cost of providing a liquid channel (this money is still in the hands of the attacker).
Our results show that an attacker can use less than 0.25 BTC to disable 650 BTC liquidity in the Lightning Network for 3 days.
To extend the connection time of a single node to the network, the attacker will connect to the victim node and disable its adjacent channels. To this end, it sends multiple payment requests back and forth through the victim's channel (this is surprisingly allowed in Lightning Network implementations).
Here are some important nodes, the cost of attacking them is:
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 the Lightning Network.
If you want to attack smaller nodes, the cost is usually proportional to their level (but not exactly the same):
We noticed that the vulnerability is relatively difficult to fix because it involves three basic attributes of the off-chain payment network:
1. Payment is performed in a trustless manner, using conditional payment contracts (in the form of transactions with HTLC), which are exchanged between the parties and are only sent to the block if a dispute occurs chain. The size of these contracts grows as more conditional payments are pending, so the total number of pending payments is limited by the size of transactions that can be placed on the blockchain.
2. Long expiration time. In order to allow a node to recover its funds when a malicious partner closes a channel that is part of a pending payment, the HTLC expiration time has been set to allow the node sufficient time to appeal such a shutdown. In Bitcoin's Lightning Network, due to the low expressiveness of its scripting language, the expiration time of HTLC will accumulate over the entire length of the path until it reaches 2016 blocks-usually two weeks.
3. Privacy of payment. The payment channel network uses onion routing, which does not allow intermediate nodes on the path to identify the source and location of the payment, allowing attackers to take action without penalty.
In fact, the latest changes to the defaults actually made our attack easier to implement: LND changed its cltv_expiry_delta default from 144 blocks to 40 blocks (March 12, 2019), which allows Link more nodes in the path without reaching the locktime_max limit. In addition, Lightning developers agreed at the 2018 Adelaide conference to set a maximum lock time for 2016 (max_cltv) to set the BOLT 1.1 specification. This is an increase from previous values used in some implementations. Again, this allows longer routing and longer expiration delays, which makes attacks more disruptive and easier to perform.
Force fast HTLC parsing. Although the expiration time of HTLC can keep nodes secure and provide enough time to post transactions to the network, we recommend adding another timeout mechanism. Specifically, if the HTLC secret does not propagate fast enough from an adjacent node, the channel to that node should be closed. This mechanism is a way to disconnect abnormally acting peers from the network to prevent them from repeating multiple attacks for free.
Reduce route length. We recommend reducing the maximum allowed route length (currently 20 hops). The network graph is highly connected, and the number of hops should still be sufficient: the path between nodes in the network is less than 3 hops on average, and the network diameter is about 6.
Setting the maximum number of concurrent payments based on trust level and circular avoidance are two other methods that can slightly mitigate attacks.
To ensure network security, further work must be done. Since the attack relies on basic mechanisms in the payment channel, more consideration is needed.
For more information, see the full text .