Lightning Network explained


The Lightning Network is a time-locked off-chain payment channel. This means that users can fix BTC off-chain, i.e. away from the Bitcoin blockchain, and send it to other users. Values ​​are sent almost instantaneously and, similar to on-chain transactions, do not require a trustworthy third party. The Lightning Network is considered a promising scaling solution for Bitcoin.

The scale thing 

Bitcoin is supposed to be an electronic money system in which the participants can send money directly to each other. A monetary system that is not controlled by a central office but is based on a computer protocol. Theoretically, this monetary system should be accessible to everyone in the world. This would give a universal currency standard; a common “language” for all mankind.

But the theory is not so easy to translate into reality. Even though Bitcoin is already an electronic money system with no controlling middlemen, it cannot be used by all people. The reason for this is the scale it requires.

The problem becomes clear when one imagines how many transactions take place every day in the global economy. While the Bitcoin technology can easily transfer gigantic sums of money, it reaches its limits when it comes to high frequency transactions. The reason for this is technical: the blockchain, on which all transactions are recorded, only offers limited space for transactions.  

You can imagine it a bit like a bus. This bus has a limited number of seats. If all the seats are full, no more people can ride. The blocks in the Bitcoin blockchain are very similar. These too only have a certain number of “seats” for transactions. When all seats are occupied, no more transactions can be “joined” (i.e. confirmed).  

One mechanism in Bitcoin is that transactions can secure a seat on the bus through their transaction fee. This means that if Alice wants to send a super important transaction to Bob that must definitely fit on the next bus, she can pay a higher than average fee. The “bus driver” (the miner) doesn’t have to ride the transaction, although he can earn a pretty penny if he does. So he has an economic incentive to make room on his bus for the transaction.  

All well and good, right? Not yet, because what happens when everyone does it? The space on the blockchain, the space in the next block, in the next bus, is strictly limited. If more and more people want to use the Bitcoin money system, more and more transactions want to push their way onto the bus, then the transaction fees will increase. Because the transactions are in competition with each other for a place on the blockchain due to their fees. In December 2017, one could see an example of this bidding on transaction fees.  

How many transactions can bitcoin process per second? 

An often-recited metric when discussing the functionality of Bitcoin is transactions per second. A block in Bitcoin can be a maximum of 1 megabyte in size. An average transaction is 400 bytes in size. This means that on average 2,500 transactions fit into one block. A new block is found approximately every 10 minutes. Consequently, the Bitcoin system can process approximately 4 transactions per second.  

How many transactions per second can the Bitcoin competition? 

To get some perspective on Bitcoin’s capacity, let’s compare transactions per second to two attractive alternatives; Visa and PayPal. While the Bitcoin blockchain reaches its limit at more than four transactions per second, PayPal can process up to 115 transactions per second. Market leader Visa even makes 2,000 transactions per second without any problems, and 4,000 transactions at peak times. According to Visa, it can do much more: up to 56,000 transactions per second should be possible. How can Bitcoin compete and become a global payment system? 

However, two nuances also need to be mentioned in this discussion: the transaction size and the finality of a transaction.  

In Bitcoin, it doesn’t matter to the fees and the network whether an amount of 0.001 BTC or 10,000 BTC is sent. What matters is the number of inputs and outputs of the transaction. With alternative payment systems such as Visa and PayPal, you usually pay a percentage of the transaction amount instead. Sending large amounts is correspondingly expensive. 

The finality of the transaction describes the possibility that the transaction can be reversed. This is very difficult with Bitcoin: once a transaction has been sent and written to a block, it can hardly be undone. This is an advantage, because sellers can be sure that the supposedly friendly customer will not cheat them afterwards. This is different with PayPal and Visa: here there is a period (usually 30 to 120 days) in which the payment can be revoked. This is possible because PayPal or Visa are the central authority in the monetary system. You determine the history of the transactions and can also change them later.  

So while Bitcoin is lagging behind in terms of transaction frequency, the technology can already score massively in terms of transaction size and financial finality.  

Scaling solutions: on-chain vs. off-chain 

The question of transaction capacity is also often called the scaling question. At its core, it has meanwhile assumed the same character as the Gretchen question in Goethe’s Faust: 

 “Now tell me, how’s the scaling?” 

Basically, the answers can be split into two camps: on-chain scaling and off-chain scaling.  

The on-chain approach, to go back to the bus example, is to scale up the bus. That is, to limit the blocks to 1 megabyte, a new upper limit is set for the block. In this way, more transactions fit into the bus, which still departs every 10 minutes. Assuming the block size increases to 10 megabytes, the number of transactions per second increases by a factor of 10. This means that it would then be possible to process around 40 transactions per second. The way to improve the capacity of the blockchain by increasing the block size is reflected in the Bitcoin hard fork Bitcoin Cash (BCH).  

The alternative to this is off-chain scaling. The aim here is not to improve the transaction capacity of the blockchain itself, but to create a second level for transactions that docks onto the first level, the blockchain. This second layer would inherit the security aspects of Bitcoin and also allow for a magnitude more transactions. So instead of scaling linearly like the on-chain approach, the second tier could handle millions of transactions. And that immediately, for very small amounts and with similar security as with the Bitcoin system itself. This method of scaling Bitcoin outside the blockchain is also called the Lightning Network. 

The Lightning Network 

For many Bitcoin representatives, the Lightning Network (LN for short) is the logical next development of the Bitcoin payment system. You can imagine the architecture as a cake with several layers. The Bitcoin blockchain is the ground, or what is known as the base layer. The Lightning Network would build on this. Certain characteristics of the base layer could be inherited, such as security, while other limitations no longer apply, namely the limited number of transactions.  

The linking of the base layer and the Lightning Network is achieved through a series of cryptographic mechanisms.  

Payment Channels – The basis of the Lightning Network 

The core of the Lightning Network are payment channels. A payment channel can be thought of as a tunnel between two parties, Alice and Bob. So it connects Alice and Bob directly to each other. The difference between a payment channel and a transaction on the blockchain is that payments within the tunnel are not recorded on the blockchain. Instead, Alice and Bob can keep updating the status of the payment channel and only write the last status to the blockchain when they are “done”. The payment channel is updated outside of the blockchain and is not bound by its limitations. Alice and Bob could update their channel status several times per second. In other words, micro-transactions are not only possible, but also plausible.  

So if you want to understand the Lightning Network, you should first understand payment channels. 

One-way payment channels 

The classic channel or payment channel consists of two participants (peers), Alice and Bob. The multi-signature technology Bitcoins and a so-called lock time are used for the channel. Multisignature transactions can be used to generate transactions that require more than one private key to sign a transaction. In the case of payment channels, so-called 2-2 multisig transactions are generated. This means that the bitcoins associated with this transaction require the consent of both parties in order to be sent. The lock time ensures that the coins within the multisig cannot be transferred for a certain period of time. 

A  unidirectional payment  channel only ever sends money in one direction. So from A to B, not the other way around. 

Let’s use a real-world example to illustrate this: Bob runs a coffee shop where Alice buys coffee every morning. So that Alice does not have to write a transaction to the blockchain every time, which takes a relatively long time and costs a lot. Therefore, she opens a payment channel with Bob. In return, she sends a certain amount, in our example 10,000 satoshi, to a 2-2 multi-sig address. Alice controls one private key and Bob controls the other. For a valid transaction to be written to the blockchain, both Alice and Bob must sign the transaction.  

The transaction that opens the payment channel is also called a  funding transaction . It is written and minded in the blockchain. The funding transaction indicates the maximum amount of money that can be spent.  

In addition, Alice brings in a second transaction that automatically sends the 10,000 satoshi back to her address after a month. This is your insurance. So if there are problems with Bob, Alice will get her money back after a month. So Bob could “hold the 10,000 satoshi hostage” for a maximum of one month—not forever. 

On the one hand, Alice has now opened a payment channel to Bob, on the other hand, she has a guarantee that she will get her money back in a month at the latest. How does this payment channel work now? 

When Alice comes to Bob’s coffee shop in the morning, she has 10,000 satoshi in the payment channel and Bob has zero satoshi. Alice pays for her coffee by updating the channel status. To do this, she creates a transaction within the multi-sig wallet that would only send her 9,000 satoshi and Bob 1,000 satoshi. She signs this transaction and sends it to Bob. Bob now has a signed transaction from Alice for the 2-2 multi-sig wallet. That means he could decide to add his signature as well and then write this transaction (9,000 satoshi to Alice, 1,000 to Bob) in the blockchain. However, he doesn’t do that because he knows that Alice will be back tomorrow. The certainty that he already has a signed check from Alice is enough for him.  

The next morning, Alice comes back to the store to buy coffee. Again she pays through the payment channel. So, she creates a new transaction in the multi-sig wallet, which now only sends her 8,000 satoshi and sends 2,000 satoshi to Bob. She signs this transaction and hands the metaphorical check to Bob. This incremental update can continue until the locktime expires. Or until Alice runs out of money left in the channel to spend. 

The term “off chain” is also explained in this context. Alice pays Bob with bitcoin, but these payments don’t touch the blockchain directly. They happen outside the blockchain (off chain).  

So the advantage is that Alice can buy her coffee every morning. She doesn’t do this with a transaction on the blockchain, but with a check for Bob, which he can cash at any time. Before that, Alice has to top up a kind of pre-paid account from which she can then deduct the individual transactions. When Bob cashes the check, or when the lock time expires, the payment channel is closed. A transaction is written to the blockchain and distributes the remaining money to Alice and Bob accordingly. 

There are only two transactions in the blockchain. Once the transaction that financed the multi-sig wallet and once a transaction that closes the payment channel. But between those 2 transactions on the blockchain, a million or more small transactions could have happened between Alice and Bob.  

If a payment channel is closed, this is referred to as a  settlement transaction . The settlement transaction is written and minded on the blockchain.

So far, however, we have only considered a unidirectional payment channel. So if Alice only sends money to Bob (like when buying coffee). But if the whole thing is also supposed to work in the other direction, things get a little more complicated. 

Commitments – When channels should go both ways 

In order to lay the foundation for the Lightning Network, bidirectional payment channels are required. 

A  two-way payment  channel is a channel where money can flow in both directions.

However, these payment channels must also be established “trustlessly”. That is, neither party can gain anything from cheating and no third party arbitration is required.  

For example, one scenario would be that Bob writes an  old  state of the payment channel to the blockchain. If Alice had already accepted the payment in the payment channel and Bob had given goods or a service to Bob, she would have been cheated of her money. Of course this must not happen. Therefore, bidirectional payment channels require an extra step. Cryptographic protection must be established for both parties so that participants cannot revert to old payment channel states with impunity.  

Recap  –  additional information] Why is this scenario not a problem with unidirectional payment channels? In the one-way payment channel, only Alice pays Bob money. In return, she hands Bob a check signed by her with the current status of the channel. At no point does Alice receive a signed check from Bob. This means that she cannot make a transaction from the multi-sig wallet, which requires two signatures. Bob, on the other hand, only ever gains more money with new transactions. Out of economic self-interest, he would not write an old state to the blockchain, as this would mean he would receive less Bitcoin than Alice actually wrote over to him. So in one-way payment channels, it’s always best for Bob to post the latest. 

Bidirectional payment channels are structured and secured as follows:  

Alice and Bob want to establish a two-way payment channel. To do this, the two parties must first agree on an opening transaction (funding transaction) with the respective amounts. So how much each pays into the channel. In our example, Alice deposits 10,000 satoshi and Bob deposits nothing. Alice sends the 10,000 satoshi to a 2-2 multi-sig wallet. For this wallet, Alice has one key and Bob has the other. Both must therefore sign for a valid transaction on the blockchain. If Bob disappears, Alice can get the money back after a certain time. 

Now Alice wants to use the payment channel and send Bob 1,000 satoshi. A second multi-sig wallet comes into play for this. After the funding transaction has taken place, Alice creates a new transaction where they send 9,000 satoshi to an address she controls and 1,000 satoshi to the new multi-sig wallet. Two signatures are again required for this new multi-sig wallet. One belongs to Alice, the other is a temporary new address for Bob. In addition, this transaction has a time lock, so it can only be spent after an elapsed period of time. So far so good. Bob could now decide to sign with his temporary signature and thus close the payment channel. Or he waits for the next update of the payment channel.  

Bob now wants to send 500 satoshi to Alice via the same channel. To do this, he must reveal his previous signature by sharing the associated private key with Alice. He then creates a new transaction where Alice gets 500 satoshi and 500 satoshi still goes to Bob. For this transaction, a temporary, new signature is required from Alice and a signature from Bob. This transaction is again time locked so Bob gets his full 1,000 satoshi if Alice doesn’t respond.  

However, since it is a two-way payment channel, a step must be taken before the commitment transaction. You have to come up with the secret, the pre-image, and exchange it.  

In practice, the wallet does this and the user does not notice much of the process. In general, however, you can imagine it like this. The wallet application generates a random, large number. This is the pre image. Then the wallet application hashes the pre image. That’s the hash. Before the payment channel can really get going, both participants create such a pre-image and the associated hash. They exchange this hash with each other. Now everything is ready for the two-way payment channel. 

Alice now sends Bob 10,000 satoshi by again signing a check to the multi-sig wallet. This check pays her 49,990,000 satoshi and Bob pays 50,010,000 satoshi. It is therefore a commitment transaction. But this transaction is special because it is provided with a hashed timelock contract. That means Alice uses the hash that Bob gave her and says “whoever can prove that they know the pre-image for this hash can resolve the HTLC.” The other possibility of making a transaction is that a certain period of time elapses . With an HTLC, this time is given in blocks (a block lasts about 10 minutes).  

Bob can get his money at any time. To do this, he resolves the payment channel in a settlement transaction by presenting his pre-image in the transaction. Alice can’t do that because she doesn’t know the pre image. Should Bob not cooperate with Alice and try to “hold” the money hostage, he can only do so until the time lock expires. If he hasn’t closed the channel and claimed his money by then, Alice can get all her money back.  

If the balance in a payment channel is changed, i.e. one party gives up more Bitcoin, this is also referred to as a  commitment transaction . Commitment transactions are not written to the blockchain. 

Lightning Network – Channels become a network 

Now we understand the technical basics for the Lightning Network. But how does it come from a bidirectional payment channel between Alice and Bob to the network between all participants? 

A  Hashed Timelock Contract  (HTLC) is a class of transaction that must meet a specific condition in order to be valid. More specifically, the sender must either provide cryptographic proof or wait until a specific date.  

The HTLC consists of two components, on the one hand the secret (Secret) and on the other hand a time lock. The secret is a random number hashed using a hash function. The initial number used to create the hash is also called  Pre Image .  

The  Pre Image  is a random number that serves as a secret for an HTLC. Anyone who knows the pre-image for an HTLC has the cryptographic proof to make a transaction. 

Previously, participants would have to set up a new channel for each new payment activity. So if Alice wants to do business with Carol, both business partners would have to set up a payment channel. This is where the Lightning Network comes in – payments could be routed through the individual participants. Instead of Alice creating a new channel with Carol, she instead uses existing channels between her and Bob and Bob and Carol. In this case, Bob acts as an intermediate step, as a  hop , between Alice and Carol. 

Lightning Network

The  Lightning Network  is a routed network of bi-directional, end-to-end payment channels. This means that the participants can send each other payments from channel to channel without having to use an intermediary. 

The critical reader is puzzled here: ” For a moment, the money goes from Alice via Bob to Carol – isn’t that exactly the trustee model that wants to replace Bitcoin ?” 

The Lightning Network is not a trust-based escrow model. Even if the payment finds its way to Carol via Bob, Bob never has control over Alice’s money. This is made possible by advanced cryptography. Just the mechanism of bidirectional, trustless payment channels, the Hashed Timelock Contracts (HTLC).  

This process guarantees that nobody in the chain of payment channels can cheat, or that cheating does not pay. It works like this: Carol thinks up a secret, again a random number. Carol passes the hash on to Alice. This hash now becomes a pledge: Bob receives a payment if he knows the secret. Alice can check this using the hash. Bob passes on the hash, again promising to pay if the recipient reveals the secret. In principle, the path between Alice and Carol can contain other participants, all of whom use the hash as a pledge. In the figure, only a simple network of three parties has been formed. 

HTLCs can be used to connect payment channels between different parties. You can see: Participants in the network, who form a bridge between Alice and Carol as nodes, are the backbone of the Lightning Network. Their importance can be compared to that of the miners on the regular blockchain. 


The blockchain continues to play a central role in the final settlement of payments and thus for the global consensus. It is secondary whether it is actually the Bitcoin blockchain: The Lightning Network can also interact with other cryptocurrencies such as Litecoin. This is how you can finally  realize Atomic Swaps  . A channel is opened here, the final settlement of which is stored on different blockchains. 

– regardless of whether Carol and Bob have already exchanged bitcoins with each other or not. Peer-to-peer would be skewed to one extreme and thus totally inefficient. One approach would be for participants in different payment channels to pass on transactions. Alice would be able to send money to Carol through Bob. The question is can you trust Bob. On the one hand, he could claim the money and simply not pass it on, on the other hand, Bob’s Lightning Node could fail. 

Challenges with the Lightning Network 

The practical implementation of the Lightning Network is far from being ready for this technology to be used by a large number of people. The network is currently in an experimental phase. To use it, it is essential to have a healthy understanding of technology. But even then it can lead to the loss of your own Bitcoin. In short: Even if the approach and the idea are already clear, there are still many construction sites.  

One of the biggest construction sites – and one of the most frequently mentioned points of criticism against the Lightning Network – is the routing. When a network consists of payment channels, the payment has to find its way through the network. However, the routing method is not specified in the Lightning Network white paper. Lightning Network critics say this is an unsolvable problem. Eventually, new nodes would come online all the time and others would go offline. The mere requirement that you have to be online to receive a transaction deters many from the Lightning Network. So it’s a step backwards instead of forward, because with Bitcoin, the recipient does not have to be online to receive payments. 

So the technological status of the Lightning Network is still immature. For widespread adoption, the technology must be easy and safe to use. At best, the user does not even notice that he is interacting with the Lightning Network and payment channels. However, it will probably take a few more years before that happens. Last but not least, the experiment could also fail.  

Experience Lightning Network in your own wallet 

The Lightning Network is not ready yet. There are now over 2,000 Lightning Nodes. Nevertheless, there is no guarantee that two users can actually set up a payment channel. So there is still a lot to do. True to the motto “Be your own bank”, everyone can help: particularly ambitious ones can set up their own Lightning  Node . 

But you can still enjoy the Lightning Network without downloading the entire blockchain. If you want to experiment quickly, you can  use as a web wallet  . With  Zap  and the  Lightning App  there are two desktop wallets. After all,  Eclair  even has a mobile wallet for Android users. As described elsewhere,  Coingate is  a service with which you can quickly allow transactions via the Lightning Network in your own web store. 

You can see that there is a lot going on.  

We will be happy to hear your thoughts

Leave a reply

Give Me A Ninja
Register New Account
Reset Password
Compare items
  • Total (0)