Image Credit: Eltoo Whitepaper

The Lightning Network is a Layer 2 solution that allows you to create micropayment channels with other Bitcoiners. It allows instant and trustless peer-to-peer transacting while limiting the amount of data needed on-chain.

In this post, I break down exactly how it works, as well as a newly proposed update protocol within it called eltoo (named after L2).

Unidirectional Channels

Unidirectional payment channels are the simplest to implement in the Lightning Network because money only flows in one direction. The most common use case is streaming money; for example, a micropayment for each minute of a video you watch.

Say you want to start such a channel with Netflix. First, you create a funding transaction, which is you locking up a certain amount of your money that you are willing to pay to Netflix (but have not yet paid them).

Say you fund this transaction with 10 Bitcoin and publish it on the Bitcoin blockchain. After being mined, this funding transaction can be spent by a 2-of-2 multisig consisting of your’s and Netflix’s keys.

As Netflix starts streaming you bytes of video, you start streaming them money — say .000001 Bitcoin per minute of video — via partially signed transactions that spend this funding transaction.

Using the funding transaction as input, you create two new outputs: one sending .000001 to Netflix, and the other 9.999999 to you. You sign this transaction and share it with Netflix off-chain (that is, without attempting to publish it to the Bitcoin blockchain). This transaction is considered “partially signed” because it only contains one of the two signatures necessary to spend.

When Netflix receives this partially-signed transaction, they are in control. Netflix can choose to claim that .000001 Bitcoin immediately, and in the process send the remaining 9.999999 Bitcoin back to you, by adding their signature to the partially signed transaction and publishing it. This is considered closing the channel or a settlement.

Instead, Netflix will continue streaming you video so long as you keep providing larger partially signed transactions every minute.

After another minute, you send Netflix another partially signed transaction using the same funding transaction as the input. This new partially signed transaction would send .000002 Bitcoin to Netflix (to reflect the two minutes of watch time), and 9.999998 Bitcoin to you. You keep doing this every minute.

With unidirectional payment channels, there’s no possibility of cheating. If you stop sending Netflix partially signed transactions every minute for higher amounts each time, Netflix will stop streaming you video. They will sign the most recent partially signed transaction you sent them (which entitles them to the most Bitcoin), publish it, and thus close the channel.

Furthermore, there’s no risk of anyone publishing an “outdated” transaction. Netflix is the only one capable of spending any of the partially signed transactions (since Netflix has your signatures, but you don’t have any of theirs), and every newer partially signed transaction you send Netflix is strictly better for them than any older one. Netflix can only cheat itself by publishing an earlier transaction.

When money flows in both directions, this gets trickier. Both parties can publish transactions, so incentives exist to publish an outdated transaction.

The Problem with Bidirectional Channels

Say Alice and Bob open up a payment channel and each lock up .5 Bitcoin in the funding transaction. Now, Alice agrees to pay Bob .1 BTC for a carwash. She sends Bob a partially signed transaction that uses the funding transaction as its input with two outputs: one that sends .4 BTC to her, and one that sends .6 BTC for Bob.

By not publishing this transaction, Bob keeps their channel open. He later agrees to pay Alice .3 BTC for a painting.

If Bob sends Alice a partially signed transaction that uses the funding transaction as its input, they will each be in possession of a different, yet valid, spend of the same funding transaction. Transactions have no expiration date in Bitcoin, so their transactions will be valid forever.

It doesn’t matter if they keep sending partially signed transactions back and forth for other goods and services. Either of them can act maliciously by publishing any earlier transaction that entitled them to more Bitcoin, thereby closing the channel, and making all other signed transactions invalid.

Bidirectional channels need a way to invalidate outdated transactions so that only the most recent signed transaction can be used to close the channel. That’s where eltoo comes in.

eltoo

Bidirectional payment channels in the Lightning Network work out-of-the-box today because the whitepaper created a working protocol to invalidate outdated transactions. This protocol, named LN-Penalty, penalizes participants who try to publish outdated transactions by allowing the other party to steal the cheating party’s Bitcoin.

Though LN-Penalty works today, it has problems. Besides its complexity, edge cases exist where it risks accidentally penalizing an honest user. eltoo is not yet usable because it relies on a proposed signature scheme SIGHASH_NOINPUT which has yet to be adopted, but because it is not penalty-based, there’s no risk of losing your funds.

In eltoo, the two parties create the funding transaction denoted by Setup in the diagram below. The funding transaction could contain Bitcoin from both parties, because we anticipate money flowing in both directions.

Each circle represents a transaction output. Diagram from the eltoo whitepaper.

Before signing the funding transaction, Alice and Bob first sign a settlement transaction (Ts,0 in the above diagram) which refunds the Bitcoin in the funding transaction to each appropriate party. In eltoo, the term “settlement transaction” describes any transaction that distributes funds back to the participants, rather than to a multisig output that they both control.

After they sign the first settlement transaction, the parties can safely sign the funding transaction. The locking script for the funding transaction looks as follows:

Locking script for the funding transaction, and any other update transaction. Image from the eltoo whitepaper.

There are two ways to spend the funding transaction: one in the IF branch, and one in the ELSE branch. These two branches rely on two separate sets of keys: the IF branch requires settlement keys, and the ELSE branch requires update keys. The two parties, Alice and Bob, each control one key from both sets of keys.

You’ll notice that the settlement branch of this locking script contains 10 OP_CSV (short for OP_CHECKSEQUENCEVERIFY) as its first instruction. Any transaction attempting to spend this funding transaction by unlocking the IF branch can only do so if 10 blocks have passed from when the funding transaction entered the blockchain. If Alice and Bob exchanged signatures for the settlement transaction, then published the funding transaction to the Bitcoin blockchain, then published that settlement transaction, it would take 10 blocks before their settlement transaction could be mined to give them control of their respective funds.