Lightning Network Observations on the Bitcoin Mainnet By LightningPeach team

It has been more than three months since the release of lnd 0.4, which marked the first Lightning mainnet beta. The year 2018 has already seen many other important breakthroughs that bring us closer to taking the Lightning Network mainstream. As the Lightning Network grows and expands its user base, we want to share some recent statistics that our Lightning Network development team has collected, as well as our thoughts on the overall direction of the network. The framework we use for collecting these statistics provided in this article, will be released soon as an open-source tool.

Before moving forward, it is important to define some of the terms and parameters we used in our observations. First, Lightning channels can be closed unilaterally (uncooperatively) or mutually (cooperatively). The terms “unilateral closing” and “mutual closing” are defined in Lightning-RFC, so we will use them here.

Second, the Lightning specification contains the following transaction types: (https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md):

Funding transaction is used to create a channel and has 2×2 multi-sig P2WSH output.

Commitment Transaction is used for unilateral channel closing.

Closing transaction is used for mutual channel closing.

HTLC (hash time-locked contract) timeout transaction is used at the second stage during unilateral closure for offered HTLC.

HTLC success transaction is used at the second stage during unilateral closure for accepted HTLC.

In this set of research, we focused on funding, commitment and closing transactions. First, we scanned the blockchain for transactions with this structure. Then, we scanned each transaction in the block and checked to see whether it matched the criteria for a commitment transaction or a closing transaction. If there was a match, we checked criteria for the parent transaction, which should be a funding transaction.

Key Statistics and Observations:

1. The percentage of unilateral channel closing relative to all closings remains high.

Fig 1. Rolling mean (2 days) of percentage of unilateral channel closings to all closings. Group interval is 24h.

Total number of closed channels: 14,287 (100%).
Number of mutually closed channels: 2,487 (17.4%).
Number of unilaterally closed channels: 11,800 (82.6%).
Number of unilateral closings where the commitment transaction has a single output of the P2WKH variety: 7,211 (50.5%).

The P2WKH output in the commitment transaction represents the balance of another party. Other balances, like the self-balance and HTLCs, are represented by P2WSH outputs. Thus, if a commitment transaction has a single P2WKH output, all other balances are below the dust limit. This represents a situation in which a party that has no balance in a channel unilaterally closes it. This is “strange” because if a party has nothing in a channel, there is no economic incentive to close it. You have an incentive to keep it open to receive at least some amount.

Our hypothesis is that a “strange” closing may appear when somebody opens the channel for testing and, after the testing is done, developers leave the channel unattended, leading to the channel being closed by a counterparty. Another fact is that many unilateral channel closings were carried out by Lightning nodes using c-lightning realization of the protocol because of the flaw with on-chain fees described here in Section 5 of this article.

Because unilateral closings have not decreased, it is reasonable to assume that the network has not yet transitioned from testing to production and that the Lightning Network is mainly used for testing, rather than “real” financial transactions. This is to be expected, since the technology is in its early stage of development and much testing needs to be done.

2. Multi-hop transactions work mainly within top nodes offering better conditions for now

Fig 2. Connectivity graph among the top-10 nodes as of June 04, 2018. The total capacity of the channels is displayed on the graph edges. If there are multiple channels between nodes, the label shows their total capacity. Vertex labels show node alias and total capacity (sum of capacities of all channels).

As you can see in the graphic, at the time of writing, the network is still too small and working mostly as sandbox for tests. The network is not complex and the top-10 nodes contain 50% of the capacity of the entire network. 41% of the nodes of the network are directly connected to the top-10 nodes. The top-10 node cluster itself is relatively well-connected for a small test network, but, in time, will become more complex and top-node competitive. Once this happens, the network will begin growing with real use cases.

Due to connectivity, even now if you are connected to one of the top-10 nodes, you can send multi-hop transactions within the top-10 node cluster with a very high probability of success. However, it may be difficult to rely on the same success level for other multi-hop transactions because of the disparity in channel capacity inside and outside the cluster. Indeed, the median capacity for a channel directly connected to the top-10 is 130 USD, and the median capacity for other channels is 3.7 USD. More than that, channels between top nodes and smaller ones are usually funded by small nodes; thus, for effective routing or receiving payments, a peer of the top node should first spend some bitcoin in the channel.

Note: Bitcoin exchange rate ~ $7.399.06 per bitcoin

3. The most frequent values for channel size are round numbers

Fig. 3. The most frequent values of channel size are round numbers (e.g., 0.001 bitcoins), which are represented as spikes on the diagram above. This implies that the Lightning Network is currently used mainly for testing purposes.

4. A channel lives 239 hours (10 days) on average, with a median lifetime of 99 hours (4.1 days)

For efficient operations, Lightning channels should live much longer; ideally, they should live indefinitely. Services like submarine swaps could make the situation better in the near future, however, by allowing for exchange between on-chain and off-chain funds. This could reduce the need for closing the channel to obtain off-chain funds.

Fig 5. Shows open and close (both mutual and unilateral) rates with a few relevant events

5. Important events on the network affect the rate of channel openings.

Events shown on the graph:

2018–03–15: Release of lnd 0.4.0

2018–03–28: Release of eclair for mainnet (link)

2018–04–02: BitPico takes credit for attack (link)

2018–04–03: Release of lnd 0.4.1

2018–04–24: Sharp increase in BTC on-chain fees, which led to mass channel closing by nodes using c-lightning realization of the protocol due to the bug described here: https://github.com/lightningnetwork/lnd/issues/1086(source)

2018–05–29: Release of lnd 0.4.2 — The release of a new version of lnd usually leads to peak in channel opening. After the release of lnd 0.4, we observed more activity present in the Lightning Network. As a result, the speed of channel openings has been increased.

6. Distribution of the number of nodes by node degree

Fitting data shows that the node degree (that is, the number of open channels) follows the power law with the exponential coefficient -2.26 starting from degree 8. Therefore, we conclude that the Lightning Network is scale-free, which implies a high degree of fault tolerance, meaning the network could tolerate the exclusion of any node. (Data fitting was done using https://github.com/jeffalstott/powerlaw.)

7. Large channels are closed unilaterally more often.

Performing a chi-square test on the correlation of channel size and unilateral channel closing yields the probability value p=1.7e-16 (the null hypothesis is the absence of correlation). Thus, this correlation is statistically significant.

Our hypothesis is that channels with smaller capacities are left unattended more often by both parties; it is reasonable to wait some time until the counterparty comes back online. In contrast, if the channel capacity is large and the counterparty goes offline, there is a high incentive to withdraw bitcoin immediately with unilateral closing.

8. Contract breach (due to dishonesty or a failed load from backup)

On an average day, less than one punishment for the incorrect channel closing occurs (that is, a situation in which a channel participant publishes an outdated channel state to the blockchain, allowing the counterparty to slash his funds as the retribution). There were a few days (March 25, block 515141; March 27, block 515413) with a much higher number of punishments.

This situation has been investigated in the following article: https://www.trustnodes.com/2018/03/26/lightning-network-user-loses-funds

Discussion

Currently, the Lightning Network is in the “experimental” mode, meaning many people connect to it simply to observe how it works. These “experiments” result in a large percentage of unilateral closings (as suggested by the sharp peaks in “round” channel capacities). Most of the current network activity is comprised of tests performed by developer teams. The network is still growing and will require more nodes to create a competitive market of alternative routes for fully-functional payments via LN. After the exponential growth the network experienced in the first few days of having mainnet clients, the number of LN nodes is now growing now almost linearly with time. The network is likely to experience a surge in growth, leading it to surpass some “X amount” of top nodes. Merchant adoption and the ability to open incoming channels (to receive payments) could be helpful in revitalizing the network.