Preview
Preview
Preview
Preview
Preview
Preview
Preview
06 Oct 2021
How does the Lightning Network function?
The difference between Bitcoin and Lightning is that Bitcoin broadcasts each transaction to the chain, whereas Lightning verifies a channel status against the chain.
Because on-chain transactions require a significant amount of data to be transmitted, the Bitcoin blockchain can handle a limited number of transactions per second. In contrast, credit card providers claim to handle up to 65,000 payment transactions per second. Because Lightning is built on top of Bitcoin, while drastically increasing transaction capacity and lowering costs, it represents a competitive alternative to traditional payment providers and a true peer-to-peer electronic cash system. But how is the Lightning Network able to scale Bitcoin? In this blog post, we try to explain how, in simple terms. This blog post is an extract from our latest report: “The State of Lightning”. Powered by OpenNode - Supported by Lightning LabsThe Lightning Network utilizes a network of payment channels powered by smart contracts to send transactions between peers. A payment channel is a connection between two counterparties on the Lightning Network called nodes. Each counterparty has committed a certain amount of bitcoin that can be sent to the other counterparty’s side of the channel. The figure below illustrates how such a channel is opened, how the nodes relay bitcoin to each other on the Lightning Network, and eventually how debts are settled through the closing of a channel. The whole process is illustrated below, but do not use too much time on it, we will walk you through the steps. The Lightning Network is a layer 2 solution on the Bitcoin Network, meaning it builds upon Bitcoin. We can see this clearly by examining the opening of a channel on the Lightning Network. When two counterparties (nodes) decide to open a channel on the Lightning Network, they need to fund the channel by a transaction on the Bitcoin blockchain. In the opening transaction, each node commits an amount of bitcoin stored on the blockchain that funds their side of the channel. In the illustration below, Alice and Bob each commit 1 bitcoin to their side of the channel in the opening transaction. They do this by both signing a multisignature UTXO (Unspent transaction output) on the blockchain where they commit 1 bitcoin each. In simplistic terms, they have now locked up 1 bitcoin each on the blockchain that can only be moved by a new input from the channel on the Lightning Network. In terms of our illustration, we have moved from the on-chain opening transaction in the lower left of the figure to the newly opened channel between Alice and Bob in the upper left corner of the figure. Once the channel is opened, Alice and Bob can start sending payments to each other. First, Alice pays Bob 0.5 BTC. The figure below shows how this works by moving from our newly opened channel in the top left to the top right after Alice has sent Bob 0.5 BTC. 0.5 BTC is then subtracted from Alice’s side of the channel and added to Bob’s side of the channel. After this transaction, Alice has 0.5 bitcoin on her side while Bob has 1.5 bitcoin on his side. Now, Bob wants to send Alice 0.25 bitcoin. Bob has sufficient funds in his side of the channel and can therefore send Alice 0.25 bitcoin. After this transaction, Alice now has 0.75 bitcoin on her side and Bob 1.25 bitcoin on his side of the channel. Alice and Bob could now go on forever, sending bitcoin back and forth to each other on the Lightning Network. In our case, however, Alice decides she no longer needs a payment channel with Bob. She, therefore, decides to shut down the channel. Bob can’t stop Alice from doing so, but he can prevent her from sending false information to the blockchain. If Alice tries to send a final ledger with more than 0.75 bitcoin on her side of the channel, Bob can dispute this with his evidence that Alice only had 0.75 after the last transaction between the two. To prevent people from trying to steal bitcoin through false closing statements, the Lightning Network has a punishment protocol in place. If Alice sends incorrect information, and Bob proves this information to be false, all the funds in the channel will be transferred to Bob’s side of the channel. In other words, Alice would lose 0.75 bitcoin by trying to fool Bob. Alice, though, has no intention to steal from Bob, and Bob also agrees that the channel should be closed. They, therefore, close the channel in cooperation. They do this by both signing off on a closing statement that confirms Alice has 0.75 bitcoin on her side and Bob 1.25 bitcoin on his. The closing transaction can now take part on the blockchain. Remember Alice and Bob and both committed 1 bitcoin each in the opening transaction. In the closing transaction, this amount gets redistributed as told by the closing announcement from the Lightning Network, meaning Bob now has increased his on-chain holdings to 1.25 bitcoin while Alice has reduced her on-chain holdings to 0.75 bitcoin. The above is an example of a bi-directional channel, which is limited to two parties transacting. However, globally viable payment networks are not built on bi-directional payments channels. Instead of establishing a direct payment channel to every other person and company on the network, a technique called Hash Time-Locked Contracts (HTLCs) allows payments to be sent through a path of payment channels. To illustrate how this works, we have sketched a miniature Lightning Network below.The Lightning Network is a network of payment channels, which means that every node is connected to another node. In our miniature Lightning Network, we have made the network of channels very simplistic for illustration purposes. Alice and Bob have yet again opened a channel with 1 bitcoin on each side. Bob has, in addition, opened a channel with John, John, in turn, has opened a channel with Sarah, and Sarah has also opened a channel with Charlie. Alice now wants to send Charlie 0.3 bitcoin. Alice and Charlie have no direct channel, as we can see in our sketch of the miniature Lightning Network. However, we can find a way to Charlie by moving through the connected channels. Alice can reach Bob, who can reach John, who can reach Sarah, who can reach Charlie. Alice has 1 bitcoin on her side and should therefore be able to give Bob 0.3 bitcoin, who can give it to John, who can give it to Sarah, who again can deliver it to Charlie, right? This is only partially true. Due to how payment channels are constructed, funds cannot be transferred from one channel to another. The transfer, therefore, must be done by rebalancing all the channels along the route from Alice to Charlie. The figure below shows how this is done on the Lightning Network. Alice starts by transferring 0.3 bitcoin from her side of the channel between Alice and Bob to Bob’s side of the channel. To forward the payment on its path to Charlie, Bob now takes 0.3 bitcoin from his side in the channel with John and transfers them to John’s side. John does the same in his channel with Sarah, and Sarah then does the same in her channel with Charlie. The net effect of this routing is that Charlie’s side of the channel with Sarah increases by 0.3 bitcoin, and Alice’s side of the channel with Bob decreases by 0.3 bitcoin. Bob, John, and Sarah all have a net effect of zero from this transaction when you combine their holdings on their side in both channels. Following the counterclockwise direction of the payment, the three have increased their holdings on the incoming side by 0.3 bitcoin and decreased their holdings on the outgoing side by 0.3 bitcoin. Before showing how the Lightning Network increases the transaction capacity of the Bitcoin Network, we would like to address one more thing. In the above example, what stops Bob from simply keeping the 0.3 bitcoin Alice transfers to his side of the channel and not continue with Alice’s payment. Remember, we earlier wrote that a technique called Hash Time-Locked Contracts (HTLCs) allows transactions to be sent through a path of payment channels, and that is still true. The Hash Time-Locked Contracts remove the possibility to intercept and keep payments. Simply put, the HTLCs use cryptography that requires the recipient, in our case Charlie, to confirm he has received the payment. If Charlie does not confirm the reception of the payment within a certain amount of time, the payment will be returned to the sender. So, If John tries to keep Alice’s 0.3 bitcoin meant for Charlie, Charlie will not confirm the payment within the time limit, and the 0.3 bitcoin is returned to Alice. So far, we have tried to explain in non-technical terms how the Lightning Network functions and not explicitly told how it solves the scaling problem of the Bitcoin on-chain Network. To do this, we provide a simple example of how our Miniature Lightning Network can send each other a multitude of payments on Lightning while not increasing the number of transactions on the Bitcoin blockchain. To show this, we have made an example ledger in our Miniature Lightning Network below. In the illustration above, we start with the same network as earlier. Our Miniature Lightning Network consists of four channels connecting five nodes. Four on-chain opening transactions are needed to set up this network. Now, all five nodes (people) in the network can freely send payments to each other if each payment is within the bounds of the possible payment amount between the payer and recipient. The Miniature Lightning Network ledger records all the transactions between the people in the network. The first 20 payments are listed in chronological order on the first page of our ledger book, with the channel bookkeeping on the second page. After these 20 payments are conducted, the payment channels are rebalanced, as shown to the right in the figure. The great part is, these 20 transactions have required zero on-chain transactions. Now, the people in our network would likely keep their channels open and keep sending payments to each other. But even if they all decided to close their channels after the 20th transaction, they would still have saved space on the blockchain, with only four closing on-chain transactions needed to settle the final ledger after 20 transactions.
This blog post is an extract from our latest report: “The State of Lightning”. Click the link below to download the full report.