Future of bitcoin —

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

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

Bitcoin has a huge scaling problem—Lightning could be the solution
Aurich Lawson / Getty

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.

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).

Channel Ars Technica