Bitcoin’s Scalability Issues

Over the years, there have been complaints about the slow processing time of transactions on Bitcoin.

Back when Satoshi Nakamoto laid out Bitcoin’s architecture, he failed to envision how detrimental the low throughput of his project would be. Small block size and confirmation times hanging around 10 minutes had been preventing Bitcoin from achieving mass adoption as there are many instant payment systems far more suitable for the daily needs of the general public.

The Lightning Network

In 2016, however, Joseph Poon and Thaddeus Dryja published a whitepaper in which they proposed a clever solution. The Lightning Network which has been under development ever since is an innovative approach to increase scalability and transaction speed of the network. Additionally, it was introduced to bring down the increasingly hefty fees involved in performing transactions on the blockchain. It is basically a second layer, existing outside of the main ledger and relieving the pressure on it by hosting transactions externally.

The Lightning network lets Bitcoin users continuously exchange payments without submitting each one of them into a block. In layman’s terms, the process could be broken down into the following steps:

Creating a channel

Channels are multisignature wallets in which users store certain deposits that they can spend from to pay the other party. Both sides need to sign the channel for it to open.

2. Sending or receiving coins

These two-way channels enable instant transactions between the users, as long as the amount being sent doesn’t exceed the sender’s remaining balance in the channel.

3. Broadcasting to the ledger

Users can close these channels at any time, which is done by submitting the final version of the channel to the main blockchain.

Driving lessons

For instance, let’s say John is taking driving lessons with Tim, an instructor.

Tim’s hourly rate is 0.008 ₿, but John is unsure how many hours he needs to practice for until he is certain that he will pass the driving exam.

So they establish a contract which John loads with 0.08 ₿ for good measure. In the blockchain this is equivalent to one transaction.

0.08 ₿___________________________0 ₿

On the first day John drives for 2 hours and thus pays Tim his 0.016 ₿.

0.064 ₿_______________________0.016 ₿

Next week John decides to take one hour longer and afterwards sends Tim 0.024 ₿ more.

0.04 ₿_________________________0.04 ₿

John concludes that he is ready for the exam, so he decides to close the channel. Ideally, both parties sign the close and the updated balances are sent from the temporary wallet to their addresses on the blockchain, but it may be done by a single user as well.

Security

Channels are secured by smart contracts, software that makes sure any malicious behavior leads to penalties for the offender. However, if the decision to close is unilateral, a dispute can be opened to investigate the situation. The network plays the role of an arbiter and easily detects any issues within the payment channel.

In our example, if Tim is offline or somehow can’t sign the close, John can take the matter in his own hands. Although he would have to wait for 1000 blocks to be validated before his funds are unlocked, while Tim’s would become available to him immediately.

At the same time, if John sends any state of the channel (or commitment transaction) other than the last to the blockchain, his entire deposit will go to Tim.

0 ₿___________________________0.08 ₿

Routing

At this point, you might be thinking that storing so many channels on the network would quickly render it unusable. To combat this, clients are able to use each other’s active connections and transfer funds indirectly, through the chain of channels that links them to the recipient.

Getting back to our example, let’s assume John’s coworker Mary is also taking driving lessons with Tim and the two share a channel, while both John and Mary are paid by their employer Hooly Inc through direct channels on the Lightning Network.

Now, provided that there is at least as many coins in the intermediaries’ loaded balance, John can pay for his driving lessons without creating a channel of his own.

JOHN → HOOLY → MARY → TIM

A Chink in the Armor

There are many implementations of this algorithm out there, so anyone can go ahead and with the right software proceed to safely use the Lightning Network in their daily life. But there’s a catch — it might not scale the way we would like it to.

After all, the routing mechanism described above is somewhat similar to the traveling salesman problem (TSP). It is a problem of finding the shortest distance from one town to another over a web of interconnected roads between other towns on the way. TPS was proven to be NP-hard, or for those not versed in math-speak, extremely difficult to solve, especially with a large number of towns.

Despite not being quite the same thing, routing in the Lightning Network is further complicated by the fact that nodes can go offline or close their channels at any moment. Without centralized infrastructure in place, this means that each user not only needs to find a route but has to do it quickly enough to not find themselves stuck in the network.

It is not all that grim, though. Hubs with a multitude of channels have already started popping up, and they can ease the tension created by the growing user base and redirect transactions for a small fee. Unfortunately, some centralization of the resources will be inevitable, but it won’t lead to a complete takeover as there are no barriers to entry and healthy competition is attainable.