Lightning Network is defined by many as the protocol that will improve bitcoin and make it usable as a means of payment for the general public. Today, Bitcoin has several problems due to the limited capacity of its blockchain that prevent it from being suitable for potential mass use of micro-payments.
The first problem is the huge issue with scalability and the number of transactions, which is fixed at about 7 transactions per second. The second problem is related to fees. In fact, during periods of great congestion, as occurred in December 2017, the fees paid to the miners for confirmation increase significantly.
In December 2017, in order to pay for a coffee with bitcoin, it was necessary to pay about twenty euros in fees, thus resulting in a payment system that was decidedly unusable.
For this reason, over the years an additional layer has been developed to complement the bitcoin blockchain, so as to increase scalability, usability, speed and reduce commission costs. This layer is precisely the Lightning Network.
Characteristics of the channels and the Lightning Network
In order to solve these problems, Lightning Network executes some transactions off-chain, which means that they are not carried out on the bitcoin blockchain. The concept takes advantage of the creation of a channel – evolution of the Payment Channel – between the two participants in the transaction who exchange money.
In essence, the transactions carried out on the dedicated channel take place instantly without any transfer to the blockchain. Only the opening and closing transaction will be sent to it.
Through the use of these channels, it is also possible to create a particular type of smart contract between the two members of the channel. In addition to all these advantages, with Lightning Network there is the theoretical elimination of fees.
Unconfirmed transactions
The Bitcoin protocol essentially consists of transactions related to previous and future transactions. Each transaction contains inputs, which refer to the addresses from which the bitcoins are sent, and outputs, which refer to the addresses to which they are sent. In addition, the inputs must include the requirements for sending bitcoins, i.e. signatures that demonstrate the ownership of the input addresses. Meanwhile, the outputs establish the new requirements, which must be included in the input of a subsequent transaction.
One of the main features of Lightning Network is that it consists of more or less regular bitcoin transactions. These transactions are usually not transmitted over the bitcoin network. In fact, they are stored locally in the users’ nodes, but can then be transmitted at any time over the network.
The example in the picture shows how Alice can sign and broadcast unconfirmed transactions, so as to send two bitcoins to Bob. But it is only after Alice has broadcast that Bob will be able to send one of the two bitcoins received from Alice to Carol.
Protection against double spending
Lightning Network also includes a protection mechanism against double-spending, i.e. the attempt to spend money several times. In fact, if two transactions are based on the same output, only one can be confirmed.
Unconfirmed transactions may conflict, which means that only one can be confirmed, thus avoiding the so-called double-spending.
In the example shown, Alice has to decide which transaction to sign and transmit. She will not be able to sign both, because if she does, only one of them will actually be confirmed.
Multi signature
The third basic element of the Lightning Network is multi-signature addresses, also known as P2SH addresses.
Multisig addresses are Bitcoin addresses that – as the name suggests – require multiple private keys to unlock and spend bitcoin. They can be set in any configuration.
The Lightning Network often uses two out of two (2-of-2) multisig configurations. Unlocking bitcoins from 2-of-2 multisig addresses therefore requires two signatures, from two dedicated keys.
In the example in the figure, Alice and Bob have created a multisig 2-2 address of which they both hold a key. When Alice tries to spend the bitcoins from that address, she won’t be able to because Bob will also have to sign the transaction. It should therefore be noted that once a transaction has been signed, it is no longer possible to change its content, as it is marked by an immutable cryptographic function.
Timelocks
Timelocks can block incoming or outgoing bitcoins, so that they can only be spent at a certain time in the future.
There are two different types of timelocks: the absolute one, called CheckLockTimeVerify (CLTV), and the relative one, called CheckSequenceVerify (CSV). CLTV blocks bitcoins up to a defined time: actual time and date, or a specific number of blocks. CSV, on the other hand, uses the relative time. Once a CSV output is recorded on the blockchain, from then on a specific amount of blocks must be generated before the bitcoins can be spent again.
In the example in the figure, CSV is applied. Alice will have to wait for the generation of a thousand blocks before she can get the two bitcoins and send them to Bob.
Hash and secrets
The last part relating to channels concerns cryptography, a fundamental part of all cryptocurrencies. However, with the Lightning Network, it is applied in a slightly different way.
A cryptographic function is a mathematical algorithm that maps data of arbitrary length (message) into a fixed size string called hash or digest. This hash function is designed to be unidirectional, meaning that it is difficult to reverse: the only way to recreate input data from the output of an ideal hash function is to attempt a brute-force attack of the possible inputs to see if there is a match.
Encryption in the Lightning Network can be used to freeze bitcoins. For example, a hash can be included in an output so that the next input is only spendable if it includes the secret key (which from now on will be called secret) related to the actual verification.
Creation of two-way payment channels
The concept of payment channels has long been in use thanks to the Payment Channel system. Classic payment channels are useful for certain purposes, but also limited, as they are unidirectional. Using the examples above, Alice can pay Bob several off-chain transactions, but Bob cannot pay Alice through the same channel.
Lightning Network, therefore, introduces one of the key concepts of such a system, namely the two-way payment channels, which are safe and reliable.
How to open a channel
To create a two-way payment channel, both parties involved must first agree on an opening transaction. This opening transaction determines how many bitcoins are deposited in the channel by each of the two parties.
In the example, Alice wants to send a bitcoin to Bob. Since Alice and Bob expect to trade frequently, they decide to open a two-way payment channel. In this example, whole quantities of bitcoins will be used, but it is obviously possible to perform the same operations even with small fractions of BTC. The system should therefore also make bitcoin suitable for micro-transactions.
To open the channel, Alice and Bob send five bitcoins each to a multisig 2 of 2 address. This is considered as the opening transaction. Bitcoins can only be spent outside this address if both Alice and Bob sign the transaction. Also, both Alice and Bob create a secret, a string of numbers, and exchange the corresponding hash.
Alice now creates a transaction after the opening operation, i.e. a commitment operation. With it, Alice sends four bitcoins to herself and six bitcoins to a second multisig address. This second multisig address can be unlocked by Bob alone, but only after 1000 BTC blocks have been extracted. A practical application of the CSV timelock thus comes into play.
Alternatively, it can be unlocked by Alice, but only if it also includes Bob’s hash. Alice will then sign her conclusion of this operation without carrying out the broadcast.
Meanwhile, Bob does the same thing, but in a mirror-like way. He also creates a commitment transaction, from which he sends six bitcoins to himself, and four to a new multisig address. Alice can only unlock this address after 1000 blocks, or Bob can do it using Alice’s hash.
After these exchanges of “semi-valid” commitment operations, both sign the transactions and transmit the opening operation to the blockchain to ensure that it is recorded. At this point the channel is finally open.
From now on, both Alice and Bob can sign and submit transactions between themselves. If Alice does, Bob gets six bitcoins immediately. If Bob does, Alice gets four bitcoins immediately. However, the person signing and disseminating the transaction will have to wait 1000 blocks to unlock the next multisig address and claim the remaining bitcoins.
As a result, the mechanism underlying the payment channels emerges: neither of them signs and transmits their part of the transaction completely.
Updating the channel
The next step is for Bob to want to return a bitcoin to Alice. The channel status is then updated to return the balances to their initial state, i.e. five bitcoins each.
First, they both repeat the process described above by skipping the opening transaction step. This time, both Alice and Bob are attributed five bitcoins each and five to a new multisig address. The conditions of the new multisig are similar but require new secrets: both Alice and Bob exchange hashes. Both then sign their new commitment transaction.
The second step is for Alice and Bob to exchange the first secret used in the opening phase of the channel. In so doing, they both possess each other’s secrets.
At this point, once again, both Alice and Bob were able to sign and submit the new commitment transaction that has just been concluded. Their counterpart will immediately receive five bitcoins, while the signatory will have to wait for 1000 blocks. The channel has thus been updated.
However, the question arises: what is stopping Bob from transmitting the old transaction so that he can get six bitcoins instead of five? It is his first secret, now owned by Alice, that prevents Bob from doing this.
As a result, Bob can no longer sign and transmit the old transaction because Alice knows Bob’s first secret. If Bob signed and transmitted that transaction, he would immediately send four bitcoins to Alice and would have to wait 1000 blocks to claim his six bitcoins. But since Alice now has the secret, she could use the waiting time of the thousand blocks to sign the old transaction and then claim the other six bitcoins in addition to the four she has already received.
And since Bob also has Alice’s secret, he can perform the same procedure. If Alice tries to sign and transmit an old transaction, Bob can steal all the bitcoins in the channel.
This therefore implies that both Alice and Bob have a strong incentive to sign and broadcast only the latest state of the channel. A real fair play and mutual trust mechanism.
Construction of the Lightning Network
After introducing the basic concepts related to the functioning of the channels and features offered, here is how, by bringing together multiple channels and users, it is possible to build a real network.
Previously it was explained how payments between Alice and Bob are made, now it will be shown what needs to be done to introduce a third person, Carol, into the system. The easiest and most obvious way is to open a channel between Carol and Alice. However, if it is already known that Bob and Carol have already opened a channel between them, there is no need to create a new channel, as Alice can simply pay Carol through Bob.
In fact, Alice can pay Bob a bitcoin, and Bob can pay Carol a bitcoin. Obviously the operation cannot be done in such a purely trustworthy way. It might be the case that Alice pays Bob but then Bob doesn’t pay Carol. Or that Bob pays Carol, but that the latter claims to have never received anything, making Alice unable to find the culprit.
This operation of passage using Bob’s channel can be done through a simple cryptographic trick. When Alice wants to send a bitcoin to Carol, she alerts Carol, telling her to create a random string of numbers and send her the corresponding hash. Alice also tells Carol to exchange the original numeric string with Bob for a bitcoin.
In the meantime Alice receives the hash from Carol and reports to Bob that she will give him a bitcoin if he gives her Carol’s numeric string, which however is still only in Carol’s possession.
So Bob gives Carol a bitcoin for the number string. Then Bob goes back to Alice with the string. At this point, Alice knows that Bob must have gotten the string from Carol in exchange for a bitcoin, and therefore concludes that Carol got his bitcoin. So Alice can easily pay Bob a bitcoin.
However, in the situation that has just been hypothesised, Bob must have confidence in both Carol and Alice. He must trust Carol to deliver the numeric string to him in exchange for a bitcoin, but he must also trust Alice, who will pay him a bitcoin only after delivering Carol’s string to him.
The exchange of bitcoins for numeric strings must take place with the absolute certainty that those who act as intermediaries will then be repaid. That’s where the Hash Time-Locked Contracts (HTLCs) come into play.
HASH TIME-LOCKED CONTRACTS
Alice and Bob want to trade a bitcoin for the string through a HTLC. At the same time, Bob and Carol want to exchange a bitcoin for the same string.
To do this, instead of sending a bitcoin directly to Bob, Alice sends a bitcoin to a new multisig address. Bitcoins locked to this address can be unlocked in two different ways.
- The first option is for Bob to include his signature and the string he got from Bob;
- The second option is for Alice to include her signature. However, this option has a suspensive effect and will serve to recover the payment in case Bob does not provide the string. The system implements a CLTV-type timelock. Alice can sign and transmit the operation to regain the bitcoin only after – for example – two weeks.
This means that Bob has two weeks to create a transaction in which he includes his signature and string, and to transmit it on the blockchain, so as to redeem the bitcoin from the multisig address created by Alice. In this way, the exchange is guaranteed. Bob can only claim Alice’s bitcoin if he provides the string. He can then transmit it through the bitcoin network to make it publicly visible to Alice and get the payment.
In the event that Bob does not provide the string to Alice in time, at the end of the CLTV timelock Alice will regain her bitcoin and the HTLC contract will be destroyed.
In the case of the network, therefore, it is precisely for this reason that the use of HTLC contracts is necessary.
As mentioned, not only Alice and Bob, but also Bob and Carol have signed an HTLC contract. So if Carol claims her bitcoin from Bob, Bob will get the string in return. Everything will be transmitted and made visible on the network.
So if that happens, Bob is sure to get a bitcoin from Alice. Bob can then take the string that Carol has made visible on the network and include it in his HTLC with Alice. He can then claim the bitcoin for himself. The two channels were therefore actually connected.
However, there is one important detail, namely that Bob must get the string from Carol before Alice can retrieve her bitcoin from the HTLC with Bob. If Bob got the string after Alice had already recovered the bitcoin, Bob would be stuck in the middle of the transaction. Precisely for this reason, the time-out of Bob and Carol’s HTLC must therefore expire before Alice and Bob’s HTLC expires. That’s why HTLCs need the CheckLockTimeVerify (CLTV) and not the CheckSequenceVerify (CSV) seen above.
However, there is one more problem that needs to be resolved. To make Lightning Network really useful and fast, all these operations must be performed off-chain, so without synchronisation with the Bitcoin blockchain.
Merging the network and closing the channels
Now it will be explored how it is possible to take advantage of everything that has been introduced so far to make the system partially a-synchronous from the blockchain.
LIGHTNING NETWORK
So far, Alice and Bob have opened a two-way payment channel, both with five bitcoins. They have made two transactions, and, at the current state of the channel, both Alice and Bob can claim five bitcoins for themselves by forwarding the channel on the blockchain. Then it was examined how it is possible to include an HTLC contract in the channel. This serves to ensure that if Carol claims a bitcoin from Bob in exchange for his string, Bob is sure to get a bitcoin from Alice in exchange.
As in the previous step, Alice and Bob started by creating a new commitment transaction. In many ways, these commitments are very similar to previous operations. They include a normal output and an output to a multisig address with a CSV timelock and a special hash-lock. Similarly, as in the previous step, Alice and Bob exchange their old secrets to make the old state unusable. At this point, both Alice and Bob can sign their half-checked transactions and potentially transmit them on the blockchain at any time.
But something’s not right. Both Alice and Bob’s transactions include a new output of the value of a bitcoin. So the budget is not five bitcoins each but four for Alice, five for Bob, and one for the new output. This new output is HTLC and there are three ways to unlock it.
First, the new output (in both operations of Alice and Bob) frees the bitcoin on the condition that Bob’s signature and string (the one obtained from Carol) are included in the next transaction. Regardless of whether Alice or Bob signal and transmit the operation, only Bob can unlock this output. However, if Bob transmits the operations to the blockchain, he must respect the CSV timelock involved. He will then have to wait for 1,000 blocks before obtaining the bitcoin, while if Alice abandons the channel he can claim it immediately.
The reason why Bob has to wait 1,000 blocks if he transmits the channel is very similar to the one seen before: it allows Alice to redeem the bitcoin in case Bob tries to sign and transmit an old channel state. Then there’s the second way to redeem the exit. In the event that Bob transmits an old state, Alice can use Bob’s old key to steal Bob’s funds, who is performing an illicit operation.
Of course, the opposite may also be the case, namely that Alice is forwarding an old state of the channel. At this point, Bob, using the same trick, will be able to claim the pending bitcoin using Alice’s secret.
The third possibility consists, as in any HTLC, in the expiration of the CLTV timelock, which will then return the bitcoin to Alice. If Bob does not respect the time-out of the contract, Alice can claim her bitcoin and retrieve it. Again, it doesn’t matter whether Alice or Bob closes the channel.
Finally, as the last option, there is the case where Alice decides to close the channel forcibly. In this case, to recover her bitcoin, in addition to waiting for CLTV, she must also wait 1000 blocks since she transmitted the first transaction.
To sum up, both Alice and Bob have a half-validated commitment transaction. If Alice transmits her transaction to the blockchain, she immediately sends five bitcoins to Bob. She then has to wait for 1,000 blocks to redeem her four bitcoins. Whereas Bob has two weeks to provide the string and declare it in the output of the HTLC contract. Once done, he can then redeem that bitcoin as well.
Alternatively, Bob can transmit his transaction at any time and immediately send four bitcoins to Alice. So, after waiting for 1,000 blocks, he can claim the five bitcoins from the address and the sixth bitcoin from the HTLC output by providing the numeric string.
Of course, if one of them tries to cheat the other by signing and sending an outdated channel, they can both completely block the other one, and take over all the bitcoins in the channel.
STATE REGULATION
At this point, Bob is guaranteed to receive a bitcoin in exchange for the string, assuming he has it. All he has to do is sign, include the string and transmit the operation he got from Alice in a subsequent transaction. Alice can’t fool Bob in any way, even if she’d discovered the string by other means.
The two of them, however, may also make arrangements outside the channel. In this way, Bob can simply give the string to Alice, and Alice can update the channel status without HTLC and time-out. If both parties want to keep the channel open, this is the most immediate solution, as it is less problematic than transmitting the channel to the blockchain.
CHANNEL CLOSURE
Finally, this is why everything that has just been described will never need to be fully transmitted to the bitcoin blockchain.
If Alice and Bob want to close the channel peacefully, they can simply create a transaction from the original opening operation to cancel everything that happened after it. From this closing transaction, they send themselves their portion of bitcoins present in the channel, as indicated in the most recent state of the channel.
This means that if Alice wants to close the channel, she can simply create a transaction by allocating four bitcoins and the other six to Bob. She’ll then have to ask Bob to sign and forward the transaction, as it’s multisig 2-2. Since there is no reason not to do so, he will probably cooperate and close the channel.
In the end, only two transactions were transmitted over the bitcoin network and included in one block: the opening and closing transactions. This will also be the case if Alice and Bob make one million transactions. Only the opening and closing operation will be transmitted, while all the others will be executed without being transmitted on the blockchain, allowing Lightning Network to be immediate, fast and efficient.
Of course, these are only the basic concepts behind the logic of the Lightning Network protocol. On a technical level, there are many other ways to automate some of the above operations. However, for the entire technical part it is possible to consult the Lightning Network whitepaper.
The network is already being tested and used by thousands of entities and users. In fact, more than 8500 LN nodes are active on the network, for a total of 35 thousand channels and almost a thousand BTC capacity.
This system offers a valid solution to the main problems of the bitcoin network, including scalability, blockchain size, confirmation speed, reduced fees and more. It is slowly establishing itself as a second layer of bitcoin, flanked by the various improvements that will be introduced in the Bitcoin protocol. Among them are Schnorr’s signatures and Taproot, which in turn includes MAST, and perhaps even MimbleWimble. This will be followed by the Confidential Transactions using the BulletProofs, already active on Monero.
Finally, Lightning Network could also be used on other cryptocurrencies, as it is an additional layer that can be placed alongside a coin’s native blockchain.
