The Lightning Network: Bitcoin’s Future or a Failure In The Making?

The Comprehensive, Non-techies’ Guide To The Lightning Network

Published in

BlockVera

26 min readMay 7, 2019

Try to read blockchain news without coming across references to the Lightning Network (LN). Crypto Twitter and Reddit are on fire with discussions about the Bitcoin scaling solution, and rightfully so! The network has exploded in recent months and actual products are being purchased with the help of Lightning. Browse casually and it may seem like Lightning is the solution to all our scalability problems — Bitcoin’s long-awaited Messiah. If only things were so simple.

Today, the debate over the future (and effectiveness) of the LN rages stronger than ever. It transcends to a much larger disagreement: that over the future of Bitcoin. It is a debate that has polarized communities, caused contentious hard forks, and made the Brexit debate look like a friendly disagreement.

You might want to skip it altogether. Let the devs fight it out and then jump in when the answer is there. But that’s not how this works. Whether you’re a casual investor, an idealistic libertarian, or a utilitarian waiting to spend crypto at supermarkets, understanding this debate is critical. It matters because it could define which Bitcoin, or even which protocols, are around in 10 years; it will determine how far we go in the pursuit of efficiency and how much decentralization we’re willing to sacrifice.

The Great Debate

It boils down to this: Bitcoin v. forks of Bitcoin (i.e. Bitcoin Cash). The Lightning Network debate is so contentious because those who believe in Bitcoin (rather than one of its forks) have a lot staked on the success of the LN and other Layer 2 solutions.

First, a brief overview of what we mean by Layer 2. Layer 2 solutions are scaling efforts built ON TOP of Bitcoin’s protocol that do not directly impact its core layer. This is an important differentiation to understand.

Layer 1: Built into the core Bitcoin protocol. Examples of this would be SegWit, a block size increase, or a change to the block times; or sharding on the Ethereum network.
Layer 2: these solutions are built on top of the BTC protocol as a second layer. The Lightning Network is an example of a Layer 2 solution for BTC. Plasma is an example of a Layer 2 solution for Ethereum.

We can understand this further by visualizing a city. Layer 1 changes would affect the set of rules on which the city is run — raise taxes, cut school funding, change zoning laws. Layer 2 changes would simply add features that work within the already existing rules — expand the public transportation system, build more apartment buildings, plant more city parks. Generally, Layer 1 rules (depending on the type of fork) MUST be followed by everyone, while Layer 2 updates simply provide an additional option that people can voluntarily use.

Current efforts to scale the protocol of Bitcoin through Layer 1 solutions (such as raising the block size) have proven contentious and unsuccessful. If Layer 2 solutions fail, it’s likely the BTC community would have to accept the necessity of raising the block limit. This is what proponents of Bitcoin Cash (or other BTC forks) hope for. These critics have already accepted that raising the block limit is something that must be done. Bitcoin Cash has an 32MB block limit in comparison to the 1MB block utilized by BTC. Bitcoin Cash would benefit from a failed LN, as it would likely force Bitcoin supporters towards Bitcoin Cash (or other tokens), a victory for those coins fighting for the BTC title.

You can even see this fact represented by the popularity of a preliminary thread I submitted to Reddit in the process of compiling this article. r/BTC is largely dominated by Bitcoin Cash supporters while r/Bitcoin features Bitcoin originalists. Obviously, r/BTC was much more receptive to my critiques of the LN.

This debate deserves further articles in the future, but for now, we’ll move onto our investigation of the Lightning Network. As a side note, I’m sure that I’ll receive flack for this article. Claims of ulterior motives or malicious intent will surely be propagated. Before continuing, I will say that I am only in pursuit of truth. I entered this research with little definitive opinion on the future of the Lightning Network. I read everything I could find. My conclusions represent the most balanced perspective I could achieve.

TLDR: Lighting Network is a Layer 2 solution, meaning it doesn’t affect Bitcoin’s core protocol. The debate over the future of the Lightning Network is indicative of a much larger debate currently raging over the future of Bitcoin.

A simple overview of how the Lightning Network works

Now that we have some context, let’s understand how the Lightning Network works and why it was created.

Unless you’re new to the scene, you know that Bitcoin isn’t particularly scalable. Fees during the last bull run broke $50 per transaction (!!!) and only several weeks ago, fees broke $2 for the first time since June of 2018. These extremely high fees are a result of the limited speed and size of Bitcoin blocks and the enormous computational power that goes into confirming and securing the network.

Two approaches to scaling currently exist. Some solutions focus on Layer 1 solutions, upgrading the core Bitcoin protocol and increasing the blocksize. This is the debate that resulted in the contentious Bitcoin Cash hard fork. Others suggest we tackle the problem through Layer 2 solutions. They propose that by moving transactions “off-chain,” we can reduce the load on the core Bitcoin network. Off-chain solutions might not be as secure as on-chain ones, but the idea is that off-chain transactions could handle transactions that are willing to compromise on security for efficiency. The transactions could be executed off-chain and moved on-chain in “batches” for eventual confirmation.

It’s not unlike running a tab at your local bar. Instead of pulling out your wallet everytime that you pay, you simply keep track of all the drinks you’ve bought and settle up at the end of the night. Assuming that you’re not racking up huge bills and that the bar reasonably trusts you. This is a win-win, especially when you consider that unlike with Visa, when it comes to crypto, minimizing transactions minimizes fees. This is because credit cards charge a percentage of the whole transaction amount whereas crypto transactions cost a flat rate. Generally, with crypto whether you’re spending $1 or $10,000, the Bitcoin fee will be the same. However, this does ignore the fact that higher value transactions can have more inputs and thus, more fees.

Layer 2 solutions are also faster. By executing transactions off-chain, customers don’t need to wait hours for confirmation like they might with on-chain Bitcoin transactions. Now you can get that beer immediately.

I will note here that the reality is a bit more technically complex than this. Off-chain transactions don’t really exist — it’s more accurate to say that the transactions are onchain transactions that are cached without being broadcasted to the network. But for simplicity’s sake we’ll use the term off-chain.

This is how the Lightning Network works. People can open up “payment channels” off-chain where they can exchange funds back and forth. After a certain time period, the sum of all the transactions is settled and transferred back to the mainchain where is it confirmed as a normal transaction by the miners.

In other words, imagine John owns a bar and you own a grocery store. You purchase beer from John throughout the month and John purchases milk from you. Instead of doing many individual transactions, you could just keep track of how much milk and how much beer you each buy. Then, at the end of the month, whoever owes the other money, “settles up.” Payment channels have the added advantage that either party at any time can claim their money.

TLDR: The Lightning Network (LN) is a Layer 2 solution that offers several distinct advantages:

Fees are greatly reduced.
Time spent waiting for transactions is greatly reduced.

The LN works by allowing people to open up “payment channels” directly with each other. They can transact as much as they want in that channel before transferring the final amounts to be confirmed on-chain.

History (skip if you don’t care!)

The Lightning Network was conceptualized early on in the Bitcoin timeline. Initial suggestions for payment channels were even proposed by Satoshi Nakamoto in 2009. Additional theoretical developments in 2011 and again in 2013 expanded the potential of the LN. However, critical questions remained (you can read a more in-depth history here). In 2015, the breakthrough happened. Thaddeus Dryja and Joseph Poon published an LN whitepaper.

In 2015, the Bitcoin dev company — Blockstream — began to develop an actual implementation of the network. Their implementation is called “c-lightning.” Other companies soon began development as well. ACINQ began development of “eclair” and Lightning Labs created “Ind.” Each worked on an LN implementation in a different programming language. A protocol known as BOLT was brought forth that would enable interoperability between the various developments. We use this protocol today.

By January 2017, the first real implementation was brought forth; by summer, the first LN transaction was broadcasted. Subsequently, applications were built on top of the LN and more users flocked to the network. As of recently, the LN has grown substantially and quickly. The network surpassed the $5 million threshold and the network’s node count has doubled since the beginning of 2019. This can largely be attributed to the release of out-of-the-box nodes that are easy to set up and use by non-technical people.

So today the LN is largely operational. Real money is being transacted, the user count grows daily, and actual goods are being purchased over the LN. So what’s the problem?

TLDR: Various implementations of the LN have been developed by independent dev companies. Currently, three implementations exist:

Eclair developed by ACINQ
Ind developed by Lightning Labs
C-lightning developed by Blockstream
Ptarmigan developed by Nayuta

The BOLT protocol supports interoperability between them. Since the beginning of the year, we’ve seen explosive growth of the Lightning Network. There are three other LN implementations, but they are not yet BOLT compatible.

The Nuts and Bolts

The Lightning Network is built on the concept of “payment channels” as I described above (with the bar tab example). Two users submit an on-chain transaction (to the Bitcoin mainchain), opening up an LN channel between themselves. When a channel is opened, the channel must be funded by the party and only those funds can be used to transact. In other words, if I open up a channel and we put 1 BTC in the channel, we can only transact with 1 BTC. Once funded, the parties can transact as much as they want until at least one party decides to close the channel and withdraw their money. This process closes the channel and submits another transaction to the mainchain.

Interacting with the LN can be done with either an LN-compatible wallet or with a full node.

Once we understand the above basics, several questions arise that highlight the complexity of the network (and ultimately, some of its problems):

How do you send money to a person who you don’t have a direct channel with?

The real potential for LN arises when we can expand beyond simple, two-party payment channels. Unless you’re transacting frequently with that individual, it doesn’t make sense to use the LN. If you were to send a single payment through Lightning, it would take TWO on-chain transactions (one to open the channel and one to close the channel) instead of just one transaction if you were to have used the main network instead of the LN. That means that two possibilities exist:

Lightning Network’s use cases remain highly niche, only applicable to people who transact frequently with the same individuals.
OR, the network supports the ability to transact with people outside of your direct channels, enabling a whole web of fast, convenient payments.

Option 2 is possible. The way it works is through a series of hops and hash-locks (not a beer and weed reference). If you have a channel with someone who has a channel with the person you want to send money to, you can essentially “route” money forward through the two channels. However, it’s not possible to directly send money through the two channels. Instead, you “loan” money to the middle man who then sends money from his/her pool. Remember how we said that channels must be pre-funded? That means that no matter how much money you have in my channel, you’re limited by the amount of money present in the other channels you’re routing through.

Example:

Let’s take a concrete example. Imagine that we can only spend cash and that it must be passed hand-to-hand to the recipient. Now I could walk up to any individual and hand them cash, but just like seeking out that individual in real life would be cumbersome, finding the direct recipient on the network and opening up a channel with them is problematic. So instead, I can rely on my friends to help me out. It would be great if I could just hand money to one friend who would then hand that same money to their friend and so on until it reached the destination. But that’s not how the LN works. My friend cannot take my cash and give it to someone else. What they can do is accept my cash as collateral, and then give some of their own cash to the next recipient. But if I want to transfer $100 and my friend only has $50 of his own cash, I can only transfer $50. This is why you are limited by the minimum amount of money in a channel anywhere on your route.

These hops as they are called (when I transfer through other channels) are protected by hash-locks. It’s technical and you can find much more technical descriptions of this system, but essentially, through a series of locks combined with cryptographic hashing, the moment someone further down the line accepts the money, it unlocks the money in the previous channels. That way, no one can steal money along the way to the destination.

So the question then becomes, how do I know which friend I should give my money to in order to reach my destination? Conceivably, if the Lightning Network reached enormous sizes, it shouldn’t really matter. In the real world, we’re all separated by about 6 degrees of separation anyway. But it’s important that we minimize the number of transfers. This is because of the fees. Generally, people along the route take small fees in order to route the money. It’s like if I was to do you a favor by taking your cash and passing it along to the next guy or girl. I might keep a buck or two for my troubles. The same happens on the LN. So it’s important that the fewest people possible are involved.

Lightning Network Maps

This is made possible by maintaining a “network map.” We can track who is connected to whom and the wallet can identify the best route to reach the destination. Each full node must store the network map; the concern is that as the network expands, so will the size of the map. IND already raised the graph limit from 4MB to 50MB — a minor increase, yes, but it highlights the fact that as more users onboard, the size of the graph will increase. We’ll discuss some of the potential problems of this further down.

TLDR: Payments on the LN can be sent to people without the sender having a direct channel with them. Payments can be “routed” through other channels until they reach the destination. A series of “hash-locks” ensures that no one can steal money along the way. A network graph is maintained by nodes so that they can determine the best routing path.

How do you close a channel?

Let’s say you have opened a channel, funded it, used it, and now you want to close it. Three possibilities exist depending on how your counterparty reacts.

Option 1: The Best Case Scenario

If your counterparty agrees to close the channel and there is no dispute as to the final state (the final balance) in the channel, then the channel closes. This is known as a collaborative close. This happens very quickly and cheaply.

Option 2: An Unresponsive Second Party

This happens if the counterparty isn’t online or doesn’t respond to the request. The channel can still be closed, but the process is more cumbersome and expensive. Essentially, a dispute is opened, and the final channel state is published. If the final published state is legitimate, then the funds will be distributed. However, the parties must still wait the length of a dispute period — see below.

Option 3: The Worst Case Scenario

Let’s imagine that one of the parties decides to try to cheat the other by publishing an old channel state. That’s why we have the dispute period. The counterparty has the dispute period to object to the final state. If an old state is published, the counterparty would recognize the malicious intent of their adversary and would publish the “true” state. As a penalty, the malicious actor would lose ALL of their money in the channel, even the money to which they were previously entitled.

TLDR: Channel closures can happen in a few ways. Let’s take the bar tab as an example. After drinking at the bar, you go to settle up with the bartender. If the bartender is at the bar and the check is accurate, then you just pay and leave (option 1). Simple!

But let’s say the bartender is not there. In this scenario, you would leave money on the counter and walk away. After a period of time, if the transaction wasn’t disputed, the tab would be closed (option 2).

Next, imagine that you, or the bartender, tried to use an illegitimate bill. Maybe you tried to use the bill from two hours ago before your fourth margarita. Or maybe they tried to charge you full price for those happy hour drinks. At this point, the honest party would publish the true bill (truth is easier to demonstrate with cryptography than in a bar). If they tried to cheat you, you would get all your drinks for free (option 3).

A few other considerations

One problem with this system is that it requires that LN users keep their wallets online. With lots of users offline, it makes the system more expensive and cumbersome since “close channel” commands would automatically go to “Option 2” and would cost more and take longer. It’s also necessary to keep your wallet online so that you can ensure that no one cheats you by publishing old states. If you went offline for too long and someone tried to cheat you, you would have to come back online before the end of the dispute period. If you don’t, you’re shit out of luck.

But Wait, there’s More! — Watchtowers

The need to keep wallets online is a known problem and solutions are under development. Enter Watchtowers. Watchtowers are essentially third-party services that watch the network, tracking current states, and checking that published “final states” match the legitimate state. Essentially, watchtowers could “cover” for you if you’re offline during a channel closure.

But as with all potential solutions, this isn’t perfect. First, it relies on third parties for a system that shouldn’t need them (shouldn’t is relative, I realize). Fees would need to be introduced to support the overhead costs of operating a watchtower (and to incentivize people to provide the service). It would be important that the fees be structured in a way that aligned incentives.

Second, what would happen if an old state was published but it wasn’t malicious, just simply a mistake? Losing all the channel funds would be a severe penalty for such a mistake. Solutions such as Eltoo are attempting to solve this. Eltoo would essentially automate the process of invalidating old channel states so that only one final state would be valid. Eltoo would serve as a type of trustless watchtower. However, for Eltoo to work, it would require an update of the Bitcoin core protocol, a problem which we will explore further down.

A final concern with regards to watchtowers is the potential for them to collude and monitor the LN. This could seriously violate the privacy of the network and its users. People could mitigate these risks by connecting to multiple watchtowers. However, I think it’s unlikely that users would do this, especially given the additional fees and operations it would entail.

TLDR for watchtowers: Watchtowers monitor the network so that you don’t have to. Instead of needing to keep your wallet online all the time, watchtowers are service providers that watch the network and ensure that no illegitimate states are published. However, several concerns arise in regards to privacy and the need for middlemen.

Will the Lightning Network Work?

This is a weighted question. It also depends on what the goal of the LN is. Is the goal to have a network that facilitates micropayments? Is the goal to create a global transaction layer, built on top of Bitcoin? Let’s approach this question by understanding the current (and anticipated) limitations of the Lightning Network.

It’s also important to understand that the network is very much in development. I will discuss those efforts further below.

The biggest question facing the LN is how the network topology will evolve. Either it will evolve to be a hub-and-spoke network, it will evolve to be a mesh network, or it will evolve to be some kind of combination of the two. A hub and spoke structure would centralize routing through large nodes, while a mesh network would be a more decentralized solution, routing transactions through a series of interconnected nodes.

Hub-and-spoke to the left. Mesh to the right.

The Hub-and-Spoke Argument

This argument points to several strong pieces of evidence in support of the eventual creation of a hub and spoke network. The first is that concerns over the growing size of the “network map” could be a strong motivator. A large network map could make it unrealistic for small nodes to operate; instead, the map would have to be maintained by several central providers.

Second, because the network is limited by the lowest channel sums (remember how we discussed that above?), it would make sense that large “hubs” with a large amount of capital would create the most efficient network. A series of connected hubs would allow for large network liquidity.

Jonald Fyookball highlights some of the arguments in this comprehensive article. Primarily, he discusses how the channel limitations restrict the effectiveness of the Lightning Network — these have been summarized above.

The Counterargument

A hub-and-spoke structure is by no means inevitable. First, storing large amounts of money in a lightning channel is unrealistic even for large providers. The LN wallets are all hot wallets — and necessarily so — making them security weak points. This would likely dissuade nodes from holding large amounts of money and distribute power to some extent.

Additionally, it’s possible that the network graph could be distributed into chunks so that nodes wouldn’t need to store the whole network, but rather only the portion of the network that they would need. We could potentially see a system where the network is interconnected enough to not need large central providers. This would result in a mesh network.

Realistically, the network will not be very effective for large payments; but it also likely doesn’t need to be. Because the Bitcoin mainnet has flat fees, the more money you’re sending via the BTC mainnet, the more efficient it becomes. A million dollar BTC transaction will have the same fees as a hundred dollar transaction. As such, Lightning is more of a solution for micropayments or frequent payments. Large payments could still be sent over Bitcoin’s mainnet.

I’d also like to reference StopAndDecrypt’s article. He highlights a strong point. The reality is that even if there is a centralization of nodes, there is a big difference in the centralization of services and the centralization of resources. On the LN, anyone will be able to set up nodes and route payments. There will likely be a strong incentive to do so, especially in the periphery of the network where centralized hubs will find it harder to reach. Because there isn’t any censorship on the network, the barrier to entry will always be low and a monopoly of centralized nodes is very unlikely. This means that even if a hub and spoke model does emerge, its power will be reduced as other users can open up additional routing paths.

The reality is that we can also look at what form the topology has taken today. We are currently seeing a good distribution of nodes. The question is whether this will continue as the network expands.

Why is a hub-and-spoke system bad?

There are two reasons why we want to avoid a hub-and-spoke system. First, the system would be very vulnerable to targeted attacks. It would, however, be very robust against random outages because the network could simply route through other hubs until the downed hubs came back online. But if an adversary could target, say, the top 10 hubs, this could severely cripple the network. For example, in March of 2018, a DDoS attack brought down 20% of nodes. The problem with this kind of attack is that it would fracture the network into numerous parts. This fragmentation would make routing far more difficult and expensive (or impossible in the worst case scenario). This paper highlights this argument in further depth.

Additionally, a hub-and-spoke model looks very similar to our current banking world. Hubs could hold significant power over their clients and essentially serve as “custodians.” This is, however, less of a concern if people can freely and easily switch hubs.

What about high BTC fees?

The dangers of a hub-and-spoke model grow exponentially when we consider that high mainnet BTC fees do in fact impact the LN. Here’s why:

Because closing a channel requires an on-chain transaction, high fees equate to a high cost for closing channels. Peter R. Rizun highlighted this brilliantly in this article. This becomes a problem only when a user must exit a channel because of malicious activity. If the amount in the channel is smaller (or close to) than the cost of the on-chain transaction, they would essentially lose all their money in the channel. In addition, high fees would make it impractical for users to move from one hub to another.

This gives significant power to hubs. By simply not responding to close channel requests, they could hold users’ funds hostage. They could require KYC/AML information in order for users to “unlock” their funds.

This leads us to our next point: LN isn’t a solution for an unscaled BTC network. High fees will lead to dangerous consequences on the LN as demonstrated above.

We can also see the potential for a “bank-run” on the LN. Credit to this Reddit user. If everyone decided to withdraw their funds from channels at the same time (or within a short period), the mainnet would be flooded by new transactions. At first glance, this doesn’t seem like an issue. The transactions would simply accumulate and eventually be confirmed (not unlike when BTC today is flooded with transactions). The issue arises in regards to dispute resolution. If challenging an invalid state (remember our bar example), requires publishing the actual state to the mainnet (i.e. another tx that must be confirmed), then if the network is backlogged severely, the actual state may not be confirmed in time. Remember that dispute resolution depends on the “legitimate state” being published within a specific time period. The thief would have successfully published an old state and stolen money. Now you could argue that this is extremely unlikely. But imagine that dramatic crypto crashes created a massive run of people exiting crypto. This could cause enormous pressure on the LN and potentially result in the situation described above.

Even when we look at some of the LN upgrades on the roadmap — such as Eltoo — we see that it requires upgrading the core BTC protocol. The bottom line is that the LN isn’t a perfect solution for high BTC fees. It should, however, provide more flexibility for the network, allowing many more tx to get into the 1MB blocks. But it does not invalidate the necessity of creating a scalable core BTC layer.

TLDR: The future of the Lightning Network depends greatly upon the type of network topology that develops. A hub-and-spoke model would place significant power in the hands of “hubs.” However, there are reasons to think that the network will have various checks on the development of a pure hub-and-spoke topology.

Further Developments

Fortunately, devs are hard at work to find solutions to account for some of the above issues. Here are the main proposals and developments currently in the works.

Potential Solutions:

Splicing — splicing is essentially a method so that people can combine the “add money,” “close channel,” and “open channel” commands into a single on-chain transaction. Splicing could also support “piggybacking” where users could combine these transactions with the transactions of other users to save on transaction costs. Splicing could also allow users to refill or drain money into or from their channels. Bottomline: This is an interesting solution that has the potential to help mitigate some of the above-mentioned problems regarding rising on-chain fees.
AMP (Atomic Multiple Pathways) — AMP allows for a large payment to be split up and sent through multiple routes. AMP also ensures that if part of the payment fails along the way, the recipient either receives all or none of the payment (i.e. it is an atomic commit protocol). Bottomline: There are several issues with AMP. First, it doesn’t negate the danger of storing large amounts of funds in a hot wallet. Second, the larger the payment and the more it is divided amongst various routes, the more likely the transaction is to fail completely.

3. Submarine Swaps — Submarine swaps would use middlemen to route LN payments to real BTC addresses. In other words, you would be able to send LN money to the middleman who would then send BTC to an on-chain address. This would help to bridge the divide between on-chain money and money in LN channels. Bottomline: One concern with regards to the LN is that users must lock funds into channels. Submarine swaps would open up significant flexibility by allowing users to still spend those funds on the Bitcoin main-net.

4. Channel Factories — Channel Factories are essentially multiparty LN channels. Imagine a channel that uses multi-sig (encryption based on multiple parties) to support more than 2 individuals on the channel. They could then pool their money and transact as usual. Bottomline: Channel Factories are an interesting proposal. They could potentially reduce the dependence of on-chain transactions since exiting from a channel would be an internal operation (with the other channel members) instead of an on-chain transaction. Additionally, collaborative channels would help raise liquidity within the network.

5. Privacy Solutions: privacy solutions are an important component for a successful LN. Tor and Onion Routing are already available options for privacy. Tor obscures node IP addresses and onion routing obscures the recipient but still allows for the transaction to be routed.

2p-ECDSA: This solution would make use of elliptical curve cryptography to make LN transactions (on-chain) look like normal on-chain BTC transactions. Today, it is relatively easy to distinguish between those LN transactions occurring on-chain and those normal on-chain BTC transactions. Bottomline: It is likely that a combination of the above solutions will provide acceptable security for most use cases on the LN.

This is a (far too) brief overview of these technical solutions. However, this is not the place for me to dive deep into all of these potential developments. However, I felt it was important to at least provide an overview of those solutions in development.

Additional Info:

On a side note, it’s important to understand that the Lightning Network is not specific to Bitcoin. Other blockchains are working towards implementing their own LN variations (Ethereum’s is called Raiden). However, the scope of this article was to evaluate the LN in regards to Bitcoin.

Conclusion:

I think that the success of the Lightning Network very much depends on how we intend to use it. I am confident that it will provide a viable solution for microtransactions and for those parties that frequently transact. I am less confident that the network will evolve to serve as a global payment network without accepting large tradeoffs.

I think that the fundamental design of the network will lead to a hub-and-spoke model or some combination of a mesh and hub-and-spoke network. Users will always be incentivized to find the shortest possible routes to their payment destination. This means that there will be a strong incentive to use well-connected nodes (i.e. hubs). Additionally, easy-onboarding solutions that allow users to set up directly with hubs will continue to push people towards a hub-and-spoke model.

Further, I predict there will be a consistent migration towards centralized/middlemen solutions. Realistically, people will also rely on hubs to store network maps. I would imagine most users will use the LN from their mobile devices — downloading a network map to their mobile phone will be unrealistic. People will make use of watchtowers as well, entrusting their security (and possibly privacy) to these semi-middlemen.

Solutions in development such as splicing and channel factories will help reduce the LN’s dependence on the core Bitcoin throughput. But it will likely never fully remove the need for Bitcoin to be somewhat fee conscious and efficient. I think it’s likely that a block size increase will be inevitable — the LN doesn’t change that.

While the LN may end up being relatively centralized, I do think there is a place for that. Having a more traditional system in place on Bitcoin may not be all bad. It would certainly be more decentralized than our current financial system and it could provide a solid hybrid solution for those who would like to use BTC, but are unable now because of the scalability issues. Even if the network evolved into a hub-and-spoke system with watchtowers, the LN could still see adoption with millions of users — not necessarily a bad thing for Bitcoin. The question is whether Bitcoin can exist in its original sense if Layer 2 solutions make these sacrifices?

Long term though, I think we will encounter problems. Efficiency can already be achieved magnitudes greater with centralized solutions (Venmo, Paypal, PayBox). We cannot sacrifice too much on the fundamentals of decentralized technology for efficiency — otherwise, we might as well use current systems. To avoid these mistakes we must be highly cognizant of those tradeoffs we are making/proposing. This article hopefully served to provide a comprehensive overview of the Lightning Network and those important questions we should all be asking.

A big thanks to all those who have written or spoken about LN, many for no payment at all and only for the betterment of the community.

From Medium, give these folks some claps and a follow:

Murch, StopAndDecrypt, Jonald Fyookball, Sam Aiken, Chris Stewart, Peter R. Rizun

FOLLOW me on Twitter: @noamlevenson

I love getting questions or suggestions, so comment away! I do my best to respond to all thoughtful comments.

For the latest BlockVera updates, follow us on Twitter and join our Telegram Announcement Channel.

References

General Lightning Resources

https://nms.kcl.ac.uk/patrick.mccorry/SoKoffchain.pdf

History of the LN:

On Network Topology:

On Network Critiques:

On LN’s Dependence on Bitcoin Protocol Scalability

On Closing LN Channels

https://bitcoin.stackexchange.com/questions/80394/closing-a-channel-in-lightning-network

Network Robustness:

https://arxiv.org/pdf/1901.04972.pdf

On Watchtowers:

On Splicing:

On AMP:

On Channel Factories:

On Privacy:

On General LN scalability:

https://www.coindesk.com/state-of-lightning-whats-the-path-for-network-adoption-in-201