Ohio Bitcoin: Understanding the Lightning Network, Part 3: Completing the Puzzle and Closing the Channel

Bitcoin ATM
bitcoin
Image by Rosapolis

The Lightning Network is probably the most highly anticipated technological innovation that will be deployed on top of Bitcoin. The payment layer, first proposed by Joseph Poon and Tadge Dryja about a year ago, promises to support a virtually unlimited number of off-chain transactions among users, at nearly no cost – while leveraging the security offered by Bitcoin.

At least three companies – Poon and Dryja’s Lightning, Blockstream and Blockchain – are currently working on implementations of the technology. But few outside this small technological frontline fully grasp how the “future of micropayments” is set to boost Bitcoin’s capabilities.

In this three-part series, Bitcoin Magazine lays out the basic building blocks of the Lightning Network, and shows how they fit together to realize this upcoming protocol layer.

The first part of this series covered basic building blocks, and explained how these are used to establish bidirectional payment channels. The second part explained how a network is formed, and how Hash Timelock Contracts (HTLCs) link different channels in the network together. This third and final part of the series explains how HTLCs are placed inside bidirectional payment channels to ensure transactions can occur fully off-chain.

The Lightning Network

So far, Alice and Bob opened a bidirectional payment channel, which they both funded with five bitcoins. They’ve made two transactions back and forth, and at the current channel state, both Alice and Bob can claim five bitcoins for themselves by “dropping the channel” on the blockchain.

Now, they want to include an HTLC in the channel. This is to ensure that if Carol claims a bitcoin from Bob in return for her value, Bob is guaranteed a bitcoin from Alice in return.

Like the previous step, Alice and Bob start by creating a new commitment transaction each. In many ways, these commitment transactions are very similar to previous commitment transactions. They include a normal output, and an output to a funky multisig-address with a CSV (CheckSequenceVerify)-timelock and a special hash-lock. Likewise, as in the previous step, Alice and Bob exchange their old secrets, to effectively invalidate the old channel. And, once exchanged, both Alice and Bob can sign their halves of the commitment transactions and potentially drop them on the blockchain at any time.

All familiar territory. Except for one change. Both Alice’s and Bob’s commitment transactions now include one new output, worth one bitcoin. (This makes the balance 4-5-1; four for Alice, five for Bob, one for the new output.)

This new output is essentially the HTLC. And it’s even funkier than all other outputs so far, because there are three ways to unlock it.

First, the new output (in both Alice’s and Bob’s commitment transactions) releases the bitcoin on condition that Bob’s signature and the value is included in the subsequent transaction. As such, regardless of whether Alice or Bob signs and broadcasts the commitment transaction, only Bob can unlock this output – if he includes the value. But there is one small difference between the two commitment transactions: if Bob drops the channel, there is a CSV-timelock involved. He will need to wait 1,000 blocks. (If Alice drops the channel he can claim this bitcoin immediately.)

The reason Bob has to wait 1,000 blocks if he drops the channel is very similar to what we’ve seen before: It allows Alice to take this bitcoin in case Bob ever tries to sign and broadcast an old channel state. That’s where the second way to unlock the output comes in. Alice can “steal” the funds if she provides Bob’s (newest) secret.

Two can play this game: If Alice ever tries to cheat and broadcast this channel when it’s already outdated, Bob can claim this bitcoin using Alice’s secret. (He wouldn’t even need to provide the value.)

And third, as with any other HTLC, both commitment transactions also include the usual CLTV time-out fall-back for Alice. If Bob does notinclude the value in – say – two weeks (for instance because he didn’t get it from Carol), Alice can claim her bitcoin back. Again, whether Alice or Bob drops the channel doesn’t matter for this option.

So where did all this get us?

Both Alice and Bob hold a half-valid commitment transaction. If Alice drops her commitment transaction on the blockchain, she immediately sends five bitcoins to Bob. Additionally, she can wait for 1,000 blocks, and claim four bitcoins for herself. Plus, Bob has two weeks to provide the value, and claim the bitcoin in “HTLC output.” (If he doesn’t provide the value in two weeks, Alice can claim this bitcoin back.)

Bob, meanwhile, can drop his commitment transaction at any time as well, and immediately send four bitcoins to Alice. Then, he’d have wait 1,000 blocks to claim five more bitcoins from one address, and another bitcoin from the HTLC output if he provides the value. (If he doesn’t provide the value in two weeks, Alice can reclaim it.)

And of course, if either Alice or Bob tries to cheat at any point in the future, and sign and broadcast this channel when it’s outdated, both can completely block the other, and steal all bitcoins in the channel.

Payment Channel

Settling the Status

At this point, Bob is guaranteed to receive a bitcoin in exchange for the value (assuming he has it). All he has to do is sign and broadcast the commitment transaction he got from Alice, include the value in a subsequent transaction, and sign and broadcast that as well.

Alice knows this. There is no way she can cheat Bob out of his bitcoin – not even if she found out what the value is through some other means.

As such, the two might as well just “settle” outside of the channel. Bob can simply give the value to Alice, and Alice can agree to update the channel status to the more normal state without the HTLC and the time-out deadline.

Assuming both parties want to keep the channel open, that’s what they would naturally do: it’s less of a hassle than having to drop the channel on the blockchain.

Payment Channel

Closing the Channel

And finally, here’s the real power of the Lightning Network:

Almost everything described in these three articles will typically never need to hit the Bitcoin blockchain at all.

If both Alice and Bob want to close the channel “peacefully” they can simply create a transaction from the original opening transaction to override everything that happened since the opening transaction. From this closing transaction, they send themselves their fair share of the channel, as represented by the most recent channel state.

Concretely, this means that if Alice wants to close the channel, she can at this point simply create a transaction paying herself four bitcoins and Bob six, and ask Bob to sign and broadcast the transaction. Since there is no reason for him not to, he will probably cooperate and close the channel.

In the end, only two transactions will have been broadcast over the Bitcoin network and included in a block: the opening and the closing transactions. That will hold true even if Alice and Bob transact a million times in between, therefore unloading a huge burden away from the blockchain.

Payment Channel