Lightning Network Status Report: MAJOR Flaws and Topology Concerns

Interested in access more free crypto analysis, resources and information like this? Check out these platforms:

Telegram —

Twitter —

I expect this article to come under a lot of fire and I welcome it all. Post your comments, negative or positive at the bottom. I’m more than happy to open a dialogue about what’s going on:


The Lightning Network, which has long been touted as the ultimate scaling solution for bitcoin, has been rumored to be close to development.

However, since the inception of the idea, there has been major pushback among some sects of the community, which has escalated to the point of creating a hard fork (Bitcoin Cash) in the bitcoin protocol. This, in essence, has split the community in two.

The Source of Contention?

Scaling. Specifically, implementing larger block sizes in these scaling efforts. Depending on who you ask, lightning network is a potential work around to increasing the block size of the bitcoin protocol.

Lightning Network Progress

There has been a lot of purported progress on the Lightning Network protocol in recent days. So, here are some stats below to help readers assess what the true state of Lightning Network implementation is at the time of writing:


This is an important statistic to note, because SegWit was the Core team’s fix for transaction malleability. Long story, short — transaction malleability is something that could potentially compromise the hash-lock functionality of the Lightning Network (ELI5: this could enable people to cheat the system).

So, this is why SegWit TX are worth tracking.

Here are Some Other Major Statistics (Topology) Information From the Lightning Network That Must be Reviewed


Interpreting the Stats Above

The overall stats show that the Lightning Network is in its infancy when it comes to actual adoption and some of the stats are a bit troubling.

Let’s review all the stats below:

Nodes — The number of nodes, which bitcoinvisuals shows are numbered around 840 for nodes with and without channels and 611 for those without channels, shows that only 229 Lightning Network nodes are currently operating with active channels. This number is microscopic in comparison to the number of Bitcoin Core nodes that are currently available:


In reviewing this, the author (CryptoMedication) realizes that there is a discrepancy between the number of nodes reported on this site and what other sources have stated.

For instance, ACINQ (one of the companies responsible for developing Lightning Network) shows 1134 active nodes on their platform:


In either case, the difference between the numbers presented between all of these sources has hardly any bearing on the rest of the statistics, which paint a more grizzly picture for the Lightning Network protocol.


Based on the numbers from all sources reporting on Lightning Network channels that are currently available, there are approximately 3,000 channels open among all nodes.

Network Capacity

This is one of the more telling factors of the Lightning Network’s growth at this point in time. As noted in the chart posted above, the network capacity refers to the, “Cumulative bitcoin capacity across all channels.”

As of right now, it stands around 9 bitcoins. Given the market price at the time of writing (we’ll round it to $7,000 for convenience), this represents a total of $63,000 on the Lightning Network.


According to the latest information from at the time of writing, there are approximately 16.9 million bitcoins in circulation. So, the total amount of coins that are on the Lightning Network total to a fraction of a percent currently.

Capacity Per Channel

This was yet another concerning statistic that was noticed on the website, because the capacity had actually decreased from February (when it starts tracking this data) to the current time of writing (March 31st, 2018).

According to the chart, on January 19th, 2018, the average capacity per channel was at $135, or 1.1 million sats.

More recent information shows a much bigger downturn in the total capacity.

As you can see from the cropped picture above, the capacity went down from 1.1 million sats to 263k sats, which is a drop of 76% over the year of 2018. This is pretty substantial to say the least.

Distance Measures

This stat remained relatively consistent from the time that this data started being tracked to now. It’s a bit harder to evaluate the max number of hops at this current point in time, because there are no case studies to make inferences about what the optimal value for this metric should be.

Completeness Measure

This category’s definition reads, “Density is a ratio of actual/potential channels”

So the smaller the ratio, the lower the number of actual channels to the number of potential channels, vice versa.

Clustering Measures

This measure is a bit more difficult to assess.

So, let’s start with the definition for it, which says, “Transitivity is the ratio of potential triangles present. A value of 1 means every path of length 2 loops back into a triangle. Clustering coefficient is the ration of interconnections between a node’s peers. A value of 0 means the node is a hub, and none of its peers are connected. A value of 1 means the node forms a clique with its peers.”


What Does All This Mumbo Jumbo Mean?

Basically, transitivity, in this sense, can be seen as a measure of how ‘centralized’ the Lightning Network is. The closer to 0 the transitivity value is, the more centralized things are. The closer to 1 or 100% that the transitivity value is, the more decentralized everything is.

Above is data regarding the Transitivity percentage on February 11th, 2018 — which was 11.1%.

Currently, however, the transitivity has decreased, which means that the Lightning Network has become more centralized relative to where it was on February 11th, 2018.

Even the 11% mark seems to indicate that this sidechain solution is highly centralized at the moment.

However, given the fact that the actual transfer of bitcoin on the network is so low at this point, this may neither be here nor there.

Connectivity Measures

This metric for the Lightning Network is defined by viewing cut channels. Cut channels are, “…a channel between two nodes that connects different components of the network. This channel’s removal would prevent other nodes from having a path. A cut node (aka cut vertex) is the same idea, except it’s a crucial node instead of a channel.”

Check out the progress below:

On February 11, 2018, cut channels represented 28.5% of the total and cut nodes were 6.7% of the total.

At the time of writing (approximately), cut channels only represent 20.7% of the total channels while cut nodes represent 5.2% of the total.

What Can be Inferred From This Data?

Given the nature of what cut channels and cut nodes are, it stands to reason that a big drop in cut channels rather than a big drop in cut nodes shows that the number of nodes that function as ‘hubs’ has barely decreased over the examined time period.

Thus, it is more than likely that the nodes that are not hubs, that have connected with the hub nodes have been the ones that have dropped off the network, resulting in the closing of their channels and the more rapid decrease of cut channels on the network.

This all falls in line with the data presented in the transitivity metric.

Channels Per Node

This category is a bit more flat. This simply measure the average number of channels involving a node.

Please see below:

On January 19th, if you had 1 channel alone you were already at the 10th percentile. Add another connection (channel) to a node and you’d be in the 50th percentile. Just two more from there would put you in the 90th percentile.

However, now, the stats are a bit different at the time of writing.

The graphic above shows that, as of March 30th, 2018, one would need 15 channels or more to be in the top 90th percentile according to the topology report.

What Does This Mean?

The vast majority of channels on the network are produced by singular node entities. This, too, fortifies the idea that the protocol has become substantially more centralized over the last few weeks.

Capacity Per Node

This metric is simply defined as, “Capacity across all channels involving a node”

On January 19th, 2018, when this metric started being tracked, the total average was $526 or 4.5 million sats.

However, now, it is 1.8 million sats, which amounts to an average of $130.

This, once again, shows a huge drop-off from just a couple of months ago.

Lightning Network DDoS Issue

Apart from the metrics of the Lightning Network’s topology, there are some other technical issues which appear to need great refinement either.

Some of these issues were exposed to a fairly substantial extent when the network faced a DDoS attack (appears to be part of a bounty and not of a malicious nature), which took approximately 20% of the network offline on March 21st, 2018.

This event is substantiated by a tweet from a user on Twitter by the name of Alex Bosworth, whom is a developer for the Lightning Apps protocol:


The user that allegedly performed the DDoS attack on the network according to a recent article by TrustNodes, is an entity/person by the name of ‘bitPico’.

Their suspected Twitter page (handle = @bitPico) URL is

The bio on their Twitter page indicates that this entity is more than likely more than one person. It simply states, ‘Bitcoin Developers’

Their most recent two tweets also indicate that they are in support of the Lightning Network as the ‘TrustNodes’ article originally suggested.

Their pinned tweet, posted on March 17th, says, “We are no longer retired from #bitcoin; just needed a break. We are bullish and working on the #LightningNetwork”

The last portion of this tweet provides even more credence to the theory that they may have been the ones responsible for the DDoS because of their assertion that they were ‘working on the #LightningNetwork’ and performing the DDoS would fit under that umbrella.

How was the DDoS Performed?

The biggest evidence/source of information regarding the nature of the DDoS itself comes from what appears to be a ‘leaked’ Slack conversation between this bitPico entity and a Lightning Network developer (?). See below for the excerpt:


According to the ‘TrustNodes’ article, which covered this situation, “The exploit is basically using as many node connections as possible so as to prevent any new connections, with potential solutions being to limit the number of connections per IP.”

This theory seems to be corroborated from the chat excerpt posted above.

Blockchain History Can Help Us Understand This

For those that are unfamiliar with blockchain history, this will be a helpful review. Way back in the days, Satoshi Nakamoto (founder of bitcoin) was faced with a dilemma regarding the bitcoin protocol:

What if someone decides to spam the network with a bunch of minute transactions?

This was a pertinent question in 2010 because the price of bitcoin was pennies on the dollar. So, a transaction for 100 satoshis, for example, would have been virtually free for anyone attempting to compromise the network.

This is what prompted Satoshi to implement a fee network. He figured that by implementing a minimum fee (which was later lifted) of .01 satoshis, it would be prohibitively expensive for an individual to spam the network.

Fees were also added as a way of allowing individuals to get their transactions through in the instance that such an attack did flood the network. The most recent bull-run in December was the perfect example of this phenomenon playing itself out in a real-world scenario.

How is Any of this Relevant?

Good question.

So, the Lightning Network, as you all know, does not have the same structure because it’s technically not part of the Bitcoin protocol. So, it isn’t constrained by the same rules. Technically, there are no fees (unless a Lightning Network node decides otherwise).

Also, there are substantially more nodes on the bitcoin network than the Lightning Network (as noted before), so an outright Sybil attack vector is highly unlikely to be successful and the resources required to erect enough fully functioning nodes in order to gain >50% of the total network’s node supply would be prohibitively expensive and infeasible.

However, this is not the case with the Lightning Network. It appears that the ‘bitPico’ account was able to attack the network using a Sybil Attack, which essentially is like replicating the ‘names’ or identities of other nodes on the network. As they attempt to make connections with other nodes in the network, it essentially confuses them and overloads the network. Given the fact that the nodes do not currently have the necessary throughput to handle/filter these requests or validate them, they were taken off the network with ease. This is what bitPico more than likely meant when he said that he was ‘exhausting TCP/IP stacks as we speak’.

Peter Todd’s Feedback on Lightning Network

Peter Todd, a Bitcoin Core developer, is another individual that has mentioned some of the drawbacks of the Lightning Network in terms of security. In fact, the multitude of tweets that he posted on the issue are something that everyone curious about Lightning Network should take a serious look at before making any definitive assertions about the Lightning Network’s functionality. See some of Peter Todd’s tweets below:

These tweets are probably more palpable/digestible for the technologically inclined, but Peter is essentially bringing up the fact that the protocol is not designed in a way that allows for the inherent securitization of transactions in the same way that the bitcoin core protocol does (Proof of Work verification).

Final Notes and Observations

What we’re seeing here are the inevitabilities that individuals in the community have spoken about for months/years before this point. There are multiple different indicators from the topology that you see above as well as statements that have been made by other individuals with the technical expertise to assess the project which indicate that centralization is an inevitability of the project’s design as this is the only way that it can ensure the security of the network.

However, given the fact that the network is not protected by the underlying Bitcoin protocol and there are no ‘copy to disk’ features for the nodes that are on the network currently, in addition to the fact the economies of scale within the network are rapidly being taken by a large quantity of ‘hubs’ — the Lightning Network, as it stands, is a major potential point of failure for the bitcoin protocol.

This Article is Not Meant to be ‘FUD’

Before this article even gets shared around the crypto circuit, I’m expecting that the primary response to it will be that this is “unnecessary FUD”. However, the purpose of this article isn’t to produce FUD. This was created as a way to actually give a thorough overview of where the Lightning Network is at, at this point in time.

I’m not asserting that there is nothing that can’t be done to improve the state of affairs on the network. However, as adoption increases (if it does), it seems inevitable that the transitivity percentage will continue to decrease. I believe that the resources that one must deploy in order to secure the network will be prohibitively inconvenient, risky and expensive. In addition, the fact that there will be major hubs on the network means that that their potential derailment on the network could be a major source of lost funds for users that are using these intermediaries.

None of these concerns have even covered some of the other logistical difficulties, such as increasing the transaction capacity of the nodes themselves, assessing the massive amounts of illiquidity on the network (remember someone most have at least the amount you are trying to transact in order to facilitate the channeled transaction), or dealing with how to limit node requests/filter them effectively enough to prevent Sybil attacks.


These facts are not from r/btc, I don’t work for bitcoin cash nor do I have an investment in bitcoin cash. In fact, I’ve been critical of their protocol as well in respects to their poor PR campaign, failure to prevent replay attacks upon the UAHF, and insistence upon an adjustable block size algorithm.

I’m not anti-bitcoin.

I do not currently hold an investment in bitcoin or bitcoin cash at the time of this article being published.

I have owned both currencies for brief periods of time for purely speculative purposes.

This article is neither an endorsement or rejection of the Lightning Network and isn’t mean to be financial advice either.

Hopefully this information helps you to make your own conclusions.

One comment on “Lightning Network Status Report: MAJOR Flaws and Topology Concerns

  1. I have noticed you don’t monetize, don’t
    waste your traffic, you can earn additional cash every month with new monetization method.
    This is the best adsense alternative for any type of website (they approve all sites),
    for more details simply search in gooogle: murgrabia’s tools

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.