The Lightning Network is probably the most highly anticipated
technological innovation to 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
- 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
In this three-part series,
lays out the basic building blocks of the Lightning Network,
and shows how they fit together to realize this upcoming protocol
This first part of the series establishes the necessary building
blocks, and shows how these can be combined to create "smart
contracts," which can be applied to realize the first requirement
of the Lightning Network: a bidirectional payment channel.
(Note: Anyone with a solid understanding of Bitcoin can skip
the building blocks.)
Building Block #1: Unconfirmed Transactions
At its heart, the Bitcoin protocol consists of transactions,
that are typically linked to previous transactions, and potentially
to future transactions. Each transaction contains
, which refer to addresses bitcoins are sent
, which refer to addresses bitcoins are sent
. Additionally, inputs must include the requirements to send the
bitcoins, like signatures that prove "ownership" of the
input-addresses. Outputs, meanwhile, establish the new
requirements, that must be included in the input of a
As one of its key features, the Lightning Network is built up
from more or less regular Bitcoin transactions. It's just that
these transactions are typically not actually broadcast over the
Bitcoin network. Instead, they are stored locally, on the nodes of
users - but they can be broadcast over the network at any time.
Building Block #2: Double-Spend Protection
The second building block for the Lightning Network probably
doesn't require much explaining, as it's arguably the
for Bitcoin itself: double-spend protection. If two
transactions (or: inputs) rely on the same output, only one can
The important thing to keep in mind here is that even
unconfirmed transactions can be conflicting, meaning only one can
Building Block #3: Multisig
The third building block of the Lightning Network is also a
straightforward one: multisignature (multisig) addresses. (Or more
Multisig addresses are Bitcoin addresses that - as the name
suggests - require multiple private keys to "unlock" and spend
bitcoins from. Multisig addresses can be set up under all sorts of
conditions. For instance to require two out of three possible keys,
or fifteen out of fifteen, or just about any other combination.
The Lightning Network often uses two out of two (2-of-2)
multisig set-ups. Unlocking bitcoins from 2-of-2 multisig addresses
requires two signatures, from two dedicated keys.
Building Block #4: Time-Locks
The fourth building block is the time-lock. Time-locks can "lock
bitcoins up" in an output, to make them spendable (to be included
in a subsequent input) only at some point in the future.
There are two different types of time-locks: the absolute type,
called CheckLockTimeVerify (CLTV), and the relative type,
). CLTV locks bitcoins up until a (more or less) concrete time in
the future: an actual time and date, or a specific block height.
CSV, instead, uses relative time. Once a CVS-output is recorded on
the blockchain, it takes a specific amount of blocks from
point on before the bitcoins can be spent again.
Building Block #5: Hash Values and Secrets
The fifth and final building block - cryptography - is the most
fundamental building block of Bitcoin itself. But in the Lightning
Network, it's applied in a new way.
In short, a "value" or "secret" is a long and unique string of
numbers that is practically impossible to guess, even for a
computer with infinite tries. With a special calculation, this
value (or secret) can be "hashed" into a different string of
numbers, a "hash." And here's the trick: anyone who knows the value
can easily reproduce the hash. But this doesn't work the other way
around; it's a one way street.
This trick can be utilized in Bitcoin itself, again to "lock
bitcoins up." (In fact, it's really how Bitcoin works.) For
example, a hash can be included in an output, and require the
subsequent input to include the corresponding value in order to be
The First Challenge: Bidirectional Payment
Even before the Lightning Network was presented, the concept of
had been around for some time. Typical payment channels are
useful for certain purposes, but also limited: they are
one-directional. Alice can pay Bob several off-chain transactions,
but Bob cannot pay Alice through the same channel at all.
As a key feature of the Lightning Network, Poon and Dryja
proposed trustless bidirectional payment channels.
Opening the Channel
To set up a bidirectional payment channel, both parties involved
must first agree on an opening transaction. This opening
transaction determines how many bitcoins each deposits into the
Let's say Alice wants to send one bitcoin to Bob. Since Alice
and Bob expect to transact more frequently, they decide to open up
a bidirectional payment channel, and use this to send the bitcoin.
(Sending a whole bitcoin is probably a lot for a payment channel,
as these might be more useful for micropayments - but it's
To open the channel, Alice and Bob each send five bitcoins to a
2-of-2 multisig address. This is the "opening transaction."
Bitcoins can only be spent from this address if both Alice and Bob
sign a subsequent transaction.
Additionally, Alice and Bob both create a secret (a string of
numbers), and exchange the hash.
Alice now immediately creates a subsequent transaction from the
opening transaction. This is a "commitment transaction." With the
commitment transaction, Alice sends four bitcoins to herself, and
six bitcoins to a second multisig address. This second multisig
address is a bit funky. It can be unlocked by Bob on his own, but
only after 1000 extra blocks have been mined after it's included on
the blockchain; it includes a CSV-lock.
, it can be opened by Alice on her own, but only if she
includes the secret for which Bob has just now given her the
hash. (Of course, Alice has no idea what this secret is - she only
knows hash - so there's no way she can make use of this option
Alice signs her end of this commitment transaction. But she
doesn't broadcast it! Instead, she gives it to Bob.
Meanwhile, Bob does the same, but mirrored. He creates a
commitment transaction as well, from which he sends six bitcoins to
himself, and four to a funky new multisig-address. Alice can unlock
this address if she waits an additional 1000 blocks, or Bob can
unlock it with Alice using her secret.
Bob signs this half, and gives it to Alice.
After all this exchanging of "half-valid" commitment
transactions and hashes of secrets, they both sign and broadcast
the opening transaction, to make sure it's recorded on the
blockchain. The channel is now officially open.
At this point, both Alice and Bob could sign and broadcast the
half-valid commitment transaction they got from the other. If Alice
does, Bob gets six bitcoins immediately. If Bob does, Alice gets
four bitcoins immediately. But whomever signs and broadcasts the
transaction will have to wait 1000 blocks to unlock the subsequent
multisig-address, and claim the remaining bitcoins.
However, and this is the key trick of a payment channel: neither
sign and broadcast their half of the transaction at all.
Updating the Channel
A little later, Bob wants to send Alice one bitcoin back. They
want to update the channel state, to make the balance five-five
again. To accomplish this, Alice and Bob do two things.
First, both repeat the process as described above (except that
the opening transaction is already recorded on the blockchain; that
part is skipped). This time, both Alice and Bob attribute
themselves five bitcoins, and both attribute five bitcoins to funky
multisig-addresses. The conditions for these multisig-addresses are
similar, except that they require
secrets: both Alice and Bob provide each other with
hashes. They both sign their new half valid commitment transaction,
and give it to each other.
Second, Alice and Bob hand each other their
secrets, as used in the
At this point, again, both Alice and Bob could sign and
broadcast the new "half valid" commitment transaction they just
got. Their counterparty would get five bitcoins immediately, while
the broadcaster would have to wait 1000 blocks. As such, the
channel is updated.
But what's stopping Bob from broadcasting the older commitment
transaction instead? That commitment transaction led to a path that
paid him six bitcoins, instead of five….
What's stopping Bob, of course, is his first secret, which he
has now given to Alice.
Bob cannot safely sign and broadcast the older commitment
transaction any more, because Alice now knows Bob's first secret.
If Bob were to sign and broadcast that commitment transaction, he
would immediately send four bitcoins to Alice... and he would have
to wait 1000 blocks to claim his own six bitcoins. That's a
problem, because now that Alice knows his secret, she could use
this time to beat Bob to the punch, and claim the other six
bitcoins as well!
And since Bob has Alice's secret too, this is just as true for
the other way around. If Alice tries to sign and broadcast an old
commitment transaction, Bob can steal all the bitcoins in the
This of course means that both Alice and Bob are strongly
incentivized to play fair, and only ever sign and broadcast the
most recent state of the channel.
Next, this bidirectional payment channel set-up needs to expand
to allow payments over a network. This is covered in the second
article of this series.
Thanks to Rusty Russell and Joseph Poon for added