Mathematical Proof That the Lightning Network Cannot Be a Decentralized Bitcoin Scaling Solution

Have you heard of the Bitcoin Lightning Network? It is a proposal that claims that:
“using a network of these micropayment channels, Bitcoin can scale to billions of transactions per day”
What it doesn’t tell you is that this can only be accomplished by using large, centralized “banking” hubs.
Many in the Bitcoin community mistakenly assumed or were led to believe that the Lightning Network (LN) would be a distributed peer-to-peer network.
However, this is infeasible. In fact, even using a generous set of assumptions, we will prove it is mathematically impossible.
We will divide this document into sections. Part one will be a brief general overview of the LN. Part two will explain in simple terms why it cannot provide decentralized scaling. Part three will be a more rigorous mathematical proof.
PART I: OVERVIEW OF LIGHTNING NETWORK
The Bitcoin Scaling Debate
Bitcoin was originally designed as peer to peer cash that would scale with simple blocksize increases. However, the discussion over how to scale the network has become a lot more complicated and controversial.
57 Bitcoin “Core” developers have signed their support to an official Capacity Increase Roadmap that advocates the Lightning Network as a “non-bandwidth scaling mechanism” that may provide “very high decentralization”.
We disagree and will prove it does not. After reading and understanding the information here, we recommend you draw your own conclusions.
What is the Lightning Network and How Does it Work?
Lightning Network (LN) is a protocol allowing for a series of off-chain bidirectional payment channels. Here is an excellent 3 part series by Aaron van Wirdum, if you would like to understand the technicalities.
“Bidirectional” simply means two directions, so Alice and Bob could open up a private channel and send bitcoins back and forth (outside of the blockchain):

In order to open the channel, one or both parties have to deposit bitcoins into a special Bitcoin address.¹ After that, they can do as many transactions as they want inside the channel, until either of them decide to close it, which settles (pays out the appropriate final balances) on the main Bitcoin blockchain.
Linking Multiple Channels
Going one step farther, if Alice had a channel with Bob, and Bob also had a channel with Carol, then Alice could indirectly send money to Carol: Bob would first pay Carol, and then Alice would reimburse Bob.

The Envisioned Network
LN evangelists promote the idea that if Alice can pay Carol through Bob, we should be able to keep extending this idea to build an entire network of payment channels, thus allowing a large percentage of transactions to occur off-chain.
However, this cannot be realistically accomplished as a peer-to-peer network, at least not one of any significant size.
“Decentralized” Vs “Distributed” Semantics
In everyday talk about Bitcoin, most people say “decentralized” to mean what is technically a “distributed topology”.
Conversely, a network with centralized hubs can technically be called “decentralized” if it doesn’t have a singular center.
But let’s not get caught up in word games. The diagram² below should clear things up:

PART II: AN EXPLANATION FOR THE LAYMAN: WHY THE LIGHTNING NETWORK CANNOT SCALE
I’ll make this explanation as short as I can.
First, you must understand that the Lightning Network is not like other networks in that you cannot simply connect to another user whenever you want.
To send or receive bitcoins, you need either a payment channel with that specific user, or a linked series of payment channels (a “route”).
It’s pointless to create a payment channel for the sole purpose of sending an off-chain transaction, since it requires an on-chain transaction to open the channel (and another one to close). You might as well just send an on-chain transaction instead; you don’t need the LN.
The idea is that you’re supposed to be able to route your payment to any destination through a series of connections. From the viewpoint of a user, the potential path to anyone else looks like a tree structure:

It Starts Off Like a Basic Math Problem
We’re going to assume the goal is to scale to one million users.
Let’s think about this: If you have a tree with 10 branches, and each of those branches has 10 leaves, you can reach 100 leaves.
And if you have a tree with 10 branches, and each has 10 sub-branches, and each of those in turn has 10 sub-branches , etc… you can go 6 levels “deep” and get: 10 x 10 x 10 x 10 x 10 x 10, or simply: 10⁶, which equals one million.
Since you have to hop from branch to branch 6 times to reach the leaf, we can say we have “6 hops”. So that’s 10 branches with 6 hops, or in our case: 10 channels with 6 hops.
So, what’s the challenge?
Your Money Can’t Be In Two Places At the Same Time
If we assume we need 10 payment channels to reach the entire network in 6 hops, that means you’d have to divide up your bitcoins into 10 parts.
But, probably only one of these channels will reach the intended recipient at any given time. That means you’ll only be able to send part of your money, for example 10%.
Could we get around this by just having 2 channels and, say 20 hops? We’ll come back to this question. First, let’s understand another important fact:
Everyone is Lending to Everyone Else
Imagine Alice wants to send 1 BTC to Carol through Bob like so: Alice->Bob->Carol
In order to route the money, Bob has to have at least 1 BTC in his “balance” in the channel with Carol. Essentially, Alice is borrowing from Bob to pay Carol.
Bob transfers his 1 BTC to Carol in the [Bob->Carol] channel, and Alice transfers 1 BTC to Bob in the [Alice->Bob] channel. That’s how it works — Alice cannot “give” the 1 BTC to Bob to then pass along to Carol.
It really is a loan because the network uses timelocks to eliminate custodial risk: Alice can’t repay Bob safely until she’s sure Bob has paid Carol.
In fact, EVERY hop en route to a destination must have the funds available for each transaction. So, the more hops that are used, the more this lending burden is multiplied.
Why is this a big deal?
It Means a Large Number of Hops is a Deal-Breaker
Let’s say that everyone was using routes with 20 hops, and most users spent about $1000/month. If everyone did their fair share to help route payments, each user would need to route $20,000/month.
Would that even be possible?
It depends on many factors including: the amount of time required for a route and the number of transactions.
Even if we make a (possibly generous) assumption that a user can route 20 times his normal transaction load and only suffer a reduction of 50% in the availability of his channels, then he would need double the number of channels he normally would have.
In Reality, It’s Even Worse
There’s at least 5 additional problems which worsen the situation.
Even the basic math we started with: 10⁶=1,000,000 isn’t quite applicable. If we assume peers form mostly random connections without a central authority to plan routes, then there’s a certain probability of success. A one-in-a-million chance, repeated a million times, only produces a 63% success rate. Choosing 2 million times improves this to 84%, which would mean increasing the number of channels.³
As users spend their income, available routes degrade, until the time that more funds are deposited. In other words, when a person receives a salary payment and deposits funds in the network, their channels are at a maximum, with full routing power. But as their money is spent, this power drops toward zero. Averaged out, this pattern cuts the routing power by about half, requiring double the number of channels.
Routing funds for others disrupts an otherwise even distribution of funds, which also diminishes the number of usable channels.
There is a large wealth disparity in any population. Therefore, the number of users that can route funds for any other random user is only a fraction of the network. And this problem is magnified exponentially with an increasing number of hops.
There always exists a risk of a routing channel becoming unresponsive (either intentionally or unintentionally). This risk also grows exponentially with an increasing number of hops.
The “TLDR” Summary
To reach anyone in a big network with a series of branching channel connections, you either need a large number of channels, or a large number of hops.
Both are a huge problem. A large number of channels means users have to divide up their funds and can’t do anything except tiny purchases. And a large number of hops means everyone’s money will be tied up routing everybody else’s money.
Conclusion: A Completely Unworkable System
As the network reaches a million users, it seems there will be no realistic way to avoid these problems. Dividing funds into many channels and continually loaning out money both make the network unusable.
The only conceivable visions are either A) everyone deposits MUCH much more than they need to transact with, or B) the system depends on large centralized hubs.
Neither is a decentralized scaling solution, or even a major part of one.
PART III: INFORMAL MATHEMATICAL PROOF

1. Assumptions
   Modeling a theoretical network that does not actually exist, of a large group of diverse people, is obviously impossible to do precisely. We acknowledge making a number of assumptions, some stated, some implicit, and some generous to critics of this proof.
   Within this context, we aim to demonstrate, through probability calculations, that a large number of open payment channels will be required for each user, thus making the system essentially inoperable at a size of 1,000,000 users.
2. Channels and Hops Required, with No Constraints
   Modeling the network as a complex graph of 1,000,000 nodes, we shall examine the probability of reaching a random peer given a certain number of open channels, C, and allowing for a certain number of hops, H.
   From the perspective of a user, reaching distant peers through a series of branching channels is similar to tree structure.⁴ The number of leafs grow exponentially and are possible transaction destinations.
   To simplify the calculations, we will ignore the possibility that a branch on the tree could link to another branch already on the tree (such as an ancestor or cousin).
   This possibility happening would reduce the number of peers found from a purely exponential branching to a slightly lower number. Since we are attempting to prove that a relatively low number of peers would be reached without a large number of channels or hops, and the real number would be even lower, this is a generous assumption (strengthening the proof).
   Let n be the number of leafs, defined as C^H. For example, 10 open channels and 6 hops is 10⁶ = 1,000,000.
   The probability P for failing to choosing a member of a set |N| with cardinality n by sampling n times, with replacement is:

(In our case, obtaining a desired destination by matching to a leaf.)
We can generalize this with the limiting form:

Since 1/e = 0.3678… then the probability of choosing correctly at least once is (1- (1/e)) = 63.21…%
Having access to any given peer at a rate of only 63.21% is too low to be considered successful for a payment system.
Using a different number of trials can be expressed as:

For example:

By taking various exponents of e, we can calculate the corresponding probabilities:

Using a value of 1,000,000 users and the limiting form, we derive the formula:

Using this formula, we can calculate some initial values reaching at least the 80% probability level; however this is not considering other factors not yet discussed:

1

1. Channels and Hops Required, with a Basic Money Constraint
   All hops along the route must have sufficient funds to process any payment they wish to service. This is the money constraint.
   Modeling a network of a million users with a wide variety of financial profiles and spending patterns isn’t possible to do precisely because there are too many unknown factors.
   However, we can make a very general common-sense assumption that many or most users will receive some kind of income at some kind of regular interval, and deposit an allowance of funds into the LN for spending.
   Deposited funds will generally be either spent or eventually withdrawn. (We will assume LN is not used as a savings vehicle)
   As users spend funds, payment channel availability for routing will degrade, either because a channel closes, or because the funded amount diminishes. When additional funds are deposited, the routing capabilities are revitalized.
   We do not have a detailed model of which and how many users are getting paid how much, when, and how often. However, we can aggregate the behavior of the set of users thanks to the law of large numbers, which states that “ the average of the results obtained from a large number of trials should be close to the expected value”.
   The typical consumer cycles consist of receiving income, spending it, and then repeating. We can generalize this behavior as a reverse sawtooth wave:

Visually, it appears as:

Salary payments are represented by spikes, and income is then spent gradually until the next payment.
Integrating the function gives half the value of the period, as expected:

This is also apparent visually as the waves form right triangles cutting out half the area.
The implication is that about half the channels that would be used for routing are invalid. Thus, the number of channels at each hop needs to be doubled.
Our probability formula changes to:

And our table of results becomes:

There is also a huge generous assumption we are making, which is that all users are a useful part of set of routing participants for all other users. In reality, a vastly uneven distribution of wealth would likely put additional and significant constraints on the system.

1. Additional Constraint of Lending
   In addition to the burdens of dividing funds and finding routes, we assume that the user also participates in the network by helping others route payments.
   This disrupts the user in two ways.
   First, it may cause the distribution of the user’s personal funds to become unbalanced, diminishing the number of routes available. Over time, this could theoretically average out with money flowing in either direction of any given channel. However, each user would be subject to a large degree of variance at any given time.
   The second is that the money used in routing others’ payments is unavailable to the user during the time that the route is in use.
   We shall generously ignore the first cause of disruption and only attempt to model the second. We’ll take the simplistic approach of assuming all users have the same average number of transactions and spending volume, and assume each user participates equally in the routing.
   Let us define the following variables:
   U: the number of users
   H: the number of hops
   V: the total network transaction volume during a period of time
   v: the transaction volume per user during a period of time
   r: the total routed volume per user during a period of time
   D: the duration in hours of a time period of measurement
   t: average number of transactions per user for time period D
   d: the duration in hours of the average route
   Since each hop needs to route the entire transaction amount for any transaction in a route that it participates in, the total routed volume for the entire network during a period of time = VH.
   Thus, r= VH/U. And since V/U=v, r=Hv.
   For example, if v=$1000, the plot appears as:

Let us introduce the concept of dollar-hours to measure routing capacity.
Each user can only spend their own money once, of course. But for purposes of routing others’ money, we can think of dollar-hours as the total dollars in their channels, multiplied by the number of hours they available. For example, $1000 sitting unmoved for a week is 168,000 dollar-hours.
We can then calculate a quotient Q, which represents the percentage of available capacity remaining after routing for others:
Q = 1- (d(H-1))/D
Note that v and t do not appear in the equation as they are factored out, but they are implicit in the ratio d/D. The reason for H-1 is that one hop doesn’t cost the network anything beyond a user’s own transactions (r=Hv).
For example, if the network uses 4 hops, and routes require 4 hours, and the user’s balances for routing are based on 168 hours (1 week), then:
Q=1- ((4)*(3))/168 ) = 0.92
Our probability formula is now:

Assuming D=168, and routing time d = 4 hours, we arrive at the following probabilities:

1. Determining Transaction Limitations Based on a Pareto Distribution
   It hardly seems necessary to prove that if funds need to be split into small buckets, there would be an enormous negative effect on usability. However, for completeness, we included this section.
   We assume most consumer and business spending follows a Pareto distribution in that each user makes a relatively small number of large transactions, several medium-sized transactions, and a larger amount of smaller transactions.
   The Pareto probability density function is expressed as:

For the simplest type 1 Pareto curve, this simplifies to:

The distribution does not change by applying constants, but we can better envision the model with some real world values by multiplying the y-values by 1000, so that dollar amounts for big items become substantial, and integrate over a typical set of x values (number of transactions at each dollar value), say 50.

The total sum of transactions = $980. Using a 10% value of $98,
we can solve the equation: 98 = 1000/x² to obtain 3.194 transactions.
Next, we will integrate over the smaller set of transactions to obtain the sum value of the transactions that have amounts that less than the our minimum $98 value:

Since 293.48/980=.299, we can say that only 29.9% of all desired economic activity would be possible if 10 channels were used.
Final Thoughts
I expect critics to nitpick. I encourage you to do your own critical thinking. Do not forget the generous assumptions we have made to ignore wealth disparity.
Remember, Bitcoin must be decentralized. Be wary of the rationalization of “Centralization is ok as long as the base layer is kept decentralized.” That is an insidious trap which allows forcing users off the base layer and into the centralized systems. We must never allow that.
So, is Bitcoin in trouble because second layer solutions may not work? No, not at all. Bitcoin was designed to scale on-chain with simple blocksize increases. It can and will do so, if we allow it.
Addendum
I published a short follow-up addressing some misunderstandings and objections.
Footnotes
Not a new type of address. Simply, a multi-signature address for the purposes of the channel.
Originally published by Carl S. Sterner in ‘Resilience and Decentralization’.
There are additional probability considerations as discussed in part III.
Technically a complex graph, not a tree structure, although the tree is an appropriate mental construct. We could have used more sophisticated graph theory calculations (perhaps the degree sum formula or a related formula) to arrive at a more precise number of nodes reached given D degrees and E edges, of but decided it was unnecessary because the maximum number of nodes is used, which is a generous assumption.