Continued Discussion on why Lightning Network Cannot Scale

I’d like to thank everyone in the Bitcoin community that took the time to read an article I published this week called “Mathematical Proof That the Lightning Network Cannot Be a Decentralized Bitcoin Scaling Solution”

This is a quick follow-up to clear up some misunderstandings and objections that people have.

This is Not a “Routing Issue”

The topic of “Lightning Network Routing” has been a common one, meaning “how can we find the best route”. This is a challenge that hasn’t been solved yet (as far as I know), but that is NOT what I am addressing in my article.

I should have been more clear about this: The article isn’t discussing if a route can be “found”, but whether a route even exists!

A lot of the comments about graphs, graph theory, routing tables, and so on are therefore irrelevant as I hope to clarify here.

Understanding the Tree Analogy

As was stated, the network is technically a complex graph. I used the analogy of a tree to paint a mental picture for the average non-technical person. From each user’s viewpoint, we can branch out with the open channels we have, to users that have different channels with other users, and so on.

The probabilities are based on relatively simple math.

In the tree analogy, why is choosing the correct leaf presumed to be a random guess? It is because you may not know ahead of time exactly who, when, and how much you’re going to pay, and more importantly: you don’t know who, when, how many, and what size channels will be connecting to them.

Some people might have some idea about some of these things, some of the time, but for the most part, they won’t.

Probabilities Are Standard Statistical Samplings

The set of all users in the network are like the leaves of a tree. At the time of payment, you know exactly what leaf you want to pick, but you probably don’t know the path unless you set up a direct payment channel with that entity.

By choosing a number of channels and hops, we can then use exponentiation (multiplying something by itself a certain number of times) to find how many chances we’ll have to pick that exact leaf.

In real life, you’ll know if you have a path or not to your payee at the time of payment (assuming perfect routing). Again, the question we’re looking at isn’t whether we can find that path, but whether it exists at all given the current set of open channels.

The probability model is using the total number of users in the network vs the number of users reached with a given number of channels and hops. Since we don’t know which channels will reach which users, it is random (we expect some overlap and therefore won’t reach 100% of the network)

As was also explained in the article, in reality you’ll actually have slightly less chances than the exponential value because some channels will link to users that you already linked to in other “branches of the tree”. But that is ok, because we’re erring on the side of underestimating the unworkability of the system.

Random Graph Vs Social Circles

One objection to my article was that it’s a mistake to assume the network would be “random” because in the real world, people form social circles and have other distinct patterns.

Technically, you can say that social networks exhibit a behavior called “preferential attachment”, which essentially means that your friends are more likely to be friends with each other than with random people. This is sometimes referred to as a “small world network”.

But this makes no difference to the argument being presented, because the money constraint is already forcing us to have a very sparsely connected network with strong practical limitations on both financial intermediaries (low number of hops) as well as open channels.

Even if you had a central planner who could perfectly arrange the network to achieve the utmost efficiency, there’s simply too many people in a group of a million (never mind the whole planet) to connect everyone in a more efficient way than branching out.

The only way to decrease the number of connections would be to pigeonhole everyone into very tiny groups that can’t transact outside the group.

What happens when you want to spend outside your social circle? Someone has to bridge the connection, but who? And do they have to connect to 10,000 other small groups? Cough cough **hub**

The “Small Hub” Idea

One comment I received offered the idea of having “5000 hubs and 3 hops”. I assume he means something like: Alice connects to a hub “A”, which then connects to hub “B” which then pays Bob.

On the surface, it sounds nice: 5000 small independent hubs that only 200 people connect to.

…Until you look at the logistics.

Is hub “A” going to have 5000 payment channels with 5000 other hubs? And how is hub “A” going to actually get Alice’s money over to hub “B” without doing an onchain payment, or having a huge surplus of funds, or both?

Taking Another Look at Routing Time

The most interesting comment I got was about routing time. Someone pointed out that routing can happen quickly. The participants don’t have to wait until the timelocks expire.

This is true but it’s a best case scenario.

For an honest accounting of the “routing time”, we should include all the time that channels are unavailable due to routing related activities:

Not just the actual payment, but time spent organizing routes, waiting for counterparties to be available, and time that a channel does nothing except wait for a timelock to expire.

First, how will Alice organize the route?

If 20 people line up to route except Dave, then you have 19 people waiting and doing nothing, and their channels may not be available for other payments. How long do we wait for Dave? What if Carol leaves but then Dave shows up?

We could assume we’d have world class wallet software that handles all that, but there would still be some amount of organization time.

The longer the route, the higher the chances that someone will go offline, at least temporarily, both before and during the payment. To avoid the whole route being cancelled unnecessarily, a not-too-short timelock period should be used, but the longer this period is, the more time users funds would be locked up if the non-responsive counterparty never shows up.

Unresponsive Channels Have An Exponentially Negative Impact on Routing Time

This wasn’t discussed in the other article, but seems to be strong argument for using a substantial quotient in adjusting the probabilities based on routing time.

When you have an unresponsive counterparty in a series of hops, it greatly increases the routing time, not just for that route… but for all possible routes that would use any of the downstream channels in the stuck route, since they are now waiting too.

For example, if we look at a scenario with 2 channels per user, 20 hops per route, and 100 transactions a month: 20x100= 2,000. That’s 66 transactions per user per day, or 33 transactions per day per channel.

If the last channel in route is unresponsive, it could cause delay to 19x33 (627) other routes.

The Real Problem Is…

The real problem is not the model, or assumptions or the math, but political agendas.

Lightning network is an extremely clever incentive system, and the market may find that it has utility in a limited fashion. However, we are being sold LN as something it is not.

It does not scale the way most people think. The benefits are being exaggerated and the drawbacks are not allowed to be talked about.

We are told “SegWit + LN” will solve all our problems, therefore we do not need a blocksize increase. Its time to bypass political narratives and get back to common sense and real science.