Understanding the Lightning Network --- Building a Bidirectional Payment Channel for Bitcoin

Original title: "Popular Science | Understanding Lightning Network, Part-1: Building a Bidirectional Payment Channel for Bitcoin", author AARON VAN WIRDUM

The Lightning Network is probably the most anticipated innovation on the Bitcoin blockchain (Editor's Note: Originally written in 2016). This payment scheme was first proposed by Joseph Poon and Tadge Dryja more than a year ago. It claims to support users to send unlimited transactions off-chain, and the cost is extremely low-it can also borrow the security provided by the Bitcoin network.

At least three companies - Poon and Dryja's Lightning, Blockstream and Blockchain - are developing implementations of this technology. But few outside the narrow circle of technologists understand how the "future of micropayments" could unleash bitcoin's potential.

In this series of articles, Bitcoin Magazine attempts to enumerate the most basic building blocks of the Lightning Network and show how these things can be combined to form the Lightning Network, an upcoming protocol.

The first article in this series will list the necessary modules and show how they can be combined to create "smart contracts"; a concept that can be used to understand the first premise of the Lightning Network: bidirectional payment channels.

(Hint: readers who are very familiar with Bitcoin can skip the introduction to these modules.)

Module #1: Unconfirmed Transactions

At the heart of the Bitcoin protocol is the concept of so-called "transactions"; in general, a transaction is always associated with another preceding transaction and can be used in future transactions. Each transaction consists of an input, which points to the address from which bitcoins are transferred, and an output, which points to the address from which bitcoins are received. In addition, in order to send bitcoins, the input must meet certain conditions, such as providing a digital signature to prove that the sender has "ownership" of the input address. At the same time, the output will also establish new conditions for these bitcoins to be used in the future, which must be met when the subsequent transaction is issued.

(Translator's Note: Think of Bitcoin as a check with a denomination. When used, the check itself gives the source of funds, and a new check will be formed after use. So for each check, There are transactions that form this check, that is, the previous transaction; and when these checks are spent again, that transaction can be called the subsequent transaction.)

image description

- (Translator's Note: As shown in the figure, Bitcoin can be split like a check, and its circulation will form a clear chain.) -

Module #2: Double-Spend Protection

The second module required by the Lightning Network probably doesn’t need much explanation, as it is arguably the raison d’être of the Bitcoin protocol itself: a safeguard against multiple payments. If two transactions (or inputs) depend on the same output, only one of them will be confirmed by the entire network.

Remember: Even if there is a conflict between unconfirmed transactions, only one will be confirmed in the end.

Module #3: Multisig

The third module of the Lightning Network is also well understood: multi-signature addresses. (Or more broadly: P2SH addresses (script hash addresses).)

As the name suggests, a multi-signature address is an address that requires multiple private keys to "unlock" and spend bitcoins. The conditions for multi-signature addresses can be set in various ways. For example, it can be required that 2 of the 3 private keys participate in the transfer of bitcoins; or other quantity requirements (such as 2/5, 3/4, etc.).

The Lightning Network generally uses a 2-2 multi-signature requirement. To transfer bitcoins from such an address, you need to provide two signatures related to these two private keys, and one less will not work.

Module #4: Time-Locks

The fourth module is a time lock. The timelock feature places a lock condition on an output so that these bitcoins can only be spent (i.e. used as an input to a transaction) after a certain time in the future.

There are two types of time locks: 1) absolute time lock, called CheckLockTimeVerify (CLTV); 2) relative time lock, CheckSequenceVerify (CSV). CLTV locks bitcoin until some (arguably) specific date in the future: a specific time and date, or a specific block height; whereas CSV only uses relative times. When a CVS output is uploaded to the chain, it must wait for a certain number of blocks before the output can be spent.

Module #5: Hashes and Secrets

The fifth and final module - cryptography - is also the most fundamental module of Bitcoin itself. But in the Lightning Network, usage is different.

In short, a "secret value" is a very long and unique string of numbers that is almost impossible to guess, even if a computer does countless violent calculations. And through special calculations, this secret value can be "broken up" into a different number, called "hash value". This is where the interesting thing is: someone who knows the secret value can easily calculate its hash value, but the reverse is not true, you can't reverse the secret value with the hash value.

On the Bitcoin blockchain, this mechanism can again be used to "lock bitcoins" (in fact, locking bitcoins is how the bitcoin protocol works). For example, you can include a hash value in an output and require subsequent transactions to spend the output only if they include the secret value corresponding to the hash value.

The first challenge: two-way payment channel

Before the Lightning Network, there was already the concept of "payment channels". Standard payment channels are purpose-built and therefore limited: they are one-way channels. Alice can initiate a Dobby payment to Bob off-chain, but Bob cannot use the same channel to pay Alice.

A key feature of the Lightning Network is the trustless two-way payment channel proposed by Poon and Dryja.

open channel

To establish a two-way payment channel, both parties involved must first reach a consensus on a transaction to open the channel. This opening transaction determines how much bitcoin each of them will deposit in this channel.

Suppose Alice wants to send 1 btc to Bob. Because both of them expected to have frequent exchanges in the future, they decided to open a two-way payment channel. (Sending 1 btc in a channel is probably a bit too much, after all channels are probably more useful for micropayments - but it's totally doable.)

To open the channel, Alice and Bob each send 5 btc to a 2-2 multi-signature address. This is the "channel opening transaction". The money in this address can only be spent if Alice and Bob sign the same transaction.

Additionally, both Alice and Bot each create a secret value (that is, a string of numbers) and then exchange hashes.

Now, Alice creates a subsequent transaction of the channel opening transaction, and this is a "commitment transaction". In this commitment transaction, Alice sends 4 btc to herself, and 6 btc to the second multi-signature address; this multi-signature address is more interesting: Bob can unlock this address alone, but, wait (Alice's transaction After 1-00 blocks on the chain, Bob can spend the money in it (this is a relative time lock); Alice can also open this address alone, provided that she also has the hash value corresponding to Bob's gift to her. the secret value of . (Of course, Alice is completely ignorant of this secret value—all she has is the hash value Bob gave her—so it’s only ostensible.) (Translator’s Note: That is, this second multisignature address is both There are time locks and hash locks.)

Alice signs her commit transaction. But she won't broadcast the transaction! Instead, she will just send the transaction to Bob.

At the same time, Bob also does exactly symmetrical operations. He also created a commitment transaction, sending 6 btc to himself and 4 btc to a new multi-signature address. Alice can unlock the address alone after waiting 1000 blocks, or Bob can unlock the address with Alice's secret value.

Bob signs the transaction and sends it to Alice.

After exchanging these commitment transactions and hash values, they sign together and broadcast the channel opening transaction so that it can be uploaded to the chain. Now, a two-way payment channel is opened.

After opening the channel, both Alice and Bob can sign and broadcast partially valid commitment transactions they got from local. If Alice broadcasts (Bob sent her a commitment transaction), Bob will immediately get 6 btc. If Bod broadcasts, Alice will immediately get 4 btc. But the one that signs and broadcasts the transaction must wait for 1000 blocks to unlock the subsequent multi-signature address and take away the remaining bitcoins.

However, this is the key trick of payment channels: not signing and broadcasting the commitment transactions they get.

(Translator's Note: The purpose of first interacting with the commitment transaction and then broadcasting the channel opening transaction is to avoid fraud by the opponent; after obtaining the commitment transaction, there is no need to broadcast, and the security guarantee can also be obtained.)

update channel

Later, Bob wants to send 1 btc back to Alice, and they want to update the state of this channel so that it returns to a 5:5 state. To achieve this, Alice and Bob need to do two things.

First of all, both parties have to go through the process described above again (except for the part of opening the transaction, because it has been recorded on the chain). This time, both Alice and Bob assign 5 btc to each other, and both assign 5 btc to that multi-signature address. The conditions for these subsequent multi-signature addresses are similar, except that they all need to generate new secret values: both Alice and Bob provide new hash values. They both sign their own new commitment transactions and send them to each other.

Second, both Alice and Bob hand each other their first secret value (the one used in the first commitment transaction).

At this point, both Alice and Bob can sign and broadcast their latest commitment transaction. Their opponents would immediately get 5 btc, while broadcasting themselves would have to wait 1000 blocks. Just like that, the state of the channel is updated.

But what's stopping Bob from broadcasting the old committed transaction? That commit transaction would allocate him 6 btc, which is more than 5 btc...

What stops Bob, of course, is his first secret value, the one he has already given to Alice.

Because, at this time, Bob can no longer sign and broadcast the older commitment transaction as he likes, because Alice already knows Bob's first secret value. If Bob were to sign and broadcast (the one Alice gave him) an older commitment transaction, he would immediately send 4 btc to Alice... and he would have to wait 1000 blocks to claim it himself, but Alice already knew he The secret is worth it, so she can use this time to pre-emptively withdraw the remaining 6 btc!

And, since Bob also has Alice's secret value, the same is true for Bob! If Alice wants to sign and broadcast the old commitment transaction, Bob can steal all the btc she put in the channel!

This means that Alice and Bob both reorganize their incentives not to play tricks, but to broadcast only the most recent state.

Well, after having a two-way payment channel, we need to expand it into a payment network. This is the subject of our second article.

Thanks to Rusty Russell and Joseph Poon for their dedicated feedback.