Bitcoin has a huge scaling problem—Lightning could be the solution

The Lightning network could enable much cheaper and faster bitcoin payments.

Three startups are getting ready to launch one of the most ambitious and important cryptocurrency experiments since the creation of bitcoin itself. Called Lightning, the project aims to build a fast, scalable, and cryptographically secure payment network layered on top of the existing bitcoin network.

Essentially, Lightning aims to solve the big problem that has loomed over bitcoin in recent years: Satoshi Nakamoto's design for bitcoin is comically unscalable. It requires every full node in bitcoin's peer-to-peer network to receive and store a copy of every transaction ever made on the network.

Initially, that design was vital to achieving Nakamoto's vision of a fully decentralized payment network. But as Purdue computer scientist Pedro Moreno-Sanchez told Ars, it creates a big challenge as the network becomes more popular. "We have reached a point where it's not suitable any more to keep growing," he said.

Lightning could offer a way out of this bind. It shifts routine payments outside of the blockchain, clearing away the most significant obstacle to bitcoin's continued growth.

In fact, the Lightning project could potentially do much more than that. Lightning payments are expected to be faster, cheaper, and more private than conventional bitcoin payments. Proponents see Lightning as a new, second layer in the bitcoin software stack. They hope Lightning will expand the appeal of bitcoin in much the same way the Web helped the Internet go mainstream.

The key ideas behind Lightning were proposed by Joseph Poon and Thaddeus Dryja in a 2015 white paper, but it's taken three years to translate the proposal into fully working code. Today, three different companies—San Francisco startups Blockstream and Lightning Labs and Paris startup ACINQ—are working on parallel implementations of the Lightning technology stack. The trio released version 1.0 of the Lightning specification in December, and the companies are now racing to get their software ready for use by the general public.

So, what's on the horizon as bitcoin prepares for Lightning to strike? To truly understand, it's important to first understand how Lightning uses the cryptographic primitives of the bitcoin network to make secure payments outside the blockchain (you're in luck—we'll explain). From there, we'll take a step back and consider the key strengths and weaknesses that the new network is likely to have once it's deployed at scale.

Lightning's core idea: Chaining payment channels together

The basic unit of the Lightning network is called the payment channel. This is a private conversation between two users that enables the exchange of cryptographically enforceable IOUs. As long as both parties follow the rules, there's no need to broadcast these individual transactions to the broader bitcoin network. In principle, two parties can make dozens, hundreds, or even thousands of payments to one another without cluttering up the blockchain.

In the Lightning vision, the old-fashioned bitcoin network becomes a cryptographic backstop for these payment channels. The IOUs are actually cleverly-formatted bitcoin transactions called commitment transactions that haven't yet been submitted to the bitcoin network. A user always has an option to "cash out" by posting the current commitment transaction to the blockchain and collecting the money she's owed.

But payment channels aren't enough to solve bitcoin's scaling challenges on their own. In the real world, people want to make payments to a lot of different people—including a lot of one-off payments to people they're never going to interact with again. Each payment channel generates two bitcoin transactions: one to open it, and a second to close it. So if people had to open a new payment channel to every recipient, congestion on the blockchain might get worse rather than better.

So the Lightning network provides a cryptographically secure method for chaining payment channels together. If Alice has a payment channel with Bob and Bob has a payment channel with Carol, then Alice can pay Carol by sending some money to Bob and asking Bob to forward the money on to Carol. Crucially, the Lightning protocol guarantees that Bob can't steal the money as it passes through his hands.

The ability to securely chain payment channels together creates the possibility of stitching millions of people together into a single global payment network. Instead of opening a new payment channel to each new recipient, users find a chain of already-open payment channels that connect them to new recipients. That means you can use a single payment channel to make lots of payments to many different people—all while generating just a handful of transactions on the underlying blockchain.

How payment channels work

To really understand how Lightning works, you have to understand how bitcoin transactions work. You might want to read the first page of our bitcoin primer, which explains this in detail. But in a nutshell, a bitcoin transaction is a list of inputs and outputs, with each input pointing to the output of an earlier bitcoin transaction.

Each output specifies the conditions that need to be satisfied in order to spend the coins in that output. The simplest transactions just require a digital signature—cryptographic proof that a transaction has been approved by the owner of a particular private key.

Suppose Alice wants to send a payment to Bob. Alice could create a bitcoin transaction that says "Send three bitcoins to Bob." To spend those three bitcoins, Bob creates a new transaction whose input points back to Alice's transaction and whose output sends the bitcoins on to someone else. He uses his private key to sign this new transaction and submit it to the bitcoin network. If the signature is valid, the transaction becomes part of the blockchain.

FURTHER READING
Want to really understand how bitcoin works? Here’s a gentle primer
Bitcoin has a scripting language that allows transactions to specify arbitrarily complex conditions for spending outputs. For example, suppose Alice has a second friend Charlie. She could create a bitcoin transaction with an output that says "These three bitcoins can only be spent with signatures from both Bob and Charlie." To unlock those funds, Bob and Charlie would have to work together, generating a single bitcoin transaction that's signed by both of their private keys.

With that background, here's how a payment channel works. Suppose Alice and Bob want to open a payment channel with 10 bitcoins in it—five from Alice and five from Bob. Alice and Bob will construct a bitcoin transaction that takes five bitcoins from Alice and five bitcoins from Bob. The transaction has a single output with a two-signature condition: both Alice and Bob have to sign a transaction in order to spend the 10 bitcoins.

Alice and Bob also construct a second transaction, called a commitment transaction, that reverses the effect of the first transaction. This new transaction takes the 10 bitcoins from the previous transaction as its input. It has one output sending five bitcoins back to Alice and a second output sending the other five bitcoins back to Bob. Alice and Bob each sign both transactions.

Then—and this is the crucial step—they only submit the first transaction to the network. This effectively puts 10 bitcoins into a shared account jointly controlled by Alice and Bob. If either one of them ever decides they want their bitcoins back, they can submit that second transaction to the network. But as long as neither of them does this, the channel remains open, and Alice and Bob can effectively send bitcoins to one another without putting anything on the blockchain.

If Alice wants to send Bob one bitcoin, she creates a new commitment transaction. Instead of sending Alice's five bitcoins back to Alice and Bob's five bitcoins back to Bob, the new commitment transaction says "four bitcoins to Alice, six bitcoins to Bob."

Alice signs this commitment transaction and gives it to Bob, who signs it and sends it back. Alice and Bob both destroy their copies of the previous commitment transactions (the one that gave five bitcoins each to Alice and Bob). Now Bob "owns" six bitcoins and Alice "owns" four—all without broadcasting anything to the blockchain.

Alice and Bob can repeat this process an unlimited number of times. Suppose Bob next wants to pay Alice three bitcoins. He creates a new transaction that says "seven bitcoins to Alice, three bitcoins to Bob," signs it, and sends it to Alice. She signs it and sends it back. They destroy their copies of the previous transaction and Alice now effectively owns seven of the 10 bitcoins in the channel. Again, nothing gets added to the blockchain.

The key idea here is that neither Alice nor Bob is ever in danger of having their coins stolen by the other party—or of having their coins locked up in a state where they can't recover them. Each of them has a copy of the current commitment transaction, which either of them can submit to the blockchain at any time to unilaterally withdraw their own funds (returning the other party's funds at the same time).

How Lightning invalidates old commitment transactions

Perceptive readers will notice a big problem with the scheme I've described so far. I said Alice and Bob both "destroy their copies" of old transactions when they create a new one. But that's not how computers work: there's no way for Alice to prove to Bob that she "destroyed" data and didn't save a copy.

So if the current commitment transaction says "four bitcoins to Alice, six bitcoins to Bob," Bob has to worry that Alice might have saved a copy of that earlier "five bitcoins to Alice, five bitcoins to Bob" commitment transaction. If she submits that outdated transaction to the blockchain, she could effectively steal one of Bob's bitcoins.

To prevent this, the Lightning protocol structures commitment transactions so that anyone who submits an outdated one will pay a stiff penalty. Alice and Bob actually each get slightly different versions of each commitment transaction. Both versions send the same number of coins to each party (in our example, five bitcoins to Alice and five bitcoins to Bob). But Alice's copy of the transaction attaches strings to Alice's five bitcoins, while Bob's copy of the commitment transaction attaches strings to Bob's five bitcoins.

In Alice's version of the commitment transaction, Bob can to spend his five bitcoins immediately. But Alice isn't allowed to spend her bitcoins until a fixed time period (typically a few days) has passed. And during this lock-up period Alice's share of the bitcoins can be taken by Bob if Bob knows a special encryption key called the revocation key.

FURTHER READING
Why the Bitcoin network just split in half and why it matters
Initially, only Alice knows this key. But when Alice wants to revoke an old commitment transaction, she tells the key to Bob. This renders Alice's copy of that commitment transaction useless to Alice because if Alice broadcasts it, Bob can use the revocation key to take all the funds in the channel.

All of this is made possible by the bitcoin scripting language we mentioned earlier. It is capable of expressing complex rules like "these bitcoins can be redeemed with Alice's signature after 1,000 blocks have been added to the blockchain or they can be redeemed immediately with a signature from key R."

And, of course, this works both ways. Bob's copy of each commitment transaction lets Alice spend her coins immediately but includes a time lock on Bob's coins. To invalidate an old commitment transaction, Bob gives Alice the revocation key for that transaction, giving her the power to take Bob's bitcoins if he ever submits it to the network.

Over the course of a channel's life, Alice and Bob might repeat this process many times: update the channel balance by swapping a new set of commitment transactions, then trade revocation keys that render the previous set of commitment transactions unusable. In this scheme, Alice and Bob always have the option to "cash out" by submitting the latest commitment transaction to the blockchain. But if one of them tries to cheat by submitting an outdated commitment transaction, the other party can use the corresponding revocation key to take all the bitcoins in the channel.

Eventually, Alice and Bob will want to close the channel and get their bitcoins back. Alice could do this by unilaterally submitting the most recent commitment transaction to the blockchain. But that would mean Alice would have to wait several days to get her money. So in practice, if Alice wants to cash out she'll ask Bob to sign a channel closing transaction that sends each party its own bitcoins without imposing any time restrictions.

This means that if everyone plays nice, then those time-restricted commitment transactions will never actually appear on the blockchain. They only come into play if cooperation breaks down between the two sides of the channel. If Bob ignores Alice's request to shut down the channel, then Alice will have no choice but to transmit the current commitment transaction—even if that means an annoying delay before she can reclaim her funds.

How Lightning chains payment channels together

In the real world, people don't send payments to the same person over and over again. They send payments to lots of different people—including many they've never met before and will never interact with again. The real magic of the Lightning network is its ability to address this need by chaining payment channels together.

The vision here is that a typical user will only have payment channels open to a handful of other people or organizations. If they want to send bitcoins to anyone else, they'll use one of their direct payment channels as the first link in a chain connecting them to the person they want to pay.

So Alice might have payment channels open with Bob and Bethany, while Bob has payment channels to Charlie and Connie, Charlie has payment channels with Donald, Daisy, and Doug, and so forth. If Alice wants to pay Daisy, she asks Bob and Charlie to help—and offers to pay them something for their trouble. She sends bitcoins to Bob over their mutual payment channel. Bob sends the same number of bitcoins to Charlie (minus agreed-upon fees), who in turn sends bitcoins to Daisy.

FURTHER READING
Bitcoin: Seven questions you were too embarrassed to ask
The obvious danger is that Bob could accept Alice's coins but fail to send them along to Charlie. But Lightning payments use a mechanism called a hashed time lock contract (HTLC) that guarantees that Bob and Charlie can't cheat. Bob can't get Alice's coins unless he pays Charlie, and Charlie can't get Bob's coins without paying Daisy.

The way this works is that Daisy chooses a random value we'll call P (for pre-image) and runs it through a one-way function called a hash function, producing a hash value we'll call H. Daisy then sends H to Charlie, who sends it back along the chain to Bob, who sends it to Alice.

Now Alice and Bob sign a cryptographic contract (the HTLC) that says Alice will pay Bob if Bob can produce a value that hashes to H. Hash functions are designed to be irreversible, so Bob will only be able to satisfy this requirement if Daisy or Charlie tell him P.

Next, Bob signs the same kind of contract with Charlie, promising that Bob will pay Charlie if Charlie produces a value that hashes to H. Finally, Charlie signs a contract with Daisy with the same terms.

Now these contracts can be cashed out in the opposite order. Daisy tells the secret value P to Charlie, and the two of them settle their contract. Now Charlie knows P, so he can settle his contract with Bob in the same way. Finally, Bob uses P to settle his contract with Alice.

At no point in this sequence is anyone at risk of being left holding the bag. Alice knows Daisy won't reveal P to anyone until the full payment chain is completed—otherwise Daisy won't get her payment. So Alice can safely sign the contract with Bob. Bob's contract with Alice guarantees that he'll get his money if he learns P, giving him confidence to make the same promise to Charlie. Charlie, in turn, then feels confident promising to pay Daisy in exchange for P.

And once all the these contracts have been negotiated, the blockchain makes them enforceable.

Hashed time lock contracts are enforced by the blockchain

The hashed time lock contracts that enable Lightning payment chains are enforced in the same manner as basic payment channels: with commitment transactions that can be broadcast to the blockchain if any party fails to play by the rules.

When Alice signs an HTLC contract agreeing to pay Bob if he can produce P, what actually happens is that she creates a new commitment transaction with three outputs. Two of the outputs go to Alice and Bob just as in a basic commitment transaction. But now there's a third output containing the funds that are under contract.

This third output can be redeemed in two different ways, as codified in bitcoin's custom scripting language. It can be cashed out by Bob if he can produce a value that hashes to H. Otherwise, it can be cashed out by Alice—but only at a fixed point in time several days in the future.

Once Bob reveals P to Alice, they can settle the contract by replacing their three-output commitment transaction with a new commitment transaction with two outputs reflecting the new channel balance.

If Bob fails to produce P then Alice gets to reclaim her funds. Bob's contract with Charlie and Charlie's contract with Daisy have similar clauses, but the time limits are progressively shorter. Alice is entitled to reclaim her funds after three days if Bob doesn't produce P first. Bob gets his funds back if Charlie can't complete the contract within two days. Charlie gets his funds back after one day.

FURTHER READING
How bitcoins became worth $10,000
These staggered time limits ensure that a failed payment chain can be unwound in an orderly fashion. Suppose Daisy disappears from the Internet after signing her contract with Charlie but before telling Charlie P. Without P, Charlie can't collect his payment from Bob. So after one day has passed, Charlie will have no choice but to close his payment channel with Daisy by broadcasting the current commitment transaction to the blockchain—reclaiming the bitcoins that had been tied up by the contract.

At this point, the payment chain has failed—Daisy isn't going to get her payment from Alice. But Bob and Charlie would probably prefer to keep their channel open, which means they'd like to avoid broadcasting a commitment channel to the blockchain. They can unwind their contract by simply creating a new commitment transaction that removes the HTLC output and credits those bitcoins to Bob. The fact that Charlie's contract with Bob lasts a day longer than Charlie's contract with Daisy ensures that Bob and Charlie will have time to do this.