Partnered With:

Understanding lightning Networks: How do you build lightning Networks? What is a hash time lock?

Read this article in 7 Minutes

Following on from Understanding the Lightning Network: Building a Two-way Payment Channel for Bitcoin, this article continues to explain how the Lightning network is built.

Source: Bitcoin Magazine

The original author :& NBSP; AARON VAN WIRDUM

& NBSP; MinMin & have spent & Ajian, ethereum enthusiast

In this paper, theUnderstanding the Lightning Network: Building a Two-way Payment Channel for BitcoinThen go on to explain how the Lightning network is constructed.

network

In the previous article, Alice and Bob established a two-way payment channel. Now Alice wants to pay 1 BTC to a third party Carol.

In general, Alice and Carol need to open a payment channel between each other. But it doesn't need to. Because there is already a channel between Bob and Carol, Alice can pay Carol through Bob.

Specifically, Alice can pay Bob 1 BTC, and Bob can pay Carol 1 BTC.

But Alice doesn't actually trust Bob, or Carol doesn't trust Bob. She was worried that if she gave the money to Bob, Bob wouldn't give it to Carol; Or he gave the money to Carol, who lied about never seeing it, and Alice didn't know who to blame.

Therefore, Alice wants to ensure that she only needs to pay Bob 1 BTC if Bob gives Carol 1 BTC.

When Alice wants to pay Carol 1 BTC, she asks Mr. Carol to make a secret value (a random string of numbers) and sends her the corresponding hash. Alice also tells Carol that she can trade this secret value for 1 BTC with Bob.

At the same time, Alice sends Bob the hash from Carol, and tells Bob that she will give Bob 1 BTC if Bob can provide the original value corresponding to the hash (which, of course, only Carol has).

So Bob goes to Carol and trades 1 BTC for Carol's initial value.

Bob then retrieves Alice and provides the initial value. So Alice knows that Bob must have paid, that Carol must have received 1 BTC, so she gives the money to Bob.

All is well.

Almost, ah, almost everybody's happy.

In this "play house" scenario, broker Bob still needs the newcomers Alice and Carol. Bob must believe that Carol is giving him a really useful value (otherwise he won't get all the money back), and that Alice will actually give him 1 BTC if he can provide the preimage corresponding to the hash.

This is where we need to hash time lock contracts (HTLC).

Hash time lock contract

A hash time lock allows Alice and Bob to trade secret values for BTC (which Bob and Carol also need, but we won't mention).

To use the hash time lock, Alice sends 1 BTC to a new multi-sign address instead of sending it directly to Bob. A BTC locked at this address can be unlocked in two ways.

The first is for Bob to send his signature along with the secret value to the address.

The second option is for Alice to send her signature to the address. But there is a way. CLTV time lock limit: Alice must wait a certain period of time (say two weeks) before signing and broadcasting the transaction to take this BTC.

That is, Bob has two weeks to create a transaction with a signature and secret value and broadcast it, sending the BTC on the multi-signed address to himself. So the deal is secured. As long as Bob can provide the secret value, he can take Alice's BTC: broadcasting the transaction publicly on the Bitcoin network allows Alice to see it.

If Bob does not provide the secret value within the specified time limit, Alice can get her BTC back. It's that simple.

Back to the web, because that's where hashing time lock contracts really come into play.

As mentioned above, there is not only a hash time lock contract between Alice and Bob, but also between Bob and Carol. Therefore, if Carol asks Bob for BTC, Bob can also get the secret value from Carol. These are all visible on the blockchain.

Therefore, if this happens, Bob must also get 1 BTC from Alice. Bob can publish the secret value from Carol on the chain, send it to his hash time-lock contract with Alice, and then take 1 BTC from the multi-signed address. The two state channels are effectively related.

One final point to emphasize is that Bob must get the secret value from Carol within the validity period, or Alice may get back 1 BTC from the multi-signed address. If Bob didn't get the secret value from Carol until Alice had retrieved 1 BTC, Bob would be stuck in the middle. Therefore, Bob and Carol's hash time-lock contract must expire before Alice and Bob's (for example, the former can be set to 10 days instead of two weeks). This is why hash time lock contracts require CheckLockTimeVerify (absolute time lock) rather than CheckSequenceVerify (relative time lock).

Finally, there is a problem to be solved: for the Lightning network to be usable, all this must be done off-chain. How this is done will be revealed in the third article in this series.