Blog: Lightning Network Observations on the Bitcoin Mainnet

Source: https://medium.com/@BitfuryGroup/blog-lightning-network-observations-on-the-bitcoin-mainnet-e5bfebb6fb00

https://www.bitcoinlightning.com/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.

 

 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

 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. 

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

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. 

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.

_______________________________________________________

About our Lightning Network Development Team, LightningPeach

Our Lightning Network work is led by LightningPeach team, which is a part of the Bitfury software department. We have been researching the Lightning Network for almost two years. Our work is focused on solving challenges that the Lighting Network faces in order to help the network achieve global adoption. We are currently working on several projects, and we will share more information on our results soon.

https://lightningpeach.com/

_______________________________________________________

The technical details on how we detected LN-related transactions

Commitment transaction contains:

- First 8 bits of locktime are 0x20

- Sole input is spending from 2x2 P2WSH multisig. Upper 8 bits of sequence are 0x80

- 0 or 1 P2WKH outputs

- Any number of P2WSH outputs. Three possible script types: to_local, offered_htlc, accepted_htlc. In this research we didn’t check whether script has this particular structure

- Version 2

The commitment transaction may not have P2WSH outputs because outputs below dust limit are not created.

Closing transaction contains:

- Locktime of 0

- Sole input which is spending from 2x2 P2WSH multisig. Sequence number is 0xFFFFFFFF

- 0,1,2 outputs. They can be P2WKH, P2WSH, P2SH, P2PKH. However, implementations create P2WKH outputs only.

- Version 2Comparing the locktime to 0 is an easy way to distinguish mutual closings.

Funding transaction contains:

- Any number of inputs

- Any number of outputs

- Should be not-malleable

- Has at least one P2WSH output

Data was gathered by searching the Bitcoin Blockchain for transactions with a specific form, so not all found transactions may be actual Lightning channels and some channels may not have been found (for example if a closing transaction uses not only P2WKH outputs, but other types too).

To estimate the accuracy of the method, we have compared it with the direct observations by a Lightning node over the span of two weeks. The blockchain scan observed 2,414 closing transactions, compared to 2,088 seen by the node. Of the 51 channels the blockchain scan did not detect, all of them used a mutual closing with a closing transaction that had other output types besides P2WKH outputs. The Lightning node did not observe 377 closings compared to the blockchain scan, which estimates that the level of private channels in the network is ~ 16%. The blockchain scan can be configured to detect closing transactions without P2WKH outputs, but this would increase the false positive ratio, so it was not considered in this research.  

• Bitcoin
• Blockchain
• Lightning Network

Source: https://medium.com/@BitfuryGroup/blog-lightning-network-observations-on-the-bitcoin-mainnet-e5bfebb6fb00

https://www.bitcoinlightning.com/lightning-network-observations-on-the-bitcoin-mainnet/

 Regards, @majestyman