Lightning Network: Don’t Buy Into the FUD

Lately, while discussing Breez with different people, I’ve been receiving repeated arguments against implementing Lightning Network as a solution for fast bitcoin transactions. I want to share these arguments and provide my 2 cents in an attempt to broaden the discussion (if you’re not familiar with Lightning Network, I suggest you read this first):

Argument #1: Lightning Network is a centralized solution

This is the argument: “A working Lightning Network topology can only be achieved using central hubs, or super nodes that will act like banks. These nodes will control the network and take away the censorship resistance of Bitcoin”.

In his article, Mathematical Proof That the Lightning Network Cannot Be a Decentralized Bitcoin Scaling Solution, Jonald Fyookball presents the following image:

Jonald claims to prove that a distributed network, as represented on the right, cannot be achieved. But even his “math” doesn’t discredit the validity of a decentralized network with hubs.

Hubs, or routing nodes, will have to emerge in order to facilitate the connectivity of large number of individuals in Lightning Network. However, like any proper decentralized system, users will have a freedom of choice and would be able to connect to different routing nodes. As Lightning Network grows, different entities would provide this type of routing service for a competitive transaction fee. Unlike ISPs (that have to reside in close proximity to users) or banks (that are bound by regulatory requirements and restrictions), there is no limit to the potential number of these routing service providers in Lightning Network. Censorship resistance then becomes a quality of service issue. A provider that won’t work or behave properly will simply lose its customers. BTW, technically, in LN, only one hop is known to a node involved in a transaction, so IMHO, this is not a serious argument.

In any case, the fact that LN facilitates peer-to-peer connections also mitigates the power of these hubs, and will most likely evolve to a six degrees of separation network.

Argument #2: Lightning network will be too slow to grow

In a comment to my article Lightning Network is the Future of Bitcoin, Gurinder Bhangoo said: “It takes a transaction on the Blockchain to open a LN payment channel. With 7 billion people in the world, it would take 32 years for everyone to open a node. How would this be a practical solution?”. This is a good question, but pretty argumentative.

Nevertheless, the answer is straightforward: with SegWit integration, one block will conservatively support 11 transactions per second. In addition, let’s assume that in 5 years, with the same cost of goods, storage capacity and bandwidth will double (again, a very conservative assumption). In this case, there would be no objections to increase the block size proportionally.

Even without taking into account additional technical optimizations (like schnorr signature), it means that every individual in the world will have access to Lightning Network in less than 10 years. This is more than reasonable timeline for worldwide adoption of new technology.

Argument #3: Lightning network is too complex for the average Joe to use

There are different nuances to this argument, but here’s the gist of it: “Lightning Network adds complexity, like payment channels, to the bitcoin protocol. This complexity will burden LN users, that will not know how to handle it”.

I agree that it’s still early for a noob to try and use LN. This is simply where we at right now, as the ecosystem is more focused on building a stable infrastructure. However, if you’re watching closely, you’ll see an increased focus on user experience in the LN community.

This is what we are trying to accomplish at Breez: to make LN accessible for non-techy users. Providing a great user experience for LN is feasible and can be achieved in the near future using existing infrastructure. These efforts will continue, no doubt, as the network matures.

If you find this article helpful, please don’t forget to add claps (long press to add multiple claps) and share it.