After sending 1000 lightning network transactions, we have something to say.

Note: This article comes from a technology company. By establishing a lightning network node, the company understands and discovers the technology and its problems, but is still optimistic about the lightning network, and believes that its application scenario exists.

As early as February 2017, I and my colleague established their first lightning network node on a ski trip. We don't know much about how it works, or what it can be used for, but we all think it's a very cool technology. Looking back, we encountered a lot of problems in testing and using this node.


Establish node

The nodes we set include the Bitcoin Core and CLightning nodes. There are many tutorials for setting up nodes, and there are even pre-configured dedicated hardware devices (such as Casa). We chose to manually install and synchronize the node and lightning network services on AWS's Ubuntu server.

Our initial idea was to create the largest node on the network. This is possible when there are only about 100 nodes on the network, but today, this requires more money and a very powerful server.

We finally developed a pilot project, LightningD, through CLightning, which is another way to deploy lightning network nodes. The project we created was able to scan all the nodes on the network and create a channel that connects to the nodes with the most external connections and operates.

Our node was once the most externally connected, with approximately 200 channels established, and nearly 5% of the bitcoin in the network is locked in these channels.

Channel damage problem

In the process of challenging the limits of this new software, we did find some edge cases. Many of the channels we created eventually became invalid bitcoin transactions, Lightning Network nodes broadcast them, but Bitcoin nodes don't, and Lightning Network nodes still wait for confirmation and no problems are found. This will cause the lightning network node to be out of sync with the actual state of the channel, causing the database to be corrupted.

When we try to challenge the limit on the number of nodes, there is a crash. When updating the state of a channel, the corrupted channel state plus the incoming and outgoing nodes seems to create edge problems in the database values. However, the Blockstream team and other contributors helped us discover and solve these problems, thank you very much.

However, we have never lost money. Although we once thought that we lost about 0.2 bitcoins due to channel damage. We must manually close the channel and resume the frozen funds to reopen the channel. Eventually, the database was badly damaged, we took out all the funds and used a normal database from scratch. This does mean that we have closed all public channels and disconnected from other nodes, but at the same time, we are particularly relieved because we know that there will be no financial loss.


Last month, our Lightning Network node paid more than 1,000 deals. After using the latest version of CLightning, it is surprisingly stable. Since we and the counterparty directly open a channel, we don't need to think too much about payment routing, which has been a weakness of the technology.

While many teams are working on launching a client-facing wallet to try to solve more problems, the process of building and connecting channels remains a challenge. The time and effort spent on creating a channel can be a barrier to adoption by the consumer, so it is more likely to become an enterprise tool.

In addition to some of the frictions and problems we initially faced, Lightning Networks has proven its applicability to frequent and fast micropayments. For some use cases, such as exchange arbitrage, pay-per-minute services (Internet bandwidth), and frequent payments for unmanaged account balances, the application scenario is real.

We are very much looking forward to seeing the progress of this technology.