I have just read Jonald Fyookball's article which claims to provide mathematical proof that the Lightning Network will fail to provide a 'Decentralized Bitcoin Scaling Solution'.

It starts with a short description of single hop and multihop payments. After that it asserts that it will be infeasible to scale such a network topology to a any significant size.

Before exploring the details, the author already knows what the topology of the Lightning Network will look like (image from the article):

Let's ignore for a moment the obvious grievance of evidence being circularly derived from preconceived conclusions instead of observations and evidence.

The author correctly recognizes that using LN for a single payment would be pointless as a direct on-chain payment would be more efficient. Next, they present a model of what they think potential routes would look like from the viewpoint of a user (image from the article):

The author muses that "probably only one of these channels will reach the intended recipient at any given time". This crucial assumption is not further corroborated, and doesn't make any sense. Simply, the presented tree model is not an accurate representation:
When a LN participant searches for a route, they're obviously only interested in directed payment capacity. This aspect is correctly represented in the tree. However, the nodes along the route are interconnected. While this could even allow cycles to occur, cycles are not possible in the route construction, as it would allow participants involved multiple times to cut out the cycle when learning the secret for the first time. The resulting graph is what we call a DAG or directed acyclic graph:

Directed acyclic graph [image from wikipedia]

The interesting takeaway is that the assumption of only one route is far-fetched: once a connection is found, any part of the route can be exchanged for a parallel path, allowing for a multitude of possible combinations.

Misrepresentation of payment forwarding as 'Lending'

Assumptions about Routing

  1. Random searching of the graph has a low success rate
    This point is likely related to the deficient route model, however, it is trivial to do better than randomly searching the graph. An early approach suggested by Rusty Russel for example prescribes each peer learning their local topology. If and when the network grows too large for this, it could be overarched with a landmark approach. The suggestion of randomly generating and trying routes is laughably inefficient and thus can't be taken serious as a limiting factor for the network.
  2. Channels are exclusively used in one direction
    Firstly, by channels being part of various routing attempts in different directions, it is not obvious that channels will not rebalance themselves more frequently, and even if it were true, doubling the channels would not be a solution. Besides, it could for example be feasible to combine onchain payments with a "Lightning Network refund" for more frequent rebalancing of payment channels, in fact, this could relieve users of creating change outputs.
  3. Routing for others unbalances channels and decreases usable channels.
    Again, since channels are bidirectional and we're not in a tree graph but an interconnected graph, it may actually be possible that e.g. A→B→C→D and A→C→B→D both exist, thus even two subsequent payments from A to D may rebalance the channel between B and C.
  4. Wealth disparity limits number of routes that can forward payments.
    Obviously channels can only forward to the limit of their own capacity. In conclusion a route can only transfer the capacity of the weakest link. This is in particular why Lightning Network has been described as a scalability solution for micropayments and low-value payments. As low-value payments are least competitive on-chain but more frequent, this is in fact a great proposition. Larger payments are more economical on-chain anyway as the fees will represent a smaller relative portion of the transferred value. It seems obvious, that Lightning Network payment requests would soon be extended to allow payments to be split over multiple routes to mitigate the capacity limitations.
  5. "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."
    As there are many routes from each node to each other node, the network is self-mending. The channel partner of the offline party can choose to terminate the channel and after conclusion thereof put the funds into another channel that is more reliable. If a peer goes offline while participating in a multihop payment, either the payment fails, or the offline participant will only collect their payment with a delay. Participants with low uptimes will likely be peered less with and have smaller channel capacities. They will also likely not be heavy participants in the payment network anyway.

As the model on which Fyookball is basing their calculations is already far-fetched, I will not bother addressing the math.

Note: I’ve updated “atomically trades” (from Greek atomos: inseparable, undivided) to read “inextricably trades” as there were questions about that, fixed a grammar error.



Account inactive. New articles appear on my blog: https://murch.one

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store