• Market Cap
    $402.172B 1.15%
  • POW Market Cap
    $309.671B 0.32%
  • POS Market Cap
    $20.113B 0.81%
  • Masternodes Market Cap
    $1.245B -0.82%

Lightning Network, a solution to increase crypto adoption

By Inkarias - 2019-11-15

After several years of research and development, the Lightning Network, a secondary layer of the Bitcoin protocol, is now completely functional and have been deployed on several chains. This sophisticated technical solution makes it possible, among other things, to greatly improve the scalability of the network. Overall, it is considered as the best answer to Bitcoin's scalability problems related to bullish trends as we have seen in 2017, but more importantly, to help increasing general adoption. In this document, we will introduce the principles, functioning and the different implementations of lightning network already in place within the crypto sphere.

What is the Lightning Network?

earth network

The Lightning Network is a decentralized system for performing instant, high-volume micropayments on blockchain while removing the risk of delegating the escrow of funds to trusted third parties.

Bitcoin, by design, has some limitations:

The delay of confirmation of a transaction on the blockchain is at least ten minutes; and it is considered that six confirmations are necessary for optimal security. These elements are right when the market is stable with not too much transactions in the network. During high-volume periods, the network tends to be slower with transactions time taking sometimes more than 1 hour.

The fees are variable and are not suitable for micro-transactions that are of the order of a few cents.

The Lightning Network circumvents these limitations by judiciously using Bitcoin's scripting system, which makes it possible to create conditional payments (smart contracts, multi-signatures) and ingenious cryptographic tools.

History of lightning network

The Lightning Network is the result of a long reflection. The idea of creating payment channel networks operating off the backbone in order to preserve the use of the network's resources, enabling its large-scale use to make instant payments at minimal cost goes back to many years.

The starting point is an idea of Satoshi Nakamoto himself, who in one of the first versions of the source code, suggests a method to update transactions that are not yet confirmed on the blockchain: it is about a basic payment channel where the balance of an address is changed several times out-of-line before a final transaction is entered into the chain and validates the final balance of the addresses concerned by the transaction. However, even if today this vision has been implemented in several chains, the initial development took years before reaching a stable system.

  • During summer 2011, "hashcoin" described the basic operation of a payment channel based on multi-signatures using a timelock (time-out), thus not compromising the funds of the parties if one some of them did not respect his commitment. The operation of this payment channel was, however, unidirectional.
  • In 2013, Mike Hearn published in a mailing list a more detailed explanation of the functioning of payment channels such as suggested by Satoshi, thus revealing some of his private exchanges with the creator of Bitcoin.
  • In April 2013, another description of a payment channel was introduced by Jeremy Spilman, improved by Mike Hearn and then coded by blockstream co-founder Matt Corallo in mid-2013.
  • In 2014, Alex Akselrod proposed a first bi-directional payment channel by playing timelocks, but it was never implemented for real use.

The idea of payment channels is therefore old but creating a network of off-channel payment channels, without relying on third parties, was harder to conceptualize and create. Several experts have been working hard to develop the Lightning Network implementation as we know today:

  • A first system was created by the mathematician Meni Rosenfeld during the summer of 2012. A payment processor had to perform off-channel exchanges between different pairs of users. This solution was considered too centralized by the community.
  • In 2014 and 2015, several proposals were made to solve that problem. Among the contributors are Peter Todd, but also the historical payment processor BitPay or the Swedish startup Strawpay.
  • It is again Alex Akselrod who proposed a trustless solution of networks of payment channels; but since it was based only on timelocks to ensure the repayment of users, its implementation was not convenient.
  • In 2015, Corné Plooy, who had been working on the development of this Bitcoin sub-layer for several years, proposed a trustless version of his system, Amiko Pay; however, to ensure the decentralization of the system, a hard fork of Bitcoin was needed, especially to add the possibility of making some transactions reversible, which was very unlikely to be accepted by the community.
  • Christian Decker (researcher at the Technical University of Zurich and now at Blockstream) also proposed with Roger Wattenhofer a two-way payment channel network system based on timelocks and an ingenious cryptographic mechanism (invalidation tree).

Finally, two hyperactive researchers/developers in the crypto community provided the Lightning Network's whitepaper in January 2016, Joseph Poon and Thaddeus Dryja, offering an unprecedented solution for this type of transaction.

How the Lightning Network works

Before going further into the technical aspects of the lightning network, it is important to understand how to two-way payment channel works between two different parties. This payment channel must operate and respect the desired properties (speed, very low cost and decentralization). For that, the totality of the exchanges between two persons which will be carried out on the channel will be summarized in only two transactions on the blockchain: one serving to open the channel to finance it, and the other to close the channel and to credit both parts of their final balance once the exchanges are done.

Some important notions before starting

The UTXO model: the state of the Bitcoin blockchain at a fixed instant is a set of "unspent outputs" (UTXO for Unspent Transaction Output). Each Bitcoin address has a balance that is the sum of all the outputs from addresses that have spent bitcoins to that address. A Bitcoin transaction therefore aims to modify the balance of an address by using the UTXOs of one or more addresses. In order to be valid, it must be signed by the owner of the private key associated with public addresses of entry. It is possible to create transactions that follow one another, signed or not, and to distribute them on the network. However, double expenses are prohibited: if it is quite possible to create transactions that spend several times the same coins present on an address, only one of them will be validated by the network.
Multisigs addresses: as their name suggests, these addresses, created with the P2SH system (Pay To Script Hash), require several signatures to spend the bitcoins stored there.
Cryptographic Secrets: A secret is a number used as a parameter in an encryption function, which is not known to the public. On Bitcoin, it is possible to use the hash of a secret chosen by a user to "lock" bitcoins: by adding this hash to an unspent output, you must know the secret itself to spend these bitcoins.
Hashed time locked contracts: These features of the Bitcoin scripting system allow to lock the outputs of a transaction during a defined period. There are two types:
  • CheckLockTimeVerify, which locks coins until a defined date and time (more precisely a block number);
  • CheckSequenceVerify that locks the coins for a defined period (in blocks), starting from the transaction's registration on the blockchain.

To make payments out of the main chain, the solution is to put bitcoins under escrow, in a 2-2 multi-signature wallet (which is a basic smart contract where exactly two signatures must be used for a transaction to be validated by the network). Once the bitcoins are in escrow, users will exchange signed "promises of exchange" and not bitcoins directly. The final balance that will be credited to the addresses of the parties involved will be updated based on these transaction promises, and when one of the users wishes to make these transactions effective, the channel will be closed, and the resulting transaction representing the last state of the channel accepted by both parties will be broadcast on the blockchain.

In more details, the system includes two major steps (but also several operations) to ensure the reliability of the different sides and to bring the transaction within the main chain.

Temporary escrow on ouput transactions

The balance exists in two copies for each operation. Each copy is completed by one of the parties and then signed by the party and exchanged. To ensure the safety of the system, each copy handicaps its owner via an ingenious system so that it is not made to cheat. For this, the balance stipulate that the owner will receive his bitcoins 1000 blocks after the transaction on the blockchain. The other party will receive them immediately. With this system, if one of the parties’ sign and broadcast a transaction, the other side has 1000 blocks, or a week, to penalize it in case of cheating.

Exchange of "secrets" and hashes to release of funds in escrow

A secret is generated by each party with each new version of the balance sum up, thus with each off-chain transaction. A hash function is then applied to this secret. The resulting hash, which can be compared as a unique digital fingerprint of the secret, is given to the other party. The secret allows to unlock and recover 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 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.

The lightning network as a wide payment channel network

To build secure payments with transactions that will pass through multiple channels before reaching their destination, it is important to use the 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 set 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.

Implementations

There are currently several variants of the Lightning network and are based on the Lightning Network's standard specifications, known as BOLTs:

Lighning-C: This is the implementation of Elements Project, a developer community supported by Blockstream.
Lightning Network Daemon (LND): Developed by Lightning Labs and coded in GoLang. A developed system, Neutrino, is a platform allowing mobile users to use a thin client for Lightning payments.
Some Lightning Apps ( LApps) have been developed by Blockstream and remain available on Elements github : https://github.com/ElementsProject. All the development was focused on bringing reliable apps with real use cases in various sectors :

Trade:

  • Nanopos - A simple point-of-sale system for fixed price goods.
  • WooCommerce Lightning Gateway - An e-commerce application integrating inventory management and order tracking.

Creation and distribution of content:

  • FileBazaar - A system for selling files (documents, images, videos ...)
  • Lightning Publisher for WordPress - A system for micropayments unlocking WordPress tickets.

Micropayments:

  • Paypercall - Programmer Toolbox - micropayments for individual calls to an API.
  • Ifpaytt - Extension of Paypercall allowing web developers to use IFTTT to request micropayments to use a service.