If you want to run your own Lightning node, there are currently three main implementations. In this slightly more technical post, we'll briefly introduce them and then we'll look at their market share, including how it can be obtained.

Lightning Network is a payment network that allows anyone to create their own node implementation. To be compatible with the rest of the network, you just need to follow the BOLT specification. However, this is very complex task and so the vast majority of users will use some already-made solution/implementation.

Today, we have three main implementations to choose from:

LND is definitely the most widely used Lightning implementation, which stands out for its simplicity and friendly API. LND is also part of the vast majority of ready-made solutions such as Umbrel, myNode or Raspiblitz, where it is often the only (or at least the default) implementation. Because of this, it has a large number of additional tools/extensions made by community and is suitable for beginners. However, advanced users or large nodes operators can use it also for sure. Recently, however, this implementation contained two vulnerabilities that slightly damaged its reputation.

Core Lightning is an alternative implementation and a "number two on the market" that is known for its stability and modular architecture. This means that you can install a lot of extensions in the form of standalone plugins in addition to the basic features. This makes it more suitable for slightly more advanced users who can customize it as they want.

Eclair targets more corporate clients, i.e. giant nodes with a very high number of channels and transaction volume. This implementation allows the node to be spread across multiple servers that distribute individual tasks among them using loadbalancing methods. Compared to previous implementations, there is a minimum of any community extensions.

Within the lightning protocol itself, there is no "header" anywhere describing which specific implementation the node uses. Thus, it is unrealistic to find out the percentage distribution of node implementations exactly.

But we can make a relatively good guess. How? Each implementation has slightly different default values, and we take advantage of that. One of these values is cltv_delta. This is the number of blocks the node reserves for HTLC processing when forwarding a payment. In other words - it is the time difference between the outgoing and incoming HTLC.

The lower we set the cltv_delta value, the more risk we take, since after forwarding the payment towards the recipient (and getting payment_preimage) we have less time to contact the node towards the sender and get our funds. This may even end up in a force-close in the form of an on-chain transaction if this node is unavailable for long time, where this parameter then plays a crucial role.

On the other hand, a very high value means that the sender's resources may be locked for a longer period of time in case of problems, so this route is usually less preferred.

It should be clear from the text above that there is no one correct value (although the BOLT specification partially defines it) and so each implementation has chosen it in its own way:

The cltv_delta value is propagated through the network within the gossip protocol in the channel_update message along with information such as fees, minimum and maximum HTLC, etc.

We will need a network graph - a list of all nodes and channels. This graph is public information and is maintained by each node. Unfortunately, there is no one correct graph. In fact, due to the way it is propagated, each node may have a graph slightly different from the others. Therefore, for these calculations, I used graphs from multiple nodes and averaged the results. The individual differences were below 1% for all parameters.

Next, we take advantage of the fact that most node operators do not understand the cltv_delta parameter and so they leave it in its default state. Thus, if the values of cltv_delta are the same for all channels of a given node, and at the same time this value corresponds to one of the defaults, it can be assumed that this is a given implementation.

If, on the other hand, at least one value of cltv_delta is different from the others or is not one of the default values, the node operator obviously modifies these parameters and cannot be relied upon. We discard such nodes from our statistics. Fortunately, this is only less than 7%.

To maximize the accuracy of the results, I excluded those channels that have not sent channel_update within the last 14 days, so according to the specification they should be considered outdated. Now is the time to create a script that will process the relevant data.

So what is the result? Exactly as expected, the LND implementation dominates. In other words, 91% of Lightning nodes have the cltv_delta value set to 40 blocks for all their channels, so this is most likely LND.

By the way, these results are almost identical to the study from September 2020. Here, additional parameters were used, namely the minimum HTLC size and fees. The result was then calculated based on different weights for each parameter, with cltv_delta having the highest weight (75%). Since a lot of tools have recently been developed that automatically adjust these parameters, I did not include them in my calculations.

In addition, other interesting information can be retrieved from the graph, such as the average number of channels for a particular implementation or the average total capacity of a given node.

As can be seen above, the results support the description of the individual implementations from the beginning of this post. LND makes up the vast majority of the network due to the fact that it is part of most ready-made solutions, but these are primarily smaller nodes. In contrast, Eclair is on the other side of this ranking, as it powers, for example, the ACINQ node, which currently has nearly 3500 public channels and thousands more private ones. And somewhere in the middle stands Blockstream with its Core Lightning implementation.

Finally, it should be noted that the above figures are only an estimate, because: