Lightning Network: A Technical Introduction

This article is dedicated to those who are particularly interested in understanding the operation of the lightning network on Bitcoin.For those who are looking for a « less technical » introduction to the Lightning Network, click on this link.

We seek to understand the mechanisms allowing the Lightning Network to exist on bitcoin while guaranteeing a maximum level of security to the users.

• What is a payment channel?
• How do transactions on Lightning Network work?
• How is confidentiality ensured on the network?

These are some of the questions that this article will answer.

Payment Channels and Security

Bitcoin’s network security is provided through a transaction validation system that requires transactions to be registered on the Bitcoin blockchain. On the contrary, Lightning Network transactions are not recorded immediately on the Bitcoin blockchain, and we refer to them as off-chain transactions.

It is therefore legitimate to ask whether these are as secure as conventional Bitcoin transactions. The answer is yes. But how?

It is important to understand two things:

1. A payment channel is a Bitcoin transaction

• One of these is the possibility to configure a Bitcoin address from several addresses in such a way that the funds stored at the said-address can only be spent if the number of signatures generated is equivalent to, or higher than that of participating addresses. This is called a multi-signature address.
• Payment channels are multi-signature addresses with only two stakeholders; two signatories are required to spend the funds.
• Depositing funds on this multi-signature address constitutes the opening of a payment channel, whereas spending it represents the closure of the channel.

1. An off-chain transaction in a payment channel is an update of the statement of accounts that takes the form of distributable transactions that are, however, not distributed on the Bitcoin blockchain.

Let’s see how such a system works.

1.   A payment channel is created by depositing funds on a common multi-signature address. The total amount of BTCs sent to the multi-signature address by the two initiators of the channel represents the total exchangeable value in the payment channel.
2. Each of the two initiators signs (in the form of a transaction that could involve all the funds available in the channel) an outbound transaction representing the initial state of the channel. However, instead of broadcasting this transaction on the Bitcoin blockchain, these two outgoing transactions will be signed by their issuer and exchanged between the two participants.
3. At each new transaction within the channel, a new outgoing non-broadcast transaction is created and then exchanged between the two parties. This new version replaces the previous one. Since each participant holds an outgoing transaction signed by the other party, they are able, at any given time, to add their second signature, which is needed to close the channel and recover the funds.

But how to make sure that the version broadcasted on the blockchain is the latest one?

After all, the two parties do not know each other specifically and do not necessarily trust one other. One of the participants could very well be circulating a previous version of the exchange that suits him better than the current one.

As such, two systems are employed to solve this problem:

1. Temporary fund escrow on outbound transactions

As we have seen, this “balance sheet” exists in duplicate for each operation. Each copy is completed and signed by one of the parties, then given to the other party.

To ensure the safety of the system, each copy binds its owner via an ingenious system that prevents any form of cheating.

For this, the balance sheets stipulate that the owner will receive his bitcoins 1000 blocks following the transaction’s broadcast on the blockchain. The other party will receive them immediately.

With this system, if one of the parties signs and broadcasts a transaction, the other party has 1000 blocks or more or less a week, as a penalty in case of cheating.

1. The exchange of “secrets” and hash functions allowing the release of escrow funds

A secret is generated by each party with each new version of the balance sheets, thus with each off-chain transaction. A hash function is then applied to this secret. The resulting hash, which can be seen as a unique digital fingerprint of the secret, is given to the other party.

The secret allows the instant unlock and recovery of the Bitcoins that belonged to the other party and blocked by the contract. It is not given to the other party.

When a new transaction is executed off-chain, the secrets of previous balance sheets are exchanged between parties. This means that in the future if one of the parties wants to broadcast a previous record on the Bitcoin blockchain, the other party will be able to recover all bitcoins of the channel before the 1000 blocks have elapsed.

Thus, everyone can decide when he wants to broadcast the transaction corresponding to the closure of the channel on the bitcoin blockchain, knowing that he has a good reaction time if the other channel participant is trying to cheat.

If none of the parties are broadcasting the transaction, then the channel remains open, whereas if the transaction is broadcasted, the channel closes and the parties retrieve their shares from their respective Bitcoin addresses. The channel can remain open indefinitely.

This is how the payment channels are kept secure. 

Below is a graphic illustration of these mechanisms:

• A and B represent the users
• S represents the secret number generated during each engagement transaction
• H is the hash function of the secret

LIGHTNING NETWORK:  A PAYMENT CHANNEL NETWORK

The concept of payment channels is not new. Their basic operation was described in 2011 by the user hashcoin, then revamped by different actors of the Bitcoin community since then.

That being said, we had to wait for the Lightning Network to propose a functional system, without a trusted third party, and a decentralized networking of these channels.

Indeed, a payment channel, as described in the first part of the article, makes it possible to secure payments only within the same channel.

To build secure payments with transactions that will pass through multiple channels before reaching their destination, one last element is needed: The Hashed TimeLocked Contracts.

The HTLCs allow special transactions to be set up through escrow funds and the secret/hash system.

This is how a Lightning Network transaction happens, with A and D wanting to make a transaction through B and C:

• The final receiver D creates a secret. He generates a hash function for this secret (H) and gives it to A, the payer. H is used at each step to build the HTLCs.
• A sets up an HTLC, a special transaction that has the following features: A will pay the total amount of the transaction to B if and only if B is able to provide the hash (H) secret at the given time. If B is not able, to do so then the transaction is canceled and A recovers the funds from the contract. A cannot recover the amount of the HTLC before the end of the countdown.
• Automatically, B implements the same type of contract with C.
• C does the same with D. Only, as D holds the secret, he is able to provide it to C and thus, he can trigger the payment of C. D recovers the funds by giving the secret to C. C now knows the secret.
• C can, therefore, recover funds from B, and B then recovers funds from A.
• The payment is completed.

Thus, from the moment the HTLCs are set up along the payment chain, each link is guaranteed to receive the payment of the previous link. Having to retrieve the hash to trigger the payment of one link to the next ensures that in case of non-cooperation, each link will recover its funds once the countdown of the HTLC contract has expired.

It is important that the HTLCs end time decreases at each stage of the payment chain so that each link can have the guarantee that he will either be paid or recover his funds.

Intermediate links in a payment chain may eventually set commissions to be paid for their services. But beware, it is in their best interest to remain very competitive as each payer naturally follows where his transaction leads.

IMPLEMENTATIONS AND INTEROPERABILITY

Different companies are working on the Lightning Network and developing their own implementations of the technology. Here are some examples :

• Lightning Network Daemon – LND – The Lightening labs
• Eclaire d’ACINQ
• C-Lightning – Blockstream

A little over a year ago, the various groups that developed the Lightning Network, whether companies or Open Source projects, came together and put in place a set of common interoperability standards.

These standards are known as BOLT (Basics of Lightning Technology). They define how the various implementations will interoperate so that the various tools developed work with each other, regardless of the selected implementation.

One of these common standards is the Onion Routing Protocol.

ONION ROUTING PROTOCOL AND CONFIDENTIALITY

The Onion Routing Protocol, implemented to run the Tor network, helps to ensure increased privacy on lightning payments.

This name was given because the payment information is wrapped in different layers, like an onion. At each stage of the chain, only one layer is unveiled at the knot that routes the payment.

Thus, a given knot is only able to see its two “neighbors” in the payment chain. If we once again consider the diagram given above, B only sees A and C, but not D.

The information routed inside this “package” will give the impression to each knot that there are 20 steps on the payment chain. This is the maximum number of links possible in a lightning payment chain. It is therefore impossible for a knot to know a payment final destination.

When the knot opens this package, it finds the information required to proceed to the next step of the chain. Only the last knot can see the last step when it opens its package.

Through this process, the knots have no way of knowing how many knots have been used before them and how many knots will be used in this payment chain. They do not know where the other knots are.

Only the payor and the receiver know how the size and location of the chain.

In conclusion, the Lightning Network is a clever technology that has been discussed and developed for many years.

In March 2018, the LN was finally deployed on the mainnet. It was a long-term job: first, we had to implement the SegWit protocol enhancement to make this possible.

The implementation of such a system showed that Bitcoin’s capacity had to evolve and eventually impose itself as a value transfer system to be used by the masses. The fields of application are numerous.

Sources

• White Paper par Lighting Labs: https://lightning.network/lightning-network-paper.pdf
• Article de Bitconseil sur Lightning Network : https://bitconseil.fr/bitcoin-lightning-network-histoire-fonctionnement/
• Répertoire des LApps: https://dev.lightning.community/lapps/
• Vidéo d’Andreas Antanopoulos sur Lightning Network : https://www.youtube.com/watch?v=c4TjfaLgzj4&t=558s