Lightning Network ⚡🕸

Explained in (relatively) plain English.

First, we discuss why we need it (part 0) and describe an idea of payment channels and Lightning Network (part 1). Then we introduce required building blocks (part 2) and see how these blocks can be used to create payment channels (part 3). We then finally build Lightning Network, discuss its properties (part 4), and sum it all up (part 5).

Disclaimer. I consciously omit/simplify some of the technical details. And also I am not an expert, and can be simply wrong.

0. Why?

Bitcoin blockchain is a kind of decentralized database that stores every bitcoin transaction ever made. Here “every transaction ever” is a fundamental part of the protocol design. For system to be truly distributed and to prevent any mistakes, thousands of network nodes need to constantly double check each other and to record all the transactions.

Of course, this does not help scalability at all. Blockchain requires tens of gigabytes of hard drive storage, blocks are full, fees are rising, people are angry and fork bitcoin. Because of all that, alternative solutions are currently being developed. And one of these solutions is Lightning Network (LN).

1. Idea

The idea of the Lightning Network, which belongs to a broader set of second layer solutions, is actually quite simple.

💡 Instead of storing and verifying all the transactions in the blockchain, let’s conduct most of the transactions “off-chain”. The main blockchain will mostly be used to synchronise the balances from time to time and to resolve conflicts. And as usual, this will all work using cryptomagic.

This sounds intriguing, but absolutely unclear how…

1.1. Payment channel

Let’s start with simplifying the lives of two people (Alice and Bob), who often transact between each other. The following scheme is proposed.

1. Alice and Bob send deposits to a special address. This address is jointly controlled by both of them using their two private keys.
2. Both Alice and Bob create a special smart contract transaction (yes, there are smart contracts in bitcoin, but more about that in the next part). This transaction is valid, but not yet recorded in the blockchain.
3. At first, the transaction contains information that Alice and Bob can get their deposits back.
4. When Alice is paying to Bob, they both by mutual agreement update the information in these transactions. Alice agrees to get less than her initial deposit, Bob — more. One can say for the sake of analogy that they are exchanging debt acknowledging documents (IOU, I owe you). But unlike most IOUs issued by banks, LN payments are fully secured and guaranteed to be immediately redeemable.
5. Like this, they can exchange small amounts (within the limits of their deposits) with each other, for as long as they both want.
6. At any moment in time any party can decide to square their balances. Then Alice (or Bob) just records the final version of their transaction to the main blockchain and they both get their deposits back (taking into account all the intermediate payments).

Points 1–3 in these plan are called opening the payment channel. Points 4 and 5 — using the channels. Point 6 — closing the payment channel.

👍 Only two transactions are recorded in the main blockchain: sending the initial deposits (to open the channel), and the final transaction (to close the channel). All the intermediate payments are conducted without blockchain synchronisation. This makes payments within channels free and instant.

1.2. Network of payment channels

Payment channels between two people per se are not super useful. Ultimately, we do not transact regularly with most people. But…

💡 When multiple payment channels form a network, any two people in this network can transact between each other. If there is a path between two nodes in the network, they can pay each other, even if they are not directly connected. This is the main idea of Lightning Network.

Mainnet LN: the graph of payment channels as of 22.01.2018 (https://lnmainnet.gaben.win).

Basically, analogous to TCP protocol, most people will need to have only one open channel to transact with anyone else.

Of course, there are many open questions left: how to find a path between two people, and how to motivate nodes to process payments. But let’s start with the main issue: the problem of trust.

1.3. The problem of trust

As it often happens in cryptography, the system of payment channels is easy to imagine when all the parties trust each other. There is no need in deposits, keys, special transactions. We can all just write down who owns whom and how much.

The question is: how to implement a payment channel and a network of payments channels without trust. There are going to be three main issues.

1. Both Alice and Bob store their deposit in a joined wallet. If Bob refuses to sign transactions, then how will Alice ever return her deposit?
2. When transacting over the payment channel, Alice and Bob create many versions of IOU transactions. Assume Alice is mostly paying Bob. Then in the last version of the transaction Bob should receive more than his deposit. But Alice can cheat and submit the very first valid transaction, pretending that she never owed Bob anything. What shall Bob do in this case?
3. Assume Alice is paying Bob through Victor in the network of payment channels. How can they be sure that Victor will indeed pass the money, and not just steal it?

We will call these issues, respectively: “the problem of a joined deposit”, “the problem of the last transaction” and “the problem of intermediary”.

All of the mentioned issues can actually be resolved using only a couple of tricks. But let’s not get ahead of ourselves. First, we will introduce some required building blocks…

2. Smart contracts

Bitcoin supports a simple smart contract programming language, called Script. Every bitcoin transaction has a special field that contains a small script in this language. This script checks under which conditions the output of the transaction can be spend.

“To spend the output of transaction A” is in fact just a more technically correct way of saying “to spend bitcoins from address/wallet K, to which these bitcoins were delivered using transaction A”.

☝ In comparison with ethereum, capabilities of smart contract in bitcoin are much more limited. This is because of the fact that Script is not a Turing-complete language. E.g. Script does not allow cycles/recursion, and does not allow creating variables (there is no memory).

See the the link below to read a bit more about transactions structure and using scripts.

Bitcoin: transactions, malleability, SegWit and scaling

Let’s have a look at a couple of important operations of bitcoin scripts.

2.1. Authorisation

Perhaps the most standard part of every transaction is signature verification. Let transaction A fund some address K with some number of bitcoins. In order to later spend these bitcoins from K, one needs to prove that they have the key. This is checked using operation OP_CheckSig.

But we can additionally check something else. For example, we can check that a person has a secret number, the hash of which is equal to the given value. For that we need two operations: OP_SHA256 (computes the hash of the provided parameter) and OP_EqualVerify (checks equality). In part 4 we will discuss why would anyone need that.

2.2. Cooperation

Another common example of simple bitcoin smart contracts is based on the operation OP_CheckMultiSig. This operation allows to spend funds from an address only when signed with multiple keys.

This principle is used for so-called multiple signature (multisig) wallets. It works approximately like a bank deposit box closed with two locks. One key belongs to a client, the second one — to an employee of the bank.

2.3. Timing

Since quite recently bitcoin also supports an operation called OP_CheckSequenceVerify, which allows to spend the funds only after some fixed number of blocks.

For example, this can be used to discipline people unable to save money. Blockchain works better than any piggy bank: if someone decides to freeze the savings for some time, the money will be securely frozen.

But beyond this scenario, OP_CheckSequenceVerify and other components are actively used for payment channel implementation.

3. Payment channel implementation

Now with all the building blocks ready, we can describe how payment channels actually work.

In reality, there exists a whole variety of different payment channels, and the first one was proposed by Satoshi him/her/them-self. We will approximately follow the specification called Poon-Dryja payment channels (named after the two authors of the Lightning Network paper).

3.1. Opening the channel

1. Alice and Bob create a transaction/transactions transferring their money to a joined deposit address O. Assume that Alice transfers X bitcoins from her wallet, Bob transfers Y bitcoins. The funds from this joined deposit can only be spent when signed with two keys from Alice and Bob (OP_CheckMultiSig).
2. The first trick is that they do NOT yet sign the transaction and do NOT yet submit this transaction to the blockchain. Otherwise Bob can refuse to cooperate and Alice will lose access to her money forever.
3. Instead, Alice and Bob create two new refund transactions (A1 and B1 respectively). The input of these transactions is the money from the joint account (the output of transaction O). There are two outputs: X bitcoins is to be transferred back to Alice, and Y — back to Bob. In reality everything is a bit more complicated, but we’ll discuss it later.
4. Then Bob signs the transaction A1 and gives it to Alice. Alice signs the transaction B1 and gives it to Bob.
5. And now the initial deposit transaction O can be safely recorded in the main blockchain. No one is going to freeze anyones money. If Bob refuses to cooperate, Alice will just sign her transaction A1, record it in the blockchain and will return her deposit.

Deposit refund transactions.

Now “the problem of a joint deposit” is solved. The channel can be opened without any trust to the second party.

☝ An interesting fact. Just half a year ago (before the SegWit activation) signing an output of an unconfirmed transaction (point 4 above) was much harder, because of transaction malleability problem.

3.2. Using the channel

Payments within a channel are in fact implemented by rewriting transactions A1 and B1 with the new transactions.

1. Alice is paying Bob for a cup of coffee that costs C.
2. Alice agrees that when closing the channel, she will receive not the original amount X, but X’=(X-C).
3. Bob agrees to receive Y’=(Y+C).

New transactions A2 and B2 will look exactly the same as A1 and B1, but with new amounts. Any party can close the payment channel at any time, submitting the last version of the transaction to the blockchain.

How to make sure that Alice will not submit transaction A1 instead of transaction A2? This is solved with the second trick.

1. Every time Alice and Bob create new transactions, they also select a one-time private key. This key can be used by one party to collect the deposit of another party (OP_CheckSig).
2. With every new payment i, Alice is revealing to Bob her previous private key AK(i-1) and creates a new key AKi. Bob does not accept payment without the previous key.
3. If Bob knows Alice’s key, he can spend all the Alice’s money. But only if Alice decides to record an incorrect transaction to the blockchain.
4. This scheme insures that Alice is always motivated to record only the last transaction to the blockchain.

Last small modification. To dispute the transaction Alice submits to the blockchain and to provide her key, Bob needs time. Because of that Alice is not going to get her deposit immediately after she closes the channel, but after some number of blocks T (OP_CheckSequenceVerify). For example, she may need to wait for 48 blocks, which is approximately 8 hours.

The final form of the transactions used for a payment channel.

If Alice signs one of her transactions (they are already signed by Bob) and submits this transaction to the blockchain, two scenarios are possible.

1. Alice submits her last transaction => Bob does not know the last private key AKi. This is a valid closure of the channel, everyone should get their unspent money. Alice will get hers after some time.
2. Alice is trying to record her older transaction instead of the last one => she is trying to cheat. In this case Bob knows Alice’s key and he can use it to get all the Alice’s money. Obviously, Alice is not interested in this scenario.

So, “the problem of the last transaction” is also solved. Payment channel between two people is ready. Now it also becomes clear, what are the advantages and disadvantages of using payment channels.

👍 Advantages: 1. payments are instant and free, they do not create a burden on the main blockchain. 2. two parties do not have to trust each other.

👎 Disadvantages: 1. deposits are blocked for the whole time while the channel exists. 2. both parties should from time to time go online (at least once in T blocks).

👌 In practice, both disadvantages are important for payment channels between two people, but much less important in the context of Lightning Network. First point stops being a disadvantage when one channel can be used to pay to various different people.

Second point is also basically non-existent in LN, because one can outsource correctness verification to a third party. If Bob is not online when Alice is closing the channel, and some random David discovers that Alice is cheating, then both Bob and David can split Alice’s confiscated deposit.

One more small note before we move further. You may think that operating a payment channel requires a lot of bookkeeping: tracking and signing different versions of transactions, exchanging signed these transactions and also temporary keys. And you will certainly be right. Good news is: when properly implemented, this will be all happening behind the scenes, the users will just send the money and receive them.

4. Lightning Network

4.1. Payment channel though an intermediary

Let’s now assume that Alice and Bob do not have a payment channel between each other, but both have an open channel with Victor. Alice can safely transfer money to Victor, Victor can safely transfer money to Bob.

But how to make sure that Victor, once he receives the money, will indeed pass them further to Bob?

The idea here is going to be quite similar to the previous trick. But instead of one-time private keys, they will use a secret number.

1. When the payment is initiated, Bob selects a secret number S, computes a hash of this number HS, and transfers this information to Alice. HS can also be used as a virtual receipt.
2. Alice creates a transaction AV that transfers the money to Victor, but only in case Victor shows a secret number S. For that she uses a script checking the hash of the provided number and comparing it to the value of HS (this is where we need OP_SHA256 and OP_EqualVerify).
3. Victor is creating a similar transaction VB transferring money to Bob, but only if Bob provides a secret number S.
4. Bob sees that he will be able to get the money from Victor and shows him his secret number S.
5. Now Victor can prove to Alice he transferred the money and successfully receive transaction AV.

There are couple of scenarios possible.

1. First, it does not make sense for Victor to cheat. By design, if he does not pass the money to Bob, he will not get the money from Alice.
2. But Bob can decide to cheat and not to reveal the secret key to Victor. To get the money Bob will need to close the channel with Victor and to submit transaction VB to the blockchain. But to actually spend the money, Bob will need to show his secret number anyway. And as the blockchain is public, Victor will also see it.

There is a couple of non-trivial technicalities with selecting the right timeframe for Alice, Victor and Bob to resolve possible conflicts. But these technicalities are way out of scope of this introductory article. If interested — google Hash Time-Locked Contracts (HTLCs).

4.2. Routing

In practice Alice and Bob can be connected through any arbitrary number of unknown/anonymous intermediaries across the whole world. The problem of finding the most optimal path of intermediaries in a graph of network nodes is called a routing problem.

Geographical distribution of bitcoin testnet nodes (https://explorer.acinq.co/#/).

The routing problem is in fact an area of active research at the moment. Optimal path depends on many dynamic factors: the availability of nodes, network topology, channels throughput, intermediaries fees.

Without going into too many details, finding the path and passing the payments in LN is currently done based on Onion routing — a technology for anonymous peer-to-peer routing, which is also used, for example, in Tor.

Everything is decentralized, the traffic is encrypted. No intermediary knows from whom the bitcoins come and where they go. One more advantage follows from this.

👍 Advantages: Lightning Network is much more anonymous than bitcoin itself. First, an absolute majority of the transactions are never recorded in a public ledger, these transactions are only visible to a handful of nodes. Second, even among the nodes involved in routing, only the first and the last node knows the source and the destination of the payment.

4.3. Fees economy

Only two major questions left.

Question number 1: why would an intermediary node process any payments from someone else?

First of all, because good connectivity allows them to use LN more efficiently. Second, because they receive fee: usually very small, but motivational enough.

At the moment the network is mostly supported by enthusiasts and the fees are almost zero: 1 satoshi, or ~0.01 cents for every intermediary node.

👍 The “bandwidth” of payment channels is a much less valuable resource than the block size. Channels are cheap and easy to open. Because of that fees in LN are orders of magnitude smaller than the fees in the main bitcoin blockchain.

Question number 2: and what about the miner fees payed on the main blockchain to open/close payment channels?

Indeed, these fees can be quite large, reaching sometimes tens of dollars. Therefore, payments are going to be cheaper if the channels are open/closed rarely.

This in turn motivates people to open channels with larger deposits, and to use channels bi-directionally: not only for outgoing payments, but also for incoming ones.

Example: I open a channel and fund it with 1000 dollars to use it for only outgoing payments. The turnover in the channel over the lifetime will be exactly 1000 dollars, and I will pay ~20 dollars in fees to open and close the channel. This results in 2% fees. Slightly lower than visa and mastercard, but still not as low as I would like.

The situation changes dramatically when the I start using Lightning to the fullest: deposit larger amounts and also start receiving money through channels. Then, depending on the proportion of spent/received money, the channel can be open forever and the fees will be converging to almost zero in the limit.

4.4. Criticism

It is easy to find lots of criticism of second layer solutions in general and of Lightning Network in particular. Some points actually deserve attention, some are outdated myths. Here is a couple of examples.

1. Using LN leads to centralization: users benefit from connecting to large hubs, and few of these hubs can control all the traffic.

This is a valid concern and deserves attention, but the risks are not huge. First, it is economically profitable and very simple to run a new node bypassing large hubs. Second, routing algorithms should balance the traffic among all the possible paths. And third, at least for the moment we do not see this centralization happening. Going forward, I hope the optimal topology is going to be encouraged by wallet software itself.

2. Low channel throughput will result in LN congestion, fees rising, and the situation will be as bad as in the main bitcoin blockchain.

Again, as soon as this starts happening, people will have larger economic incentives to run their own nodes. Unlike the block size, the number of nodes/channels is almost unlimited.

3. Efficient and effective routing on large number of peer-to-peer nodes is impossible. Especially when accounting the cost of opening new channels.

These problems are far-far-far into the future. But the research in this direction is already happening (example). The community will come up with something.

4. Channels need to be often opened and closed. Fees spent on that will be high, and LN will become more and more expensive.

Actually, this is an outdated myth still circling around. Early proposals of payments channels indeed were uni-directional and could last only for a fixed time. Now these problems are both solved.

5. You need to be online to use LN.

Partly true. Unlike early LN implementations, there is no need to be always online: other participants can monitor my open channels and verify that no one is cheating. But you indeed need to be online to send/receive money. This is of course a limitation, but a much less significant one.

6. LN is not compatible with cold storage.

This is a very good point and valid concern. Funds locked in payment channels are controlled by the wallets being online (hot wallets). So additional security for nodes will be required to protect against hackers.

7. LN transactions are not as safe as on-chain transactions.

LN payments are indeed more risky than on-chain transactions. But only in case of a successful 51% attack. The risk of it is very-very small.

5. LN today

The most important thing you need to know: Lightning is already here and it really works.

More than a thousand nodes in bitcoin testnet and more then three hundred nodes (growing every day) in mainnet are already processing transactions and testing different software today.

Co-founder of Lightning Labs does not recommend running mainnet nodes for the moment.

As for software, there are three main implementation: lnd from Lightning Labs, c-lightning from Blockstream, eclair from ACINQ. These teams have been working for years to create standard specifications for nodes interactions called Lightning Network Specifications (BOLTs). And recently, in the end of 2016, they performed massive successful payment testing. All three implementations proved to be compatible.

At the moment, you can pay with real bitcoins using LN in only three or four online shops. But this is a whole three or four shops more than just a month ago, so this is already a great success 😊

Of course, the moment of ubiquitous transition from on-chain bitcoin payments to off-chain payments is still far away. A huge work should still be carried out by developers of wallets, payment gateways, exchanges, online stores. And, of course, by users themselves.

The most interesting in this story is that faster, cheaper and more anonymous transactions — is only the beginning of the story! Soon we will see even more anonymity, atomic swaps, decentralized exchanges and many more cool things. The future is exciting! ⚡

More technical details about LN: 1, 2, 3, 4, 5.

This article in Russian (статья на русском).

Please do comment, criticize, ask questions, subscribe. More about the author: http://laptev.ch.