Partnered With:

Understanding the Lightning Network: Building a two-way payment channel for Bitcoin

Read this article in 18 Minutes

The Lightning Network is perhaps the most anticipated innovation on bitcoin's blockchain.

原文标题：《 UNDERSTANDING THE LIGHTNING NETWORK, PART 1: BUILDING A BIDIRECTIONAL BITCOIN PAYMENT CHANNEL 》

原文作者： AARON VAN WIRDUM

原文编译：阿剑，以太坊爱好者

The Lightning Network is perhaps the most anticipated innovation on bitcoin's blockchain. The payment scheme, first proposed more than a year ago by Joseph Poon and Tadge Dryja, claims to enable users to send an unlimited number of transactions off-chain at a very low cost -- and to borrow from the security provided by the Bitcoin network.

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

In this series, Bitcoin Magazine Try to list the basic building blocks of the Lightning Network and show how they can be combined into an upcoming protocol like lightning Network.

The first article in this series will list the necessary modules and show how they can be combined to create a "smart contract"; This concept can be used to understand the first premise of lightning networks: a two-way payment channel.

(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 what are called "transactions"; In general, a transaction is always associated with another prior transaction and can be used in future transactions. Each transaction includes Input, point to Roll out & have spent The address of a Bitcoin; And & have spent Output, pointing to Received & have spent The address of the bitcoin. In addition, in order to send bitcoin, the input must also meet some 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 establish new conditions under which those bitcoins will be used in the future. Post-order transaction & NBSP; It must be satisfied when it is sent.

Think of Bitcoins as cheques with denominations that, when used, give themselves the source of funds, and then form new cheques when used. So for every check, there is a transaction that forms the check, that is, a prior transaction; When the checks are spent again, the transaction is called a sequential transaction.)

A key feature of the Lightning Network is that it is made up of more or less regular Bitcoin transactions. It's just that these transactions generally don't spread across the Bitcoin network. Instead, these transactions are kept local to the node by the user -- except that they can be spread across the Bitcoin network at any time.

- (As you can see, bitcoin can be split like a check, and flows in a clear chain.) -

Module #2: Double-Spend Protection

The second module required by the Lightning network may not require much explanation, as it is arguably the raison d 'oeuvres of the Bitcoin protocol itself: a precaution against multiple payments. If two transactions (or inputs) depend on the same output, only one of them will be validated by the entire network.

Remember: even if there is a conflict between unconfirmed transactions, only one will be confirmed.

Module #3: Multisig

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

As the name suggests, a multi-signed address is an address that requires multiple private keys to "unlock" and use Bitcoin. Conditions for multi-signature addresses can be set in a variety of ways. For example, you can require two out of three private keys to be involved in order to roll out bitcoin; Or other quantity requirements (such as 2/5, 3/4, etc.).

Lightning networks generally use a 2-2 multi-signature requirement. Transferring bitcoin from such an address requires two signatures associated with the two private keys, not one.

Module #4: Time-locks

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

There are two types of time locks: 1) absolute time locks, called CheckLockTimeVerify (CLTV); 2) Relative to time locks, CheckSequenceVerify (CSV). CLTV locks bitcoin down to some (arguably) specific point in the future: a specific time and date, or a specific block height; CSV only uses relative time. When a CVS output goes up the chain, it waits for a certain number of blocks before it can be used.

Module #5: Hash and secret values

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

In short, a "secret value" is a long, unique string of numbers that is almost impossible to guess, even if a computer crunches it a million times. This secret value can then be "broken up" into a different number, called a "hash", by a special calculation. Here's where it gets interesting: knowing the secret is worth it makes it easy to calculate the hash, but not the other way around. You can't figure out the secret by holding the hash.

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

The first challenge: a two-way payment channel

The idea of a "payment channel" predates the Lightning Network. Standard payment channels are used for specific purposes and are therefore limited: they are one-way channels. Alice can initiate a Dobie payment to Bob down the chain, but Bob cannot pay Alice in the same channel.

A key feature of lightning networks is the trust-free two-way payment channel proposed by Poon and Dryja.

Open channel

To establish a two-way payment channel, both parties involved must first agree on a transaction to open the channel. This opening transaction determines how many bitcoins each of them will deposit into the channel.

Let's say Alice wants to send Bob 1 BTC. Because they both expected to be in frequent contact, they decided to open a two-way payment channel. (Sending 1 BTC in a channel might be a bit too big, since 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-signed address. This is called a channel-opening transaction. The money in this address can only be spent if Both Alice and Bob sign the same transaction.

In addition, Alice and Bot each create a secret value (that is, a string of numbers) and exchange hashes.

Now, Alice creates a subsequent transaction to the channel opening transaction, and this is a "promise transaction." In this commitment transaction, Alice sends 4 BTC to herself and 6 BTC to the second multi-signature address; This multi-signed address is more interesting: Bob can unlock the address alone, but he can't spend the money in it until 1-00 blocks (after Alice's transaction is chained); Alice can also open the address on her own, if she. Also & have spent Has the secret value corresponding to the hash value Bob gave her. (Of course, Alice has no idea what this secret is worth -- she only has the hash Bob gave her -- so it's only ostensibly possible to do this.) (This second multi-signed address has both a time lock and a hash lock.)

Alice signed her promise. But she would not broadcast it! Instead, she will only send the transaction to Bob.

At the same time, Bob is doing exactly symmetric operations. He also created a commitment transaction, sending 6 BTC to himself and 4btc to a new multi-signature address. Alice can wait 1,000 blocks to unlock the address alone, or Bob can unlock the address with Alice's secret value.

Bob signed the transaction and sent it to Alice.

After exchanging these committed transactions and hashes, they co-sign and broadcast that channeled open transaction, enabling it to be chaining. Now, a two-way payment channel is open.

After the channel is opened, both Alice and Bob can sign and broadcast the partially valid commitment transactions they receive from the local. If Alice broadcasts (the promised transaction Bob sent her), Bob gets 6 BTC immediately. If Bod is broadcast, Alice will immediately get 4 BTC. But the one who signed and broadcast the transaction had to wait 1,000 blocks to unlock the subsequent multi-signed address and take the rest of the bitcoin.

But that's the key trick for payment channels: not to sign and broadcast the promised transactions they get.

The purpose of the transaction is to avoid fraud by the opponent; After obtaining the promised transaction, you can obtain the security guarantee without broadcasting.

Update the channel

Later, Bob wants to send back 1 BTC to Alice, and they want to update the state of the channel back to the 5:5 state. To do this, Alice and Bob need to do two things.

First, both parties go through the above process again (except for the opening part of the transaction, which is 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 & NBSP; New & have spent Secret value: Both Alice and Bob must provide it. New & have spent The hash value. They both sign their new commitments and send them to each other.

Second, Both Alice and Bob put their The first & have spent The secret value (used in the first commitment transaction) is given to the other party.

At this point, Both Alice and Bob can sign and broadcast their latest promise. Their opponent would immediately get 5 BTC, while broadcasting themselves would have to wait for 1000 blocks. In this way, the status of the channel is updated.

But what's to stop Bob from broadcasting old commitment transactions? That promised transaction would assign him 6 BTC more than 5 BTC...

What stops Bob, of course, is his first secret value, which he already gave Alice.

Bob can no longer sign and broadcast the older promise transaction at will, because Alice already knows Bob's first secret value. If Bob wants to sign and broadcast an older commitment transaction (the one Alice gave him), he will immediately send 4 BTC to Alice... And he has to wait for 1000 blocks to claim, but Alice already knows his secret value, so she can use this time to pre-empt and just take the remaining 6 BTC!

And because Bob also has Alice's secret value, the same is true for Bob! If Alice wants to sign and broadcast old promise transactions, Bob can steal all the BTC she has in the channel!

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