The lightning network has been hailed as the solution to Bitcoin’s scaling woes and with the beta now being deployed by a variety of merchants accepting Bitcoin, a full scale production-ready roll out doesn’t seem far off. Depending on who you ask, Lightning is either the cure to scaling and a way to consolidate Bitcoin as the de facto dominant cryptocurrency or a recipe for disaster with severe security and usability pitfalls. As always the truth falls somewhere in the middle and some aspects of Lightning are far more nuanced that what is readily apparent.

Let’s explore the history of Lightning, what it tries to accomplish and how.

Lightning, what is it?

On a high level view, Lightning is a multi hop off-chain payment network designed to take some of the recurring transactions currently happening on chain and taking them off-chain. This is commonly referred to as a Layer 2 solution because it’s built on top of the Bitcoin software stack and to some degree relies on the bitcoin chain for security assumptions. It was initially described by Joseph Poon and Thaddeus Dryja in this whitepaper dated to 2015, but it’s only coming to fruition now after a longer than expected development cycle.

The Lightning Network relies on constructs called Payment Channels to function. Payment channels are off-chain communication channels established between two parties where they exchange cryptographically signed transactions structured similarly to traditional bitcoin transactions. If there are no disputes concerning these transactions, then they are committed on-chain – as you can imaginem this is a much more efficient way of transacting bitcoins than broadcasting every single transaction on-chain. These cryptographically signed attestations can be redeemed on the bitcoin chain by broadcasting the most recent Commitment Transaction.

This is where this simple payment channel architecture encounters its first roadblock. In the real world, people often need to send one time payments for one-off services or products. Due to the way payment channels function, in order to successfully establish a channel, two transactions are needed; one to open the channel and one to close it. Crucially, both are on-chain transactions. This is at odds with the stated goal of providing a scalability solution for Bitcoin, since widespread usage of such a mechanism would congest the network even more instead of shifting some of the load off-chain.


The novel approach adopted by Lightning is to chain together several payment channels together, creating a sort of mesh network and allowing people to send funds to people they don’t have a direct connection with, routing their payment through other users channels until it reaches the intended recipient. This is secured by some clever cryptography to make it impossible for one of routing parties to appropriate the funds in transit.

To establish a two way payment channel between two users, the Lightning protocol requires both users to lock some funds in the channel by signing transactions adhering to the UTXO Model adopted by Bitcoin. This is done by broadcasting an opening transaction signed by both parties on chain. Funds committed to the channel are effectively put in a shared account where both parties need to sign a transaction to move funds.

To disengage funds from a channel, a second transaction is crafted by both parties but not committed to the network until one of the users wants to withdraw his bitcoins, therefore closing the channel(and also releasing funds belonging to the other party). Now if one of the two users wants to send a payment to the other a new commitment transaction is created with altered balances reflecting the amount transacted and the old state is destroyed.

This mechanism ensures that an unlimited amount of transactions can happen off chain and at a significantly faster speed than it would be possible if they were broadcast on-chain while providing sufficient security for everyone involved. To avoid the possibility of people broadcasting old states to the blockchain in an attempt to steal funds, the Lightning Network uses a complex mechanism involving a lock up period(HTLC or Hashed Time Lock Contracts)and revocation keys to allow a user to take possession of all of the funds inside of the channel if the other party acted maliciously.

Uptime, DDoS, centralization, frozen funds and other headaches


So far so good right? well not so fast. This is where things start to run into some trouble.

There are significant downsides to this approach, because to keep a Lightning channel alive, both parties involved need to regularly refresh the state of the channel. If you go offline for a determined amount of time, the channel is automatically assumed to no longer be in effect and the funds are released. To make matters worse, unlike Bitcoin, Lightning is NOT asynchronous; this means that to be able to receive a payment you need to be online all the time.

This added requirement has catastrophic security and usability implications as a simple DDoS attack on Lightning Nodes could significantly disrupt the capabilities of the network, rendering it virtually useless and causing some major delays for users wanting to disengage their funds from a channel. Such an attack has already happened on at least one occasion and it’s hard to envision it being a sporadic occurrence considering the economic incentives for an attacker to try and break the network.

Another potentially unwanted situation could arise when a user finds himself having sent funds routed through a channels that failed for whatever reason and that has entered the lock up period. His funds would be frozen until the required time has elapsed. Until the network is much more mature we won’t have an idea of what fees will look like for multi hop payments, albeit they will be substantially lower than the current average for an on chain tx.

Finally, centralization is a serious concern. Since there are economic penalties imposed for being offline, this will inevitably lead to nodes being hosted on centralized services offering high uptime like Amazon AWS, Azure etc. This would ultimately create a single point of failure and a prime target for government regulation or interference. The current network topology is already heavily reliant on Lightning Hubs providing nodes with high uptime and acting as communication centers aggregating many channels with different users, enabling the exchange of funds between users not directly connected to each other.

Hubs with all of those connections mean Lightning is relatively centralized.

To conclude, Lightning is an extremely promising technology whose impact can’t be underestimated but at the same time is ripe with security and usability limitations – the crucial factor in its success is going to be adoption. If the network is able to achieve critical mass it will become much more resilient and achieve widespread usage. Unfortunately this is a vicious cycle, as to become big it needs users and to get users it needs to be functional (and therefore big).

Only one thing is certain, we’re still in the early days – will Lightning Network manage to prove itself in a real world scenario? Time will tell.

Leave a Reply