by Anantha Divakaruni∗ Peter Zimmerman†
Abstract
The Lightning Network (LN) is a means of netting Bitcoin payments outside the blockchain. We find a significant association between LN adoption and reduced blockchain congestion, suggesting that the LN has helped improve the efficiency of Bitcoin as a means of payment. This improvement cannot be explained by other factors, such as changes in demand or the adoption of SegWit. We find mixed evidence on whether increased centralization in the Lightning Network has improved its efficiency. Our findings have implications for the future of cryptocurrencies as a means of payment and their environmental footprint.
1 Introduction
Bitcoin was originally designed to serve as a “peer-to-peer electronic cash system” — that is, a reliable means of payment outside the control of centralized monetary authorities (Nakamoto (2008)). Since its introduction in 2009, Bitcoin has grown immensely in value, but still sees relatively little use as a means of payment (Bolt and van Oordt (2020)). One important reason is that Bitcoin’s blockchain technology imposes capacity constraints on processing transactions. These constraints allow Bitcoin to handle, on average, merely seven transactions per second, which compares unfavorably with centralized payment systems such as Visa or Mastercard.1 When transaction demand is high, the processing limits mean that Bitcoin transactions can take a long time to settle. In recent years, many solutions have been proposed to resolve this so-called scalability problem, to help Bitcoin achieve its potential as a large-scale payments system. One such solution is the Lightning Network (LN), which allows Bitcoin users to make payments outside the blockchain. Rather than inscribe every individual payment onto the blockchain, two individuals can open an LN channel and make bilateral payments. Once they have completed their payments, they can close the channel and settle the net amount. In principle, doing this requires only two transactions on the blockchain — one to open the channel, and another to close it — regardless of the amount settled or the number of underlying payments. In this way, adoption of the LN can reduce demand for blockchain space and ease congestion. We find that adoption of the Lightning Network has led to a reduction in Bitcoin blockchain congestion and lower mining fees. The results are significant, both statistically and economically, and cannot be explained by changes in demand for blockchain space, nor by other technological developments. We find limited evidence that greater centralization of the network is associated with lower fees. Our results suggest that the Lightning Network can help Bitcoin achieve greater scalability, allowing it to operate better as a payments system. According to our results, if the LN had existed in 2017, congestion could have been 93 percent lower. Our analysis covers the period January 1, 2017, to September 5, 2019. Data limitations prevent us from extending our data set. The Lightning Network continues to grow, doubling in size over 2021.2 There has been institutional adoption, too. For example, Twitter allows tipping using the LN, among other payment methods.3 El Salvador enables Bitcoin payments among its citizens using the Chivo Wallet, which features LN functionality (Alvarez, Argente, and Patten (2022)). And several cryptocurrency exchanges have introduced support for the LN.4 But recent episodes of high congestion, especially in early 2021, suggest that the LN is not a panacea. The development of the Lightning Network may have consequences for welfare. First, as Bitcoin becomes a more efficient payments system, users are better off. Their transactions settle more quickly and more cheaply (Zimmerman (2020)). Second, since fewer transactions need to be recorded on the blockchain, less memory and energy are needed to run a Bitcoin node. This saving lowers the cost of maintaining the blockchain, allowing more nodes to participate and making the system more secure against a double-spending attack (Budish (2018)). Third, by reducing fees, the LN reduces the incentive for Bitcoin miners to use large amounts of computing power, meaning less energy use and positive consequences for the environment.5 Fourth, less blockchain congestion may mean lower barriers to arbitrage across cryptocurrency exchanges, thereby improving market liquidity (see Hautsch, Scheuch, and Voigt (2018)). While this paper focuses on Bitcoin, the same technology can allow other cryptocurrencies to be widely used, secure, and decentralized. For example, the Raiden Network is a similar netting solution for Ethereum. Other solutions to the scalability problem have been proposed, including sharding, and batching at exchange level.6 If the scalability problem can be successfully addressed, it may be possible for a currency based on a permissionless blockchain to obtain wide acceptance. The rest of the paper is organized as follows. Section 2 briefly describes the Lightning Network and outlines findings from the existing literature. Section 3 describes our data, and Section 4 our results. Section 5 concludes
2 The Lightning Network
The Lightning Network was first introduced by Poon and Dryja (2016), and began to attract widespread usage in January 2018. The LN is a secondary transaction layer that operates outside the blockchain. Two users open an LN channel by contributing Bitcoin to a smart contract. They can then transfer these coins between them without creating traffic on the blockchain (Auer (2019)). Once the channel is closed, only the net amount needs to be settled on-chain as a single payment. This netting reduces the required number of on-chain transactions to just two: one to introduce the smart contract that opens an LN channel, and a second to close it. In this way, the system can handle a much larger number of payments. Arcane Research (2022) provides an up-to-date description of the Lightning Network. In payments system terms, the Lightning Network can be thought of as a net settlement system appended to Bitcoin’s gross settlement system (Kahn, McAndrews, and Roberds (2003)). This economizes on liquidity, but introduces counterparty credit risk. The LN introduces various safeguards to minimize the risk of counterparty default. In particular, if one party tries to close the channel without the approval of the other, she may forfeit her claim on any Bitcoin that are locked in. The Lightning Network protocol itself relies on Segregated Witness (SegWit), which is a change to the Bitcoin transaction format activated on August 23, 2017. SegWit improves the efficiency of blockchain storage, so that a single Bitcoin block can potentially store up to four times as many transactions as before. Brown, Chiu, and Koeppl (2021) show that the introduction of SegWit has reduced Bitcoin mining fees. Only a couple of papers in the economics and finance literature focus on the Lightning Network. Guasoni, Huberman, and Shikhelman (2021) build a strategic model in which Bitcoin users choose whether to open LN channels, and examine the characteristics of the network that emerges. Bertucci (2020) studies a strategic model of network formation and shows that competition between nodes prevents the network from becoming highly centralized. More broadly, our paper relates to a literature examining the fee-based market for blockchain space; see, for example, Easley, O’Hara, and Basu (2019), Hautsch, Scheuch, and Voigt (2018), Huberman, Leshno, and Moallemi (2021), Lehar and Parlour (2020), Makarov and Schoar (2020), and Zimmerman (2020). In the computer science literature, papers have focused on the financial viability of the LN (e.g., B´eres, Seres, and Bencz´ur (2019) and Brˆanzei, Segal-Halevi, and Zohar (2017)); its network structure (e.g., Lin et al. (2020) and Martinazzi and Flori (2020)); and its ability to guarantee security and privacy (e.g., Harris and Zohar (2020), Kappos et al. (2021), and P´erez-Sol`a et al. (2020))
3 Data
We aim to test whether adoption of the Lightning Network is associated with reduced congestion on the Bitcoin blockchain. We construct measures of congestion using data on the Bitcoin mempool; that is, the set of payments waiting to be added to the blockchain. Our data come from Jochen Hoenicke.7 We collect data on: (i) the number of pending transactions (mempool txn count); (ii) the fees attached to pending transactions (mempool txn fees); and (iii) the proportion of transactions with fees under 10 satoshis per virtual byte (low fee txns).8 Data on the Lightning Network come from the website hashXP.9 This repository contains detailed historical information on all public Lightning nodes (both active and inactive), channels between these nodes (both open and closed), and channel capacity (in bitcoin and USD). In addition, hashXP provides complete details of Bitcoin transactions executed in order to open and close LN channels.10 The shape of the Lightning Network may affect its efficiency. For example, if Lightning channels tend to be intermediated via a few central nodes, then collateral (i.e., the Bitcoin that users have locked into the LN) can be used more efficiently. In other words, when the network is more
centralized, each channel, and each Bitcoin locked into the protocol, is likely to support a higher volume of payments (see Martinazzi and Flori (2020)). To account for this effect, we include the LN clustering coefficient as an independent variable. This network statistic is defined by Watts and Strogatz (1998) as the average probability that two neighbors of any given node are themselves connected. When the network is more centralized, the clustering coefficient is lower. Thus, we predict that when the clustering coefficient is high, mempool congestion is worse. As Figure 1 shows, the network has tended to become more clustered — and thus less centralized — as it develops, though the last few months of the sample period show a trend toward greater centralization. Figure 1: Mean clustering coefficient among Lightning Network nodes. Source: hashXP. We introduce proxies for Bitcoin demand over this period. Higher demand for transactions on the Bitcoin blockchain can increase congestion for reasons unrelated to LN adoption, so we need to take it into account. While demand cannot be observed directly, Liu and Tsyvinski (2020) suggest that it is positively related to historical price changes; in other words, there is a momentum factor. Motivated by this observation, we introduce 1-day price change as the log-lagged change in the Bitcoin price at midnight UTC (Coordinated Universal Time) each day. We also use price volatility as a proxy for speculative demand for Bitcoin. We define 30-day volatility as the rolling standard deviation of Bitcoin returns from each of the past 30 trading days. These two measures are computed using price data from Coin Metrics (https://coinmetrics.io/). We also include a measure for the supply of blockchain space. Unlike demand, supply is directly observable ex post, since we can see how many blocks were created each day. We proxy supply by dividing miners’ total hash rate divided by average mining difficulty, using Coin Metrics data. We call this measure mining intensity. While the Bitcoin protocol aims for a long-run mean of one block every 10 minutes, the realized rate of block creation can vary due to chance, or due to changes in miners’ hash rate since the previous difficulty adjustment (Nakamoto (2008)). In addition, since SegWit adoption may affect mempool congestion, we control for it in our regressions. We obtain data from Bitcoin Visuals on the estimated proportion of Bitcoin transactions that use SegWit (https://bitcoinvisuals.com/chain-tx-block). A description of each variable can be found in the Appendix. Our sample period contains daily data from January 1, 2017, to September 5, 2019, so it includes a period of about a year before the LN was widely adopted. We cannot extend our data set any later because, beyond these dates, hashXP was no longer actively monitoring the Lightning Network and providing accurate data. As a result, we are unable to study any more recent developments in the LN. Hoenicke’s mempool data set is missing six days: Feb 1, 2017; Apr 17–19, 2017; Jun 1, 2019; and Jun 26, 2019. We drop these days from our data set. We use first-differenced data (see later in this section), so we also drop the following days (i.e., Feb 2, 2017; Apr 20, 2017; Jun 2, 2019; Jun 27, 2019). As a result, we have a total of 968 daily observations of the dependent variables. In addition, the Coin Metrics data on prices are missing one day (Jan 1, 2019). Table 1 shows summary statistics for our data. Many of the variables are highly volatile with substantive right-skew. Because of this skewness, we use the logarithms of mempool txn count, mempool txn fees, LN channels, and LN capacity in our regressions. Figure 2a plots the number of transactions waiting to be confirmed in Bitcoin’s mempool (denoting congestion) over our sample period, along with active LN channels over time and the percentage of transactions that use SegWit. Congestion in Bitcoin has fallen markedly since early 2018, coinciding with the introduction and rapid adoption of the LN. Congestion has remained relatively low since
Table 1: Summary statistics. count mean std dev min median max Mempool txn count 968 23,042 40,619 92 5,731 252,750 Mempool txn fees (USD) 968 106,180 440,206 39 3,008 4,750,619 Low fee txns (%) 968 53.45 28.30 0 52.04 95.99 Lightning Network channels 968 12,671 15,374 0 7,575 44,087 Lightning Network capacity (USD) 968 2,766,535 4,080,066 0 205,388 11,794,337 Lightning Network mean clustering 968 0.06 0.07 0 0.06 0.19 SegWit txns (%) 968 20.72 15.48 0 27.61 46.80 30-day volatility 968 4.16 1.54 1.10 4.03 8.07 1-day price change 967 0.00 0.04 -0.21 0.00 0.23 Mining intensity 968 7.49 0.82 3.98 7.51 9.79 Notes: Daily data from January 1, 2017, to September 5, 2019. See the Appendix for variable definitions and data sources. then, although it picked up slightly in mid-2019.11 Figure 2b plots similar measures weighted by monetary value: we measure congestion using mempool fees, LN adoption using the USD value of locked Bitcoin, and SegWit usage by the monetary value of transactions. Total fees attached to payments waiting in the mempool have fallen since 2017, suggesting either lower demand or greater supply of settlement capacity. Over this period, the total value of Bitcoin used to collateralize LN channels has risen. Figure 3 shows that the distribution of fees has changed over our sample period. Generally, fees have fallen in nominal bitcoin terms. The proportion of transactions with fees below 10 satoshis per virtual byte rose from 32.6 percent on January 1, 2018, to 74.2 percent on September 5, 2019.12 We are interested in whether LN adoption is associated with lower mempool congestion. We test for relationships using autoregressive integrated moving average (ARIMA) specifications, which
Notes: Daily data from January 1, 2017, to September 5, 2019. The chart plots fees in satoshis per virtual byte. There are 100 million satoshis to a bitcoin. Source: Jochen Hoenicke. where c is a constant term, y d is the variable of interest expressed after taking d differences, Xd t is a vector of the d-differenced independent variables, and εt is a residual term. The parameter p is the number of lags of the variable of interest, d is the number of differences taken, and q is the length of the moving average window of historical residual terms. For each specification, we estimate the parameters (p, d, q) using the Hyndman-Khandakar algorithm (Hyndman and Khandakar (2008)). The time variable t is daily. We employ robust standard errors, since we cannot be sure of homoskedasticity. Figures 2a and 2b suggest that the data are non-stationary. We take first-differences of all our variables. Augmented Dickey-Fuller (ADF) and Kwiatkowski–Phillips–Schmidt–Shin (KPSS) tests confirm that these first-differenced variables are stationary (i.e., d = 1).
4 Results
We run three sets of regressions. First, we test the effect of LN adoption on mempool count, using the number of LN channels. We run four versions of this model. Model (1) contains no controls; model (2) includes the demand and supply controls; model (3) includes the proportion of transactions that use SegWit; and model (4) has all the controls. Table 2 reports the results. In each of the four specifications, an increase in the number of LN channels reduces the mempool 9 count. The results are significant at the 1 percent level. None of the supply and demand controls have a significant impact on mempool size.13 Table 2: Impact of Lightning Network adoption by number of channels on mempool count. (1) (2) (3) (4) ΔLN channels (log) -0.247∗∗∗ -0.244∗∗∗ -0.251∗∗∗ -0.249∗∗∗ (0.075) (0.077) (0.077) (0.078) ΔLN mean clustering -3.857 -3.803 -4.004 -4.007 (5.959) (6.073) (5.800) (5.918) ΔSegWit txns (%) 0.016 0.018 (0.012) (0.012) Δ30-day volatility -0.024 -0.020 (0.082) (0.082) Δ1-day price change -0.738 -0.744 (0.622) (0.620) ΔMining intensity 0.033 0.042 (0.048) (0.049) Constant -0.001 -0.001 -0.001 -0.002 (0.009) (0.009) (0.009) (0.009) Observations 967 966 967 966 AIC 2589 2590 2589 2589 Notes: Regressions of LN channels (log) on mempool transaction count (log). In all four models, the parameters selected by the Hyndman-Khandakar algorithm are: p = 6 lagged terms included for the dependent variable, d = 1 difference taken, and q = 2 length of window for the moving average of historical residual terms. Data are from January 1, 2017, to September 5, 2019. See the Appendix for variable definitions and data. Our second set of results tests a similar relationship using US dollar values. We regress the USD value of Bitcoin locked into the LN against the USD value of fees attached to mempool transactions. Table 3 shows the results. As before, greater LN capacity is associated with reduced congestion. This time, however, the results are not significant at the 5 percent level once we include supply and demand controls. Finally, we investigate how the LN affects the proportion of low fee transactions in the mempool. 13For each model, Portmanteau and Durbin-Watson tests suggest no evidence of autocorrelation in the residuals. 10 Table 3: Impact of Lightning Network adoption by capacity value on mempool fees. (1) (2) (3) (4) ΔLN capacity (USD log) -0.198∗∗ -0.199∗ -0.197∗∗ -0.198∗ (0.099) (0.102) (0.100) (0.102) ΔLN mean clustering -6.889 -7.233 -7.150 -7.572 (7.940) (7.977) (7.652) (7.674) ΔSegWit txns (%) 0.025∗ 0.027∗ (0.014) (0.014) Δ30-day volatility 0.115 0.122 (0.105) (0.105) Δ1-day price change -0.549 -0.548 (0.837) (0.835) ΔMining intensity 0.030 0.041 (0.058) (0.058) Constant 0.003 0.003 0.002 0.002 (0.010) (0.010) (0.010) (0.010) Observations 967 966 967 966 AIC 3042 3043 3040 3041 Notes: Regressions of LN capacity (USD log) on mempool fees (USD log). In all four models, the parameters selected by the Hyndman-Khandakar algorithm are the same: p = 6 lagged terms included for the dependent variable, d = 1 difference taken, and q = 1 length of window for the moving average of historical residual terms. Data are from January 1, 2017, to September 5, 2019. See the Appendix for variable definitions and data. Table 4 shows that greater LN usage is associated with a significant increase in low fee transactions. Unlike the first two sets of regressions, clustering has a significant and negative impact on low fees. In other words, a more centralized network means that transactions are likelier to have low fees, in line with our priors. Overall, these results suggest that increased LN usage is associated with a significant reduction in mempool congestion. Since there is no theoretical upper limit on LN usage, there is the potential for further reductions in congestion in the future. However, network centralization does not have a clear effect on the efficiency of the network.14 14We also run a set of regressions that include interaction terms between the LN adoption variable and the mean clustering coefficient. In each case, the interaction terms are not statistically significant and their inclusion does not affect the other results. More details are available upon request. 11 Table 4: Impact of Lightning Network adoption by number of channels on low fee mempool transactions. (1) (2) (3) (4) ΔLN channels (log) 0.192∗∗∗ 0.186∗∗∗ 0.195∗∗∗ 0.187∗∗∗ (0.034) (0.035) (0.034) (0.035) ΔLN mean clustering -2.244∗∗∗ -2.295∗∗∗ -2.169∗∗ -2.144∗∗ (0.858) (0.863) (0.864) (0.871) ΔSegWit txns (%) -0.016∗∗∗ -0.016∗∗∗ (0.004) (0.004) Δ30-day volatility -0.018 -0.024 (0.024) (0.024) Δ1-day price change 0.059 0.065 (0.224) (0.223) ΔMining intensity 0.042∗∗∗ 0.036∗∗ (0.015) (0.015) Constant -0.002 -0.002 -0.002 -0.001 (0.002) (0.002) (0.002) (0.002) Observations 967 966 967 966 AIC 692 674 676 658 Notes: Regressions of LN channels (log) on proportion of mempool transactions with fees below 10 satoshis per virtual byte. In all models, the parameters selected by the Hyndman-Khandakar algorithm are the same: p = 6 lagged terms included for the dependent variable, d = 1 difference taken, and q = 2 length of window for the moving average of historical residual terms. Data are from January 1, 2017, to September 5, 2019. See the Appendix for variable definitions and data. In each regression, SegWit has the opposite effect of Lightning Network adoption on mempool congestion, although the results are only significant in Table 4. At first glance, the signs of the coefficients are surprising: greater use of SegWit appears to increase, rather than reduce, congestion. There are a number of possible explanations. First, LN transactions require SegWit, so there is some positive correlation between these variables. However, the exact relationship is not clear, since we do not have data on the number of LN transactions, only on the number of channels and the value of Bitcoin locked in. Second, the causality is not clear. It may be that periods of high congestion encourage greater SegWit usage. Third, since SegWit transactions use fewer virtual bytes than non-SegWit transactions (all else equal), users may be willing to pay a higher fee per 12 virtual byte.15 We can assess the economic significance of reducing Bitcoin congestion by posing the following counterfactual question: if, during 2017, the LN had existed and been the size it was at the end of our sample, by how much would Bitcoin congestion have been lowered? Our results suggest that the mempool count would have been 93 percent lower, mempool fees 96 percent lower, and the proportion of low fee transactions 197 percent higher. These numbers demonstrate that the LN can potentially have a substantial impact on blockchain congestion.
5 Conclusions
We show that usage of the Lightning Network is associated with reduced mempool congestion in Bitcoin and with lower fees. Our findings suggest that the off-chain netting benefits of the Lightning Network can help Bitcoin to scale and function better as a means of payment. Centralization of the Lightning Network does not appear to make it much more efficient, though it may increase the proportion of low fee transactions. Data are not available on how Bitcoin is used, so we cannot say for sure whether Bitcoin is being increasingly used as a means of payment. Makarov and Schoar (2021) study blockchain data and conclude that the majority of usage is for trading and speculative purposes, but their analysis does not extend to transactions that take place on the Lightning Network. We can only say that the Lightning Network loosens a key technological constraint by allowing payments to be settled more quickly