In the previous article about payment channels as the basis for the Lightning Network, we discussed how payment channels make it possible to make a large number of transactions between two parties, without directly burdening the blockchain and without compromising on trust. In this article we extend the bidirectional payment channels to Hashed Time-Lock Contracts (HTLCs).

The next step towards the Lightning Network

In the previous article, we described how unidirectional and bidirectional payment channels work. But, while powerful for two-party payments, the capabilities of a simple bidirectional payment channel are limited when we want to enable payments across an entire network of users. After all, it is only possible to make payments between parties that have a payment channel open with each other. HTMLs are an extension of bidirectional payment channels that make it possible to make payments to parties with whom a payment channel has not immediately been opened. HTCs are therefore the next step in the foundation for the Lightning Network.

Transfer payments

With a bidirectional payment channel, Alice and Bob can easily, cheaply and quickly make a large number of payments to each other. But what if Alice wants to make a payment to Carol, or to Dave, with whom she has not opened a payment channel? It would be inefficient and expensive if Alice had to open a separate payment channel for every payment she wants to make to another party. What we can do is let Alice use the already existing payment channels between other parties.

By letting Alice use the already opened payment channel between Bob and Carol, Alice can send a payment to Carol via Bob. This prevents the blockchain from having to be taxed, and the transactions remain fast and cheap.

However, there are a few trust issues with this approach, which is exactly what we want to avoid. There are two issues that immediately become apparent:

1. What prevents Bob from keeping the payment of 0.01 BTC for himself? There is nothing implemented that forces Bob to forward the payment to Carol. We’ll have to trust Bob to act honestly.
2. How do we know that Carol will be honest about the payment she received? After all, upon receipt of the payment, if Bob indeed acts honestly, she can claim that the payment she received does not come from Alice, but from another party. There is no guarantee that Carol will act fairly.

However, these problems can be solved by making smart use of the scripting functionality that Bitcoin offers. We can make the payments from Alice to Bob and from Bob to Carol dependent on certain conditions. We call this a Hash-Locked Contract (HLC) .

A hash function is an algorithm that, given a certain input, generates a unique output. It is not possible to calculate back what the input was from the generated output, but it is possible, given the input, to check that the previously displayed output is correct by running the algorithm again with the input.

In an HLC, Carol generates a random number R and takes its hash ( H ). Then Carol sends the hash H to Alice.

Alice then creates a transaction of 0.01 BTC to Bob on the condition that Bob can show R that matches the given H. Bob does the same with a transaction to Carol: he sends a transaction of 0.01 BTC to Carol, again on the condition that Carol can show R.

Carol is now able to claim the payment she received from Bob; After all, Carol is the only one who knows the right R for H. When Carol claims Bob’s payment, she gives R prize to Bob, which in turn allows Bob to claim the payment he received from Alice. This construction ensures that:

1. Bob cannot choose to keep Alice’s payment himself; after all, he must first make payment to Carol before he can claim payment from Alice, and
2. Alice is sure (and can prove) that her payment went to Carol; after all, the payment could only be claimed with the correct R for the given H that came from Carol.

However, there is also another trust issue with this solution:

• If Carol refuses to disclose R , she may be able to delay payment until the payment channel between Alice and Bob expires. When this happens, Carol could claim payment from Bob, without Bob having the opportunity to claim payment from Alice. So Bob runs the risk of losing money and has to rely on Carol to cooperate.

This problem can be overcome by again making smart use of the scripting functionality that Bitcoin offers and adding a time factor to the HLC: a Hashed Time-Lock Contract (HTLC) . Let’s now say that Bob has three days (or some other amount of time) to show the correct R to Alice. If Bob does not do this within three days, the payment (read: the contract) of 0.01 BTC that Alice sent to Bob will expire.

We can now expand the example to make it look more like a network. Bob and Carol in this example are arbitrary intermediaries and represent any number of intermediaries who facilitate payment from Alice to Dave. In practice, this can be a single intermediary, or any number of intermediaries. What is important is that a route is possible from Alice to Dave, so that the payment can take place. In this scenario, Dave generates the random number R and sends the hash of R , H , to Alice.

Alice then creates an HTML for the payment to Bob with, in addition to the condition that R is required to claim the amount, the condition that the payment must be completed within three days. Bob does the same with Carol, but sets the payment completion time to two days. Finally, Carol does the same with Dave, with the condition that payment must be completed within one day.

Now Dave is able to claim the payment Alice wants to make to him; After all, Dave knows the R needed to meet the requirements of the HTML. But what if Dave decides to stop cooperating or drops out of the network? There is then no risk for any of the intermediaries of losing the payment they have reserved. The entire series of HTLCs will close in reverse, starting with the HTLC between Carol and Dave because it has the shortest time condition. This means that the risk for the intermediaries is mitigated at every step and (micro) payments can be sent through a network without trust.

??

The advantages:

• (Almost) all payments can take place off-chain, so that the Bitcoin blockchain is not burdened and the pressure on the network is relieved.
• A network of payments is created on top of the Bitcoin network. The Lightning Network makes smart use of the resources Bitcoin offers and operates as a second layer on top of Bitcoin. This helps maintain the decentrality and trustlessness of the Bitcoin network itself.
• By directing payments through the network, it is not necessary to open many new payment channels often: a single, or a few, payment channels per person is sufficient to reach everyone in the network.
• Because the transactions take place off-chain, they are:
  • Cheap – no fee has to be paid to the miners for every transaction.
  • Micro – due to its low cost it is possible to make real micro payments from a single satoshi (0.00000001 BTC) and even smaller.
  • Instant – Payments via the Lightning Network are instant, no need to wait for confirmation.

The Lightning Network in essence

The unidirectional and bidirectional payment channels, the hash-locked contracts (HLC) and the hashed time-locked contracts (HTLC) as described in this and the previous article are essentially the entire foundation of the Lightning Network. There is of course much more to actually implementing this theory, such as solving the problem of how payments can be efficiently routed through the network of payment channels. But the clever use of the possibilities offered by Bitcoin’s scripting functionality to enable a network of off-chain Bitcoin payments is the big innovation. Innovation that is now almost a reality.