Blog: Lightning Network Observations on the Bitcoin Mainnet

By: Viacheslav Zhygulin, Mykola Sakhno, Kostiantyn Pisnia and Alex Ostrovski (LightningPeach team, Bitfury Software)

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 2x2 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.