The Lightning Network Explained, Part I: How to Build a Payment Channel

What is the Lightning Network? We try to make this crazy piece of Bitcoin scaling technology understandable for everybody. The first part is about the basic unit of Lightning, the Payment Channels. How are they built? Why do they make it possible to send bitcoins without miners? And how do they avoid the need to trust a counterparty?

When it comes to the Lightning Network, many people only say the best and best of all about it. Lightning can solve any scalability problem Bitcoin ever had and will ever have, will make transactions confirm immediately and fundamentally increase privacy.

This is said, and basically, this is correct. But if somebody promises you to explain Lightning “very easy,” you should be sure to be in contact with a liar. Lightning Network is never easy, but always monkey-complicated. While investigating the topic, the author spun several new knots in his brain, and it will be unavoidable that the brave reader will do the same. But these articles try to make it as easy as possible.

With Bitcoin, Every Node Cooks its Own Soup

To understand the Lightning Network you have to start with the Bitcoin network. Precisely with the fact that Bitcoin is a broadcast network, which means that everybody does everything. Every node receives, validates, stores and relays every transaction. This has its need in Bitcoin, but it obviously is creepily ineffective.

Imagine you have a travel group of 250 people traveling from Milan to Stockholm, and everybody uses their own car. Or a group of five pupils has to solve together five math problems, but instead of exchanging the results, everybody works through all tasks. Or, to present a last analogy; seven guests each download the same recipe for asparagus soup, print it out, buy the ingredients at the same supermarket, visit the host and each cook their own bowl of soup.

You could add an endless number of analogies. But the message is clear; Bitcoin is bad at scaling.

Lightning does Scale well

The Lightning Network which is presented here cleans up with those problems. It builds a network of so-called payment channels, which ship a transaction only from the sender to the receiver. Meaning, if Alice sends funds to Bob, the transaction does not need to be validated, relayed and stored by every node of the Bitcoin network, but only by the node of Alice and Bob. This solves a lot of fundamental problems in Bitcoin with one strike:

• Privacy: In Bitcoin, everybody logs what everybody else does. Blockchain analyses can dramatically reduce the privacy of Bitcoin transactions. If everybody reads and stores every transaction, the Blockchain is an open book about other people’s financial affairs.
• Scalability: A broadcast network like Bitcoin does not scale well. If you add more peers, the network does not become more efficient but just increases the absolute traffic volume. It could even be that the burden on a single node increases with the number of nodes. For this, there is a very low chance that Bitcoin will ever reach a transaction volume like payment processors such as PayPal or Visa while maintaining a significant degree of decentralization. Lightning, however, might be able to increase the odds in Bitcoin’s favor.
• Speed: Bitcoin transactions can be seen nearly immediately, but you need some minutes to hours until they are confirmed by miners. Until this happens, it is possible that a transaction can be undone. This could be a significant obstacle to using bitcoin for retail payment. With Lightning Network transactions can be valid nearly immediately.

That is powerful, if true. The big questions are; is it possible? And if yes, how can it be done? The answers to these questions can be found behind the promised knots of the brain lobes. Let us start with the first part; the payment channels.

Payment Channels

What is a payment channel? The answer is not easy, which is why you need to invest a little bit of concentration in understanding. But it will not get too complicated.

A payment channel is a method to make off-chain transactions between two parties. To build up one you need to transact Bitcoins on a 2-of-2-Multisig address. For example, 0.1 bitcoin. 2-of-2 means that both you and the other party have to sign a transaction to make a payment. Like with bank accounts used for your rent deposit.

After both parties have transacted bitcoins to the multisig-address, they build a new transaction – for example, one who pays 0.1 bitcoin to each of them – and sign them. Now the tricky part starts; this transaction is not propagated to the Bitcoin network and not confirmed by the miners, but just shared between both parties involved in the payment channel. Instead of sending it to the network, they can modify the transaction as often as they want. These modifications of the transaction, signed by both parties, can be used to make off-chain payments.

You can imagine payment channels a bit like paper transfer forms, which are filled and signed and could be put in the box of your bank. But instead of giving it to your bank, you modify it to handle payments with your partner.

For example, you build a payment channel with a partner and both of you paid in 0.1 bitcoin. If you want to pay your partner with 0.0001 bitcoin, you write and sign a transaction which pays out 0.0999 bitcoin to you and 0.0001 bitcoin to your payment partner. Whenever one of the involved parties sends the transaction to the Bitcoin network, so that it is confirmed by the miners, the channel closes. If you pay your partner every day 0.0001 bitcoin and the channel is closed after one year, there have been 365 payments, but only one transaction lands on the blockchain, sending 0.0635 bitcoin to you and 0.1365 bitcoin to your partner.

Such payment channels might be useful when two parties share a lot of transactions. But as this is more of a niche application, payment channels unleash their true power only if you connect them to a network of channels. This is what the Lightning Network does. It enables you to let payments flow through several channels, from Alice to Bob to Carol to Dave to Emile and so on.

That is the basic idea. But before we start to come to the network, we need to understand some basic problems and solutions surrounding payment channels. The big question is, like so often with Bitcoin; how can you do it without needing to trust someone?

What is the Problem?

There are two major problems which make a payment channel more complicated as painted above. Large parts of the Lightning Whitepaper, written by Joseph Poon and Taddeus Dryvja, cover these issues.

The Hostage Taking Problem

Imagine, you open a payment channel with another party. Both of you send 1.0 bitcoin to the 2-of-2 multisig address. But before you start sending money through the channel, your partner shows his true face and says: “Hey, I will never close the channel. Your bitcoin is locked on the address forever. You only get it back if you give me 0.5 bitcoin.” Both parties of a payment channel could take the commitment of the other as a hostage.

How can this be prevented? Poon and Dryvja found a smart solution. It is not as complicated, as it seems at first glance. If you understand the underlying mechanism, it is relatively easy; first, you and your partner build and share the transaction, which opens the payment channel by sending a certain amount of bitcoin to the multisig-address, but you neither sign nor propagate it. So everybody knows what will happen, but nobody has the signatures needed to make it real. The payment channel exists only as an idea.

But this idea contains enough pieces of information to build the transaction which closes the channel by redeeming the bitcoins from the address. So both of you build this transaction, sign, and share, but not send it. This is something like a backup in case the other party wants to cheat.

Only after both have the transaction to close the channel, they sign the transaction which opens the channel and sends it to the Bitcoin network. Now nobody can take the other’s coins as a hostage since everybody can close the channel whenever they want.

But this does not solve the second problem.

The Problem of Old Commitment Transactions

Imagine, you have a payment channel and pay your partner each day a little bit of bitcoin. When the channel started with a balance of 0.5:0.5, on day 200 it has evolved to something like 0.3:0.7. But now, one day later, you decide to close the channel. Instead of the newest transaction, however, you take the first. The result would be that all payments done in the last 200 days would be deleted, and the initial closing transaction, which pays each party 0.5 bitcoin, would settle on the blockchain. It is as the channel has never existed.

Poon and Dryvja have also solved this problem. Unfortunately, the solution is a bit complicated. But, as promised, you will understand. To not get things wrong, let us take a short stop at the definitions. The authors call the transaction that opens up the payment channel the “funding transaction” and the transaction, that can close the channel, the “commitment transaction.” To change the balances in the channel you just write and sign a new commitment transaction.

As soon as you change the balance in a payment channel, several different commitment transactions exist at the same time. And each of them could legitimately settle on the blockchain. How can this problem be solved? How can you guarantee that only the newest commitment transaction is valid on the blockchain?

Poon and Dryvja developed a transaction model which punishes the party that propagates an old commitment transaction by taking the whole fund in the channel. The model consists of two parts.

First, it is necessary to detect an old transaction which is relatively easy to do; you just need to build two distinguishable, but functionally identical commitment transactions. This is possible due to the cryptographic mechanisms applied in Bitcoin. Each party just needs to sign inputs and give them to the other party which signs the whole transactions.

To illustrate this procedure, imagine you sign a paper, give it a friend, who signs another paper, puts both sheets of paper in an envelope and signs the envelope. And the other way round. You do not need to get all the details, but it is important to know, that there are two different transactions with different IDs, but which do the same. That will become important.

But before we continue this story, we need to find a way to reverse “wrong” transactions which violate the rules. A mechanism is needed to make sure that only the newest transaction can go on the blockchain, while all other transactions can be revoked. Here a script with the name OP_CHECKSEQUENCEVERIFY, short CSV, comes into play. This script uses the sequence field of transactions to “freeze” the outputs; the transactions need to have a certain number of miner confirmations to allow that the outputs to be spent. For example, you receive one bitcoin, but you can only spend it when the transaction is confirmed in 1,000 blocks. It is like putting a time-lock on the transactions.

With CSV it is possible to build a transaction scheme which allows a change in transactions later. For this, each party creates a commit transaction with two paths. First, the bitcoin are paid to each party, as it should be. The outputs of it, however, are frozen and need a certain amount of confirmations to be spent again. The second path is that the whole fund in the channel is paid to the other party. This path distinguishes the two commitment transactions. The counterparty can activate this path, which is enforced immediately but only under the condition that the transaction is already sent.

Yes, it is complicated, but soon the pieces will come together and make sense. The scenario is that your counterparty wants to close a payment channel with an old commitment transaction. Instead the 0.6 bitcoin, which you should get according to the channel’s balance, he only wants to give you 0.5 bitcoin.

After he sent the transaction to the Bitcoin network and after a miner put it in a block, the outputs can be spent after let us say 1,000 blocks. As soon as he sent the transaction, something interesting happens; you have the option to activate the second path of the transaction the counterparty signed for you – and you can redeem the whole fund of the commitment transaction to yourself.

In other words, when you send somebody something with a payment channel, you do not just send him the signed inputs for a new transaction, but also the information with which your counterparty can change every former transaction so that they receive the whole balance of the channel. This means, as long as both parties watch the payment channel, they can detect every time whether the other party tries to cheat – and both have the option to punish the other party in this case by taking the whole fund. The only problem is that both parties have to be online the whole time.

After having these two problems solved, a payment channel can be built without trust. In the next part, we explain how Lightning builds a network with these payment channels.