On the Lifecycle of a Lightning Network Payment Channel

TL;DR

This work conducts a measurement study of the Lightning Network to shed light on the lifecycle of channels, and by combining Lightning gossip messages with on-chain Bitcoin data investigates the lifecycle of a channel from its opening through its lifetime to its closing.

Abstract

The Bitcoin Lightning Network, launched in 2018, serves as a layer 2 scaling solution for Bitcoin. The Lightning Network allows users to establish channels between each other and subsequently exchange off-chain payments. Together, these channels form a network that facilitates payments between parties even if they do not have a channel in common. The Lightning Network has gained popularity over the past five years as it offers an attractive alternative to on-chain transactions by substantially reducing transaction costs and processing times. Nevertheless, due to the privacy-centric design of the Lightning Network, little is understood about its inner workings. In this work, we conduct a measurement study of the Lightning Network to shed light on the lifecycle of channels. By combining Lightning gossip messages with on-chain Bitcoin data, we investigate the lifecycle of a channel from its opening through its lifetime to its closing. In particular, our analysis offers unique insights into the utilization patterns of the Lightning Network. Even more so, through decoding the channel closing transactions, we obtain the first dataset of Lightning Network payments, observe the imbalance of channels during the closing, and investigate whether both parties are involved in the closing, or one closes the channel unilaterally. For instance, we find nearly 60% of cooperatively closed channels are resurrected, i.e., their outputs were used to fund another channel.

Figures (17)

• Figure 1: Two exemplary funding transactions. Cooperative closings spend the 2-of-2-multisig output from the funding transaction and do not have a locktime, while commitments use the locktime field to encode the commitment number. By analyzing the outputs from the commitment, we can classify them into multiple types; some of them are used to send funds to the owner of the commitment (after some timeout), while others represent HTLCs or enable fee bumping. Following the local output for the commitment owner to the spending transaction lets us identify whether the commitment has been revoked. We further analyze whether outputs were used to directly fund other channels. Here, the funding transaction in Example 1 has a change output that funds another channel (i.e., Example 2).
• Figure 2: Weekly number of public and private channel openings.
• Figure 3: Private and public channel opening sizes.
• Figure 4: Number of public nodes (cf. Figure \ref{['fig:activeNodes']}), as well as public and private channels (cf. Figure \ref{['fig:activeChannels']}) over time.
• Figure 5: Daily number of channel updates. The median, mean, and 99th percentile are indicated by vertical lines.