LockDown: Balance Availability Attack Against Lightning Network Channels

Abstract

The Lightning Network (LN) is a payment network running as a second layer on top of Bitcoin and other Blockchains. This paper presents the possibility of performing a balance lockdown in the LN due to misbehaving nodes associated to a given channel. We formalize and introduce a practical attack, minimizing the economic cost of the attack. We present results that validate our claims, and provide experimental results and potential countermeasures to handle the problem.

A Simnet Network

To perform our experiments, we create a Lightning simnet network with eleven nodes, $M,A,B_1, \cdots , B_9$. Node M will be the adversary and A the victim. Nodes $B_1, \cdots , B_9$ will represent victim’s neighbors. To test all implementations in our simnet, we run different implementations for different nodes. More precisely, the following configuration has been taken. Nodes $M, A, B_1,B_2,B_3$ run the LND implementation with version 0.5.2-99-beta, nodes $B_4, B_5, B_6$ the c-lightning with version v0.7.0 and nodes $B_7, B_8, B_9$ run eclair with version version=0.2-SNAPSHOT. Over this configuration, we have created 10 payment channels, as shown in Fig. 4(a).

With this settlement, M performs a payment to himself, following the route $M \rightarrow A \rightarrow B_1 \rightarrow A \rightarrow B_2 \rightarrow A \rightarrow B_3 \rightarrow A \rightarrow B_4 \rightarrow A \rightarrow B_5 \rightarrow A \rightarrow B_6 \rightarrow A \rightarrow B_7 \rightarrow A \rightarrow B_7 \rightarrow A \rightarrow B_9 \rightarrow A \rightarrow M$.

The correct execution of such experiment proves that the payment has been processed by all nodes and that routes can effectively contain loops. Notice that the loops tested in this experiment are the shortest possible which validates the shorter loop case of our attack (see Sect. 3). Notice that the implementation selected for each node ensures that such behavior is equivalent in all implementations.

Figure 4(b) shows a new scenario where we have added a payment channel between nodes $B_6$ and $B_9$. With this scenario, M performs a payment to himself, following the route $M-A-B_6-B_9-A-B_6-B_9-A-M$.

Again, the test shows that the payment is correctly processed by all nodes and it proves that all implementations can also accept the longer loop case, since we have chosen A, $B_6$ and $B_9$ all with different implementations.

Fig. 4.

Simnet scenarios

Once we have ensured that routes with cycles are possible to execute in any implementation, we would like to study how to maximize $\varDelta _{p}$, the time that a payee can lock a payment p. Such value can be estimated using information of the nodes that are included in a route. More precisely, values $\delta$ and $T_{max}$ of each node and the node position in the route determines the maximum time a payment can be blocked.

In our scenario, the adversary controls both the first and the last node of the route. We first describe how, as a first node, the adversary can determine the maximum $\varDelta _{p}$ for a particular route. Then, we will detail how the adversary, as the last node of the route, may block the payment during $\varDelta _{p}$ and how, after that time, he can cancel the payment without paying any fee to the routing nodes and, furthermore, leaving all the channels in the same setting than the initial phase of the attack being able to reexecute the attack without any cost.

As pointed out in Sect. 2, the parameters that determine the actions of each node of the route are $T_{max}$ and $\delta$. The first one, $T_{max}$, is the maximum amount that a node allows an outgoing payment in a channel to be locked. And the second one indicates the difference, in blocks, that each hop in the route requires. Such parameters are different for every lightning implementation as Table 4 shows. When a node receives a payment, he sets an expiration time¹¹, $\theta$, for the payment, and subtracts his $\delta$. In case that the resulting value is lower than his $T_{max}$, then he will keep forward the payment, in other case, the node will refuse the payment, the route will be discarded and the payer will need to find another route. Then, the best strategy for an adversary to maximize $\varDelta _{p}$ is to simulate the route assuming that each node, instead of discarding the payment, will set the new $\theta$ as his $T_{max}$. For instance, suppose the following route $M-B_i-B_j-B_k-M$ and assume that $B_i$ is a lnd implementation, $B_j$ is an eclair implementation and $B_k$ is a c-lightning implementation. Assuming the default values of Table 4, the simulation performed by M will start with $\theta = \infty$. When processing the first hop, $B_i$ has a lnd implementation which means $T_{max}=5000$ and $\delta =144$ so for that hop, we can compute $\theta = 5000 - 144 =4856$. In the next hop, $B_j$ runs an eclair implementation, hence $T_{max}=1008$ and $\delta =144$. In that case, since the received $\theta = 4856$ is greater than 1008 we will set $\theta = 1008 - 144= 864$. Then $B_k$ runs a c-lightning with $T_{max}=2016$ and $\delta =14$ and the received $\theta = 864$ is lower than 2016, we can calculate $\theta =864 - 14 = 850$. Since this is the last hop, $\theta =850$ is the time during which the channel can be blocked. With this procedure, M can compute the optimal $\theta$ value that he will include in the first hop to maximize $\varDelta _{p}$. In that case $\theta =850 + 14 + 144 + 144 = 1152$ will provide a maximum $\varDelta _p$, in that case 850

Table 4. Default parameters for different implementations.