Lightning Network

Published on 09 February 2022 in InfrastructureLayer 2

Introduction

In the landscape of cryptocurrencies, Bitcoin reigns as the pioneer and poster child, capturing the imagination of individuals and institutions alike with its potential to revolutionize finance and reshape the global economy. Yet, as Bitcoin’s popularity soared, so too did the challenges it faced, notably in the form of scalability constraints and sluggish transaction speeds. 

Enter the Lightning Network, an innovative way to address Bitcoin’s scalability issues, illustrating the innovative character of the cryptocurrency community. The Lightning Network aims to provide faster and cheaper transactions, and reduce congestion on the Bitcoin mainnet by moving transactions off-chain. This layer 2 solution has gained a lot of traction over the years. It represents a pathway to unlock Bitcoin’s true potential as a fast, efficient, and accessible means of payment on a global scale.

Here, we delve into the inner-workings of the Lightning Network and shed light on its history and the reasons behind its development. We’ll also navigate through the challenges it faces and the ongoing efforts to enhance its security, privacy, and user-friendliness. Finally, we will analyze whether or not the Bitcoin Lightning Network lives up to its promises, and the role it could play in the future of our financial systems.

A brief history of the Lightning Network

Conception

In February 2015, Joseph Poon and Thaddeus Dryja first proposed their idea for the Lightning Network in a whitepaper. The concept of such a network, intended to provide a solution to Bitcoin’s impending scalability issue, quickly gained attention within the Bitcoin community and developers started to work on the creation of such a network.

Alpha release

Developers started working on the Lightning Network’s alpha implementation, and the first successful Lightning Network Bitcoin transaction occurred in April 2016, demonstrating the concept’s feasibility.

Development and testing

Over the next couple of years, developers from various organizations, including Blockstream, Lightning Labs, and ACINQ, actively worked on implementing Lightning Network technology. The network underwent extensive testing and received valuable feedback from the Bitcoin community.

It was also during this period that Bitcoin underwent a drastic upsurge in popularity in late 2017. As the price of Bitcoin skyrocketed and media attention increased, more users rushed to buy and trade Bitcoin. This led to a significant increase in the number of transactions being processed on the network, causing congestion and delays. This highlighted one of Bitcoin’s main issues: its limited scalability – the exact issue the Lightning Network was developed to address.

Mainnet launch

On March 15, 2018, the Lightning Network went live on Bitcoin’s mainnet with the release of the Lightning Network Daemon (LND) by Lightning Labs. This marked a significant milestone in Bitcoin’s journey towards scalability.

Growth and adoption

Since its launch, the Lightning Network has seen steady growth in terms of the number of nodes and channels, making it easier for users to open payment channels and transact with Bitcoin more quickly and at lower fees. Through this way, the Lightning Network plays an important role in keeping Bitcoin accessible for many people, and making it more suitable for micropayments in day-to-day transactions.

Improvements

Ongoing development efforts have led to various enhancements and improvements to the Lightning Network protocol. Developers have been working on features such as watchtowers (to prevent fraud), better routing algorithms, and mobile wallet integration, making it more user-friendly.

In summary, the Bitcoin Lightning Network has evolved from a conceptual whitepaper to a real-world solution that offers a promising way to scale Bitcoin by enabling faster and cheaper transactions through a second-layer network. Its ongoing development and growing adoption are indicative of its potential to enhance the Bitcoin ecosystem.

Core values behind the Lightning Network

With Bitcoin rising in popularity, more and more people started to conduct transactions on its network. Because Bitcoin is limited by blocksize and an increasing difficulty of mining efforts, the network was unable to keep up with the rapid growth in transactions. This led to long waiting times and high transaction fees, making Bitcoin less appealing to the wider public and also less suitable for daily transactions.

Keeping Bitcoin accessible

The developers behind the Lightning Network wanted to address the scalability issue of Bitcoin. By taking a large part of transactions, especially smaller payments, off of the main blockchain, the congestion would lessen, while transactions would simultaneously become cheaper and faster. This keeps Bitcoin accessible for a larger group of people, especially those who mainly use it for small transactions that are not worth the high transaction fees of the main blockchain.

Making Bitcoin more suitable for micropayments

The lower transaction costs and waiting times for Bitcoin payments on the Lightning Network also make Bitcoin more suitable for day-to-day uses, such as paying for groceries or online shopping. Before layer 2 solutions, these transactions were difficult to perform with Bitcoin due to the waiting times. This made Bitcoin unable to compete with other digital payment systems, such as Visa, who handles massive amounts of transactions every day. Layer 2 solutions such as the Lightning Network have the ability to make cryptocurrency more suitable for micropayments, thus providing them with a stronger position on the payment market than before.

Open-source and community driven

Another important value of the Lightning Network is that it is an open source project, which relies on a community of contributors, similar to Bitcoin itself. This fosters collaboration and innovation within the cryptocurrency ecosystem, while preventing that only one entity or a select group of people hold all the power over the network.

How does the Lightning Network work?

The Lightning network is essentially a layer-two payment protocol built on top of Bitcoin’s main blockchain. Via this protocol, users that wants to make multiple transactions with one another can transfer value back and forth until they don’t need to transact with each other anymore. When that happens, the final balance of those transactions is settled on the main chain. In order to understand exactly how this process occurs, we have to first understand how two fundamental concepts to its functioning work. These are bidirectional payment channels and hashed timelock contracts (HTLC). Let’s first focus on payment channels.

Bidirectional payment channels

The goal of the Lightning network is to establish a network of transaction roadways, which is effectively achieved by stringing together multiple payment channels. These paths occur off-chain, as to make transactions cheaper and faster. A single payment channel allows for the state of a transaction to be broadcasted to the blockchain at a later date. 

A single bidirectional payment channel between two participants

To understand some of the main ideas of the Lightning network, let’s first consider a single bidirectional payment channel between two network participants. The first thing that needs to be done before they can get started is to set up an initial funding transaction. The funding transaction allows for a starting balance of funds, which can be spend by both participants as long as the maximum amount in the channel is not exceeded. Both participants may fund the initial balance, but they have to exchange the inputs with each other so that all parties know the balance. Furthermore, they exchange one of two keys for the output of the funding transaction, which is a 2-of-2 multisignature output. However, they don’t sign this output until they have made further transactions. The next step is to spend from this balance, this is performed by what is called a commitment transaction, which is a “child” transaction to the “parent” transaction which is the initial funding transaction. A commitment transaction then reflects the new balance between the two participants. When a new spend occurs, a new commitment transaction is caried out, which once again reflects the updated balance. If the participants want to close their channel, then they can do so in two ways. After one or more commitment transactions are spend, they are signed and the signatures are exchanged between the participants. Either they can spend from the funding transaction, based on the balance that is reflected by the most recent commitment transaction, with an exercise settlement transaction (ES). In this case, the initial funding transaction is signed, its signatures are exchanged and finally the parent transaction is broadcasted to the blockchain, with both parties obtaining the funds that are theirs. The second option is to broadcast the most recent commitment transaction instead. 

Ascribing blame

An important factor to keep in mind is that each participant must be incentivized to broadcast based on the most recent commitment transaction. Consider two participants, we will denote them A and B. Now imagine that the current balance between two users is slightly higher for participant A than for participant B, but a few commitment transactions ago the balance was distributed the other way around. Participant B would then be incentivized to broadcast an older commitment transaction to the blockchain, since they would receive more money this way. For this reason, it is important to prevent old commitment transactions from being broadcasted. An agreement between the participants is made that only the most recent commitment transaction can be broadcasted, if this agreement is broken a penalty is enforced upon the user who acted wrongly in the form of a complete loss of funds. These funds go to the other participant. Vital to a penalty-based system like this, is that there must be some sort of way to ascribe blame to participants. In order to achieve this, both participants have a unique commitment transaction that is completely identifiable. The idea relies on the fact that both of these commitment transactions spend from the initial funding transaction, and thus only one of them can be broadcasted on the blockchain. These two commitment transactions will be denoted as C1a and C1b (footnote: With denotations like these, the 1,2, etc indicate the number the types of transactions. So C1 denotes the first commitment transaction since the payment channel is opened, for example. The letters a and b represent from which channel user the transaction is).

The identification part is achieved in the following way. Imagine participant A and B again. Participant A has the possibility to broadcast a commitment transaction that is already signed by participant B. Since both signatures are needed, only participant A can broadcast this transaction by signing it. Similarly participant B has the option to broadcast a commitment transaction but with the signature of participant A already on it. This construction thus ensure that each participant can only broadcast their own commitment transaction. Therefore, it is known which participant broadcasted wrongly in case of fraud. 

Revocability of transactions

In order to enforce the penalties in the case of malicious behavior, as well as to “overwrite” old commitment transactions and replace it by an updated one, the ability to revoke transactions on the channel is desired. To that end, sequence numbers are utilized to give maturity to transactions, meaning that transactions can “expire”. This would allow for a form of relative block confirmation time locks to be used on the payment channel. The structure that is used to accomplish revocability is called a Revocable Sequence Maturity Contract (RSMC). The idea is that each parent transaction has two pathways, one where the funds can be redeemed instantly and one where the funds can be redeemed only after the child transaction has had a minimum number of confirmations between itself and their parent transaction. The former is called the Delivery transaction and is denoted as D(1). The latter is called the Revocable Delivery transaction (RD(1)). The participant that broadcasted the commitment transaction takes the RD pathway while the other participant can redeem their funds instantly. This boils down to the following: The broadcaster of the commitment transaction can only spend funds from the parent output when the number of blocks between this output and the transaction in question has reached a specific block height. After this time has passed it becomes possible for this participant to broadcast RD(1) and receive their funds. This leads to a situation where the parent transaction is the potential payout to the participants, which turns into reality after enough time, and thus confirmations, have passed. Before this happens, there is time to disprove this transaction, or to replace the commitment transaction with a new one. For the latter to happen, the participants simply agree to generate a new commitment transaction and broadcast it within the allowed timeframe of its parent transaction. This new transaction easily supersedes the old one due to the maturity gained from the use of sequence numbers. 

Payment channels with the ability to ascribe blame and to revoke transactions

Let us look at how an update of the most recent commitment transaction would take place after the concepts of ascribing blame and transaction revocability are applied to the bidirectional payment channel. After both of the participants have agreed upon a new balance, in the form of two new commitment transactions, which will be denoted as C2a and C2b, they will both sign them. One will be signing C2a and receiving C2b and the other will sign C2b and receive C2a. Subsequently they will invalidate the old balance. The latter is done by making both participants sign a transaction that will overrule the RD1 transaction and thus practically replace it. This is called a Breach Remedy transaction (BR(1)) and if it is broadcasted by a party then all the funds in the channel will be send to the counterparty. To that end, both users sign the BR1 transaction and exchange it with the other. That way, when one signs its (old) commitment transaction C1, the corresponding BR1 transaction will be broadcasted by the other user, which results in the former losing all its funds. The BR1 transaction can only be broadcast after the corresponding C1 transaction is broadcasted first, there thus exists a predefined time period in which BR1 can be broadcasted. However, when the other user forgets to broadcast their BR1 transaction within the allotted timeframe, their funds get practically stolen. To prevent this, it is required that the blockchain is monitored constantly. Because this can be troublesome for most users, it is possible to delegate this responsibility to a third party. 

Hashed Timelock Contracts (HTLC)

What is an HTLC?

A Hashed Timelock Contract (HTLC) is a smart contract that aims to lessen counterparty risk. (Investopedia). It is utilized in numerous blockchain applications, in the case of the Lightning network it functions to allow for safe transferring of funds. HTLC’s thus allow for participants to make micropayments across the interconnected network of payment channels without requiring any level of trust between them, i.e., safe network routing. It is thus a vital component of the Bitcoin Lightning network. There are two components to an HTLC, a hashlock and a timelock. An HTLC is thus a smart contract that consist of both of them, hence its name. Putting a hashlock on a transaction means that that transaction is encrypted in order to make it secure. The public key is hashed by the participant that begins the transaction. The information that is needed to generate this hashlock, as well as to later on solve it, is called the pre-image. The pre-image thus needs to be disclosed to the receiver of the transaction in order for them to obtain the funds, it is like a proof that they can use for this purpose.

The second component is the timelock, this is a form of restricting mechanism that prevents a transaction from occurring until a certain time limit is reached. It thus allows for time constraints to be set on the contracts. So, receivers of transactions cannot confirm the details of the transaction until a specified time is reached. What’s more, they need to provide a proof-of payment before this time has passed in order to receive the funds. 

Combining these two properties into HTLC’s that are applied to a network of payment channels leads to the main idea of the Bitcoin Lightning network, payments that can be enforced by the receiver knowing the pre-image of its transaction, but are cancelled when this is not the case. If the recipient fails to do so before the time has elapsed, then the sender can claim a return of the funds back to them. To prevent both options from remaining valid after the time period has passed, the concept of revocability is utilized here as well, once again in the form of RSMC transactions. 

HTLC transactions between two participants

Consider that two participants want to update their initial balance. The outputs from their new commitment transactions (C2a/b) will be threefold: an immediate delivery, a revocable delivery via an RSMC and an HTLC transaction. The first two work similar as to what we have seen in the bidirectional payment section. To set up a new HTLC transaction, the participants first exchange their signatures for the HTLC, followed by an exchange of the signatures of the new commitment transactions, and finally the Breach Remedy transactions are signed. The funds that are meant to be send, as to update the current balance, are described by the HTLC. There are two HTLC outputs for each of the commitment transactions, they are thus different for C2a and C2b. This means there are two options, either the sender of the funds broadcasts the commitment transaction or the receiver does. Let’s consider the case of the sender first, they broadcast their commitment transaction, C2a. Only the receiver is then able to broadcast an HTLC Execution Delivery transaction (HED1a) and pull its funds from it when they know the pre-image. They are able to do this because the sender has given its signature to the receiver as discussed at the start of this paragraph. If, however, the receiver fails to broadcast this transaction in the allotted timeframe, the sender is able to broadcast an HTLC Timeout transaction (HT1a), which is an RSMC transaction. After a specific number of block confirmations have occurred, the sender can broadcast an HTLC Timeout Revocability Delivery transaction (HTRD1a) and claim their funds back. Before this happens, the transaction can be overtaken by a new transaction. The case where the receiver of the funds broadcasts their commitment transaction, C2b, is a bit similar but with the exception that now, the execution transaction is an RSMC and the timeout transaction is not, which is the opposite from the previous scenario. The receiver can broadcast an HTLC Execution transaction (HE1b) when they know the pre-image. However, the sender has some time available to broadcast the HTLC Timeout Delivery transaction (HTD1b), whereby the funds are retaken when the receiver fails to broadcast HE1b in time. If this is not the case, then the receiver can broadcast the HTLC Execution Revocable Delivery transaction (HERD1b) after the time has passed and obtain their funds. Again, this transaction can be superseded by another when they both agree to do so. 

In both of these cases, when the participants want to keep the channel open, they create new commitment transactions as described at the start of this section. If they wish to terminate their channel, they might also create new commitment transactions that update the balance (but no new HTLC transactions) and in addition to exchanging breach remedy transactions, which invalidate the old commitment transactions, they should exchange private keys that are used in the old HTLC transactions as well. That way, one counterparty’s funds are guaranteed when the other broadcasts old commitment transactions. 

The Lightning network of bidirectional payment channels

Transaction settlement via routed payment channels

So far, we have seen the construction of a single bidirectional payment channel and how transactions between two users would look like with the concepts of blame ascription and revocability embedded into it. Furthermore, we have discussed how revocable HTLC transactions are applied to the channel, a concept that is mandatory for a network of payment channels to function properly. Let’s now consider a micropayment in the Lightning network that occurs via a routed payment channel. Imagine that node A wants to send some funds to node B. However, they don’t have a payment channel open together, but they do not plan to exchange funds regularly in the future. Both of them do have payment channels open with other nodes. As it turns out, there is a way to achieve their end, namely the funds can go through a number of other nodes, denoted as Xn (so X1, X2, X3, etc). Let’s consider a transaction chain that has three intermediary nodes, these are also called the routing nodes. So, we get the chain A-X1 -X2 -X3 -B. Node A wants disclosure by node B of the pre-image, but they are not directly connected. To that end, a chain of delegated responsibility is created, specifically, each routing node obtains an HTLC that serves to them as a promise that they will receive a fee for providing the routing service. They obtain this fee when they obtain the pre-image from the node in the chain before them. In our case, node B obtains an HTLC from node X3, and subsequently sends the pre-image to the latter. This allows X3 to obtain their fee and afterwards node B can pull their funds, which were locked in the HTLC. The payment is then settled via an update of the most recent commitment transaction between the two nodes. When this has occurred correctly between node B and X3, novation of the commitment transaction can now take place between node X2 and X3 in a similar manner, all the way back to the sender of the funds. To ensure that this structure of subsequent funds pulling can function accordingly, the expiration time of each HTLC contract in the transaction chain increases from the receiver back to the sender. So, for example, counting from the moment that the transaction is set up, node B has 1 day to settle between them and node X3, while the latter has 2 days to do so with node X2, and so on.  

The receiver of the payment should only disclose its pre-image in the event where they have received an HTLC from their direct counterparty, that way they are sure to obtain their funds and no intermediary node gets unlawfully enriched. When all nodes are cooperating, the whole process occurs off-chain. When there is an unresponsive party, for whichever reason, its counterparty should broadcast the most recent commitment transaction to the blockchain. That way, the node next in line can continue to update their balances off chain. 

In the case that a transaction does not reach the receiver, they should be compensated for their loss. If there is no counterparty that has any half-signed contracts, the refund could be settled by a straightforward update of the commitment transaction, from the most recent node onwards. Other options are to reverse the transaction, by letting the receiver request the same amount of funds to the sender of the original transaction. This should be sent with the exact same hash as used previously. Finally, it is also possible to send the funds back via a new route. This new route would involve other nodes that were not contributing to this payment before. They may replace a single node but it is possible that they replace multiple nodes at once as well. 

Fees and third parties

Fundamentally, the fees that are associated with using the Lightning network are paid out between participants and are stemming from a mixture of charges. For starters there are the standard transaction fees of the Bitcoin network, but fees are also paid for both the closing and the opening of the individual payment channels in the network. Additionally, fees are charged for the routing of information between the nodes of the network. So, fees are used to pay for the time consumption that comes with using the access to the payment channels in the network. Another reason than that is the counterparty risk that comes from a communication dependent system. If one’s counterparty is non-responsive in the chain of delegated obligations, then some fee losses are suffered since they have to make up for the lack of their counterparty by broadcasting to the blockchain, which comes with a fee. For that counterparty risk, a fee is paid as well. 

As mentioned earlier in the text, it is necessary that the blockchain is constantly monitored, with regards to the Breach Remedy transactions. To that end, it can be convenient that a third party is designated to perform this monitoring. If this is the case, the Breach Remedy transaction is given to the third party, so that they can broadcast it when the respective counterparty maliciously broadcasts an old commitment transaction. The third party is willing to do this because a fee is paid to them in the final output of the transactions that they monitored. These third parties are often referred to as Watchtowers. 

Adoption and growth of the Lightning network

The Lightning network has seen a vast number of upgrades, new features and integration over the last years, -and it doesn’t seem like its development and adoption is going to stop any time soon. In 2018 the first Lightning transaction was conducted, and the total amount of BTC that was locked up on the network was below 100 BTC. Today, there is over a couple of thousand BTC locked on the network, over 15 000 nodes are running and over 70 000 channels are operating. More and more businesses worldwide are accepting bitcoin payments on the Lightning network. Clearly, a lot has happened with the layer two protocol since its inception. Let’s go over some of the most significant developments. 

Wallets

In 2018, some of the first user-friendly BTC Lightning network wallets were deployed. Among these were the non-custodial Wallet of Satoshi and Eclair Wallet. Later on, even more wallets were developed, like Breez for example, that increased user-friendliness even more and helped make the Lightning network more available for the average user.

Exchanges

Many crypto exchanges have integrated the Lightning network, to allow for Lightning support among them, which is important to grow the Bitcoin ecosystem. By enabling their customers to withdraw and deposit their funds using Lightning network payment channels, these exchanges facilitate the wider adoption of Bitcoins layer two network. The exchanges that have integrated Lightning include some popular ones, like OKex, BitFinex, Bitstamp, Kraken and, since July of 2023, Binance as well. Furthermore, the tradingapp Robinhood has adopted the technology too. Relatively soon after Binance adopted it, Coinbase’s CEO Brian Armstrong announced that the company is also working on integrating Lightning. With Binance and Coinbase being two of the biggest exchanges, this integration could proof to be significant for global Lightning adoption.

 El Salvador

The country El Salvador was the first to make Bitcoin legal tender, this happened in 2021 under the leadership of president Nayib Bukele. Soon after, they launched a Lightning wallet called Chivo, which is backed by the state, that has onboarded millions of users. El Salvador is often hailed as the first example of a place where payments in bitcoin are made on a day-to-day basis, and while this is certainly happening, there are still many inhabitants who do not use bitcoin all that much, or trust familiar fiat money options more. Though there are also those who are very enthusiastic about Bitcoin and its future, the opinions among the people thus differs in the country. It is speculated that further integration of the accessibility of the Lightning network into the day-to-day life of its inhabitants may end up shifting the opinions more into Bitcoin’s favor.

Strike

Using Lightning network to make remittances is cheaper than traditional ways to transmit money. Namely, the fees of the Lightning network are significantly lower compared to the latter. At the end of 2022, the digital payment platform Strike, founded by CEO Jack Mallers, introduced a new feature to their money transfer app, that streamlines cross-border payments even more. It already had their Bitcoin Lightning payment app in use, with user-friendly features, like displaying the balances in local currencies and handling the cryptographic elements in the background. With their new feature, called “sent globally”, they enhanced the remittance payment process even more. Among others, seamless money transfers between the United States, the Philippines and various African countries is possible now. All using the Lightning infrastructure and with negligible fees. At the Bitcoin conference of 2023, Strike announced that it would expand their bitcoin payment services to 65 global markets, estimating that they could reach up to 3 billion people globally.

Cash app

Jack Dorsey, the CEO of the mobile payment platform Block, formerly called square, has shown enthusiasm for Bitcoin and the Lightning network on multiple occasions and has funded numerous grants for various Bitcoin and Lightning network projects so far. In 2013, Block developed a mobile payment service in the US and the UK, called Cash-app. With Dorsey being such a big proponent of Lightning, it was no surprise that the company integrated the Lightning network, which occurred at the end of 2022. This allowed access to millions of users to the network. 

Merchants

There are numerous merchants that accept Lightning payments in bitcoin for their shops, and for apparent reason. If merchants accept credit card options, the companies behind them charge hefty processing fees (for VISA and Mastercard typically between 1.5-2.5%, compared to the fees on the Lightning network, which are only 0.0029% on average according to analytics company Glassnode. The choice for using Lightning payments thus is not contained to El Salvador, there are plenty of international stores or payment providers who have adopted it. Some big names are Shoppify, MCDonnalds, Macy’s and Walmart. The beforementioned company Strike additionally partnered up with payment providers like Clover, NCR and Blackhawk to facilitate Lightning payments to various merchants. 

Africa

For a lot of African countries, facilitating money transfers is an overly complicated process. There is limited access to both commercial banks as well as digital banks and the vast majority of cross-border payments stemming from African banks are processed outside of the continent, leading to high processing fees and high waiting times. Combine this with extreme inflation and no shortage of corruption in governments, and you have a complicated money situation to deal with. To do just that, mobile money transactions took off around the start of this century, which allows users to transact via SMS texts, no mobile data or smartphone required. But this method still lacks in several ways as it is not able to provide the same benefits to its users as banking services in more developed countries do. Furthermore, the biggest issue seems to be interoperability, since there exist around two thousand payment networks that communicate little to none with one another. To the inhabitants of these countries, Bitcoin on the Lightning network is an excellent solution, as it circumvents a lot of the issues discussed above, and let anyone send money easily and instantaneously to one another or abroad, with little to no fees. Bitnob, an app designed with the specific goal to make it as easy as possible for African businesses and individuals to connect to the Bitcoin blockchain, uses the mobile payment structure to that end by being SMS based as well. Similarly, a non-custodial wallet called Machankura (a slang term for money used in some parts of South Africa) uses USSD technology, which is similar to SMS, to let its users transact via Lightning rails. Projects like these allows Africans to transact in BTC for their daily needs. Popular South-African grocery merchant Pick n Pay accepted Lightning infrastructure at the end of 2022, to give an example.

Taro protocol

The Taro protocol (Taproot Asset Representation Overlay) is a protocol implemented in 2022 that allows Bitcoin users to issue and transact digital assets and data on the Bitcoin blockchain. Due to the immense benefits in speed and transaction fees, this mainly happens on the Lightning rails, since Taro is compatible with Lightning. In fact, the protocol is an initiative of Lightning Labs and consists of some Bitcoin improvement proposals. One of the main features that stems from Taro is that stablecoins like USDC can be transacted globally using the Lightning network.

Lightning outside of Bitcoin

Besides Bitcoin the Lightning network is also available on some altcoin blockchains. Unsurprisingly, there is a Lightning network that runs on Litecoin, since this project originated as a fork of Bitcoin. Z-cash on the other hand, has its own version of a Lightning-based protocol, called BOLT (Blind Off-chain Lightweight Transactions) developed by BOLT Labs and focused on privacy. To that end, it has implemented zk-SNARKS into every payment channel, such that users cannot see each other’s balances per see. Similarly, Raiden is an Ethereum compatible layer-two scaling solution that functions closely to the Lightning network. Any ERC-20 token can be transacted on it.

More projects and updates

  • Mid 2020, the Wumbo upgrade came through, which significantly allowed for Lightning network nodes to facilitate larger transactions at larger volumes. Before this point, the balance inside a single payment channel was restricted to 0.1677 BTC at a maximum, thus forming a problem for somewhat larger transactions to come through the network. 
  • The blockchain company Blockstream has built an alternative version to the Lightning project called core Lightning, formerly called c-Lightning, because it is coded using the C programming language. The aim is to focus on interoperability, since the developers believe that contributions of community members will ultimately help develop and grow Bitcoin and Lightning the most.  
  • A small notable feature deployed on Lightning is the tippin.me chrome extension that is integrated with the network. This makes it possible to tip social media participants on X (twitter) using satoshi’s. 
  • Another notable project is NOSTR, this is a decentralized data sharing protocol that has integrated the Lightning network for payment support. Tipping, spam deterring and payment options can be settled via Lightning rails.

Benefits

While not entirely perfect, the Lightning network has numerous advantages that allows it to distinguish itself as a worthy layer two protocol for the Bitcoin network.

More suitable for payments

To start off, the transaction settlements are significantly faster than the main chain, as well as practically every other layer one protocol. The main Bitcoin chain has a TPS of less than 10, where the Lightning network can, in theory, handle millions of transactions per second. Knowing how Lightning operates, utilizing payment channels that only broadcast to the main chain occasionally, doesn’t make it hard to see how this substantial difference in TPS is achieved. Since a whole lot more transactions can be fitted into a single block in the blockchain this way, using the Lightning network also leads to a decreased amount of network congestions. As discussed earlier, the fees associated with the Lightning network differ from the regular fees on the mainchain. Since they are significantly lower on the Lightning network as well, as miners have to validate less blocks, this also means that it is way easier for the network to scale. The structure of the network is well-suited to conduct micropayments that occur on a day-to-day basis, allowing for Satoshi’s vision of turning the Bitcoin network into a peer-to-peer payment system to become closer to being a reality. For merchants, using the Lightning Network is more feasible to use rather than accepting credit cards, since the fees are significantly lower, as discussed previously.

Reduction in CO2 emissions

Since more transactions can take place with less validation via BTC mining, the Lightning network reduces its carbon footprint drastically compared to the main chain. A decrease in energy on itself is already a big virtue, but this might also help with regards to interest of institutional investors that are typically warry of investing into Bitcoin due to ESG (environmental, social, governance) related issues. Namely, the Bitcoin network has a bad reputation when it comes to carbon emissions, having a second layer on the network with significantly lower carbon emissions helps to dampen this issue. 

Privacy

Furthermore, due to only the opening and closing of payment channels being broadcasted to the blockchain, in case of no malicious behavior, the privacy of the actual transactions remains. The only thing visible to everyone is the total amount of funds that is transacted eventually, but all of the micropayments in between remain private to the individual parties. Therefore, the Lightning network introduces some privacy that the Bitcoin mainchain is lacking, which is a concept that is still very much desired by numerous people. 

Fiat currencies on Bitcoin

With all sorts of digital fiat currencies being in development currently, it is not impossible to imagine a strong fiat currency like, for example, a digital dollar to be employed on the Bitcoin blockchain via the Lightning network. In a way this already happens, since the Taro protocol allows for stablecoins like USDC to be deployed on Lightning. This allows for an increase in accessibility of the strongest fiat currencies to people living in less developed countries, which could prove very useful with regards to wealth inequality. Additionally, using the Lightning Network for payments instead of for example CBDC based, or other centrally controlled, payment systems, would protect users against potential transaction censoring and keep their financial freedom more intact. The latter is something that is desired by many crypto enthusiasts. 

Micropayments to shape revenue models

Another, probably less obvious potential feature of the Lightning network has to do with its ability to facilitate absolute micropayments, up to a single Satoshi. This opens the door to fundamentally alter some revenue models that are not optimally suited to provide financial income to members of their industry. An example here is the publishing industry, which operates on a subscription basis, together with generated revenue via advertisements. Using micropayments, publishers can get paid for letting consumers read a single online article, rather than forcing a subscription on them. This might incentivize consumers more to spend, since often subscriptions are not made if there is only interest in a couple of specific articles. With the low fees of the Lightning Network, such micropayments are actually feasible.

Challenges and improvements

Besides the amount of progress that has been made with developing the Lightning network and the numerous advantages it brings to the table, there are still many risks and downsides to the layer-two protocol, leaving enough room for improvement. 

Centralization risks

One of the main complaints that are voiced is the fact that the Lightning network adds centralization to the Bitcoin network, which naturally clashes with the decentralized ideals that the main chain was founded on. If Lightning adoption takes off, it is expected that big companies will create specialized hubs that will allow for many people to transact to the intermediary in a quick way, as to boost user experience and profits. But these specialized hubs will be centralized and resemble the financial intermediaries that exists in today’s financial landscape and bring the exact problems with them that Bitcoin was designed to mitigate. It could be argued that with the complete decentralized main chain, these centralized hubs would be a lesser problem compared to the financial intermediaries in the current financial system, but the situation would be far from ideal when Satoshi’s vision is kept in mind. Furthermore, the beforementioned third parties (Watchtowers) add another centralization factor to the Lightning network. Finally, it can be noted that setting up and managing a node for the Lightning network as an individual is not the easiest thing to do, especially if you want to stay profitable. There are thus some payment incentive issues regarding running a smaller Lightning node, if this issue is not resolved or becomes more apparent, than this might also be a factor that adds to the list of potential centralization risks of the Lightning network. 

Transaction size limitations

Another drawback is that transactions that are carried out have a limiting size, namely the transaction cannot exceed the BTC size of the channel. This means that the amount of BTC send can only be as high as the smallest payment channel in the route that is used. Of course, it could be argued that large sums of money should be transacted via the main chain, due to its enhanced security compared to the layer-two. Nevertheless, this can still be quite a limiting factor. It is not impossible to make a payment that is larger than the channel balance of the user, but this requires locating a node on the network that has enough funding and has a channel that is directed to the recipient of the transaction that the user wants to make, which is not an easy process and can take quite some time.  

Global Lightning adoption

What’s more, Lightning payments can only be used at enterprises that actually enable them. This means that in order for the Lightning network to really shine, global adoption needs to progress even more. But despite numerous businesses, exchanges and merchants integrating the Lightning network over the last years, this remains one of the big challenges of the layer-two project. Because enterprises might be hesitant to adopt the Lightning network due to factors related to regulatory uncertainty, but also due to Bitcoin’s price volatility and a general reputation problem that crypto projects have. In addition to this, most consumers are not aware of the potential benefits that the Lightning network might offer them. Even stronger, the vast majority of consumers has probably never even heard of the Lightning network. Both of these factors make grand scale Lightning adoption a challenge to be overcome. 

Security issues

There is also the risk of security issues occurring on the network, because it is susceptible to scams. Via, for example, DOS (Denial-of-service) attacks, the network can get congested and the funds cannot be withdrawn by their respective parties anymore, the attackers can profit from this situation by stealing these funds. Likewise, there have been more attacks identified that can freeze payments in the channels, or cause congestion in other ways, but Lightning developers have been implementing measures to trivialize these threats to a certain point. However, that doesn’t mean that malicious behavior is not a problem at all anymore on the Lightning network, compared to the main chain there is definitely a reduction in security. 

Decreased transparency

As mentioned before, the fact that the individual payment channels preserve privacy can be celebrated as an advantage, but it also comes with some downsides. Decreased transparency can lead to problems regarding criminal activity, for example, one of the benefits of using blockchain based payment networks over hard cash money is that it becomes significantly harder to partake in criminal activity when using the former, due to the inherent transparency that the blockchain brings with it. Lesser transparency leads to lesser means for oversight, which is something that regulatory agencies value when it comes to their recommendations regarding blockchain projects. Since such agencies can have significant influence, this decrease in oversight might proof a hurdle for Lightning network adoption in certain areas. 

Conclusion

In conclusion, the Lightning network presents a compelling case as a layer two protocol for the Bitcoin network, offering a range of benefits that enhance its functionality and usability. The speed and efficiency of transaction settlements, particularly in comparison to the main chain, make it more suitable for day-to-day payments. The reduction in CO2 emissions and increased privacy are notable advantages, addressing environmental concerns and providing users with enhanced financial confidentiality.

Moreover, the potential for integrating fiat currencies onto the Bitcoin blockchain through the Lightning network opens new possibilities for accessibility and financial inclusion, especially in less developed countries. The ability to facilitate micropayments down to a single Satoshi introduces a transformative element to revenue models, potentially reshaping industries like publishing.

However, it’s essential to acknowledge the existing risks and areas for improvement within the Lightning network. Centralization concerns arise with the potential creation of specialized hubs, reminiscent of traditional financial intermediaries, which contradicts the decentralized ideals of Bitcoin. Transaction size limitations and the need for global adoption pose challenges to the network’s widespread effectiveness. Security issues, including susceptibility to scams and decreased transparency, need careful consideration to ensure user protection and regulatory compliance.

In navigating the future development of the Lightning network, it is crucial to address these risks and work towards solutions that uphold the principles of decentralization, security, and transparency. Striking a balance between innovation and addressing these challenges will be key to realizing the full potential of the Lightning network as a valuable addition to the Bitcoin ecosystem.