guides/en/ln-04.md

• Title: HTLC Overview
• Summary: In this chapter we will get into how multi-hop payments can be made.

---

In the previous two chapters we learned how two peers can send funds betwee themselves in a channel by updating state and invalidating old states. In this chapter, we will give an overview of how HTLCs enable multi-hop payments. The next chapter will be a deep dive into HTLCs.

Let's get into it with a simple example!

Simple 3 node, 2 hop network

In this simple network, we have three nodes: Alice, Bob and Charlie. There are two channels between them: one between Alice and Bob and another between Bob and Charlie. Each channel has a capacity of 10 BTC distributed equally between the participants.

For simplicity's sake, we only show one commitment transaction spending from the funding transaction hence determining channel state. This is not exactly accurate as we learned about asymmetric commitments in the last chapter, but for the purposes of understanding HTLCs this simplification will be easier. A more precise description will be given in a later chapter.

Now, let's suppose that Alice would like to pay Charlie. She can't pay him directly since they do not have a channel with each other and it is costly (in terms of time and money) to open a channel just for one quick transaction. Instead, Alice can use her channel with Bob to route a payment to Charlie since Bob and Charlie share a channel.

Step 1: Generating and sharing a pre-image hash

Alice first needs to tell Charlie she wants to pay him. Charlie will then generate a random secret S, and get the hash of S which we will call H. Charlie sends H to Alice.

Step 2: Setting up the chain of HTLCs

Let's say Alice wants to pay Charlie 1 BTC. She needs to first find a route to Charlie. In this case it's A-B-C. She also sees that in order to use this route, she needs to incentivise Bob to help her out by giving him a routing fee. Let's say Bob charges a flat fee of 1 BTC for routing payments so Alice will be paying a total of 2 BTC: 1 BTC for routing and 1 BTC for Charlie. Alice then signals to Bob that she would like to route a payment by suggesting that they update their channel state. In this simplified example, the channel's commitment transaction will have the following outputs (remember that in reality Alice and Bob will both have their own commitment transactions):

• An output of 3 BTC back to Alice.
• An output of 5 BTC to Bob.
• An output of 2 BTC to a special script that has 2 possible spending paths:
  1. The first path can be spent by Bob if he has the pre-image of H
  2. The second path can be spent by Alice after an absolute time cltv_expiry_AB

This last output with a special scripting locking up the 2 BTC is called a Hash and Time Lock Contract (HTLC) because it has one hash-locked path and one time-locked path.

Bob will happily update to this new channel state because he can see that he is not losing money: if the transaction goes on-chain and he still does not have the pre-image then he still gets back his original funds. He can also see that if he cooperates and forwards the payment then he will be rewarded with a routing fee if the payment is successful because he will be able to claim the hash-locked output on the transaction.

Bob now locks up some funds in a similar way in his channel with Charlie. He updates the channel commitment transaction to include the following outputs:

• An output of 4 BTC to Bob
• An output of 5 BTC to Charlie
• An output of 1 BTC to an HTLC script that again has two spending paths:
  1. The first path is spendable by Charlie if he can reveal the pre-image of H
  2. The second path is spendable by Bob after a cltv_expiry_BC

Bob can confidently lock up his funds this way because he knows that if the payment fails then he will be able to claim his funds back via the time-locked path and if the payment succeeds and Charlie reveals the pre-image when he spends via the hash-locked path then Bob will see this pre-image and can claim the hash-locked output in the HTLC from the commitment transaction he has with Alice.

When Charlie receives this HTLC offer from Bob, he can see that he does in fact know the pre-image S that hashes to H, so he knows that he can claim the hash-locked path of the commitment transaction's HTLC output if it were to go on-chain. Ideally though, things don't have to be settled on-chain. Instead, Charlie simply sends the pre-image S to Bob. This proves to Bob that Charlie would claim the HTLC output if they were to go on-chain and so now Bob and Charlie can agree to just update their commitment transaction to reflect that Charlie now has 1 more BTC:

Now that Bob has the pre-image S, he can turn around and reveal S to Alice, proving that if their commitment transaction goes on-chain, Bob would claiom the hash-locked output. So as Bob and Charlie did in their channel, Alice and Bob update their commitment transaction by removing the HTLC output to reflect the new balance of funds:

Alice sent Charlie 1 BTC and Bob earned 1 BTC in routing fees.

cltv_expiry

What if things go wrong? For example, Charlie goes offline and doesn't respond to Bob with a pre-image. If this happens then Bob will need to broadcast the commitment transaction so that he can claim his funds back via the time-locked path of the HTLC. If he does broadcast the transaction but then Charlie comes back online before the cltv_expiry_BC and spends via the HTLC's hash-locked path then Bob will see the pre-image on-chain and will thus be able to turn around to Alice and reveal the pre-image to her as usual.

From this example, you can see that it is important for the cltv_expiry values to decrease along the path from the sender to the receiver. This is because in the worst case, Charlie only reveals S to Bob just before cltv_expiry_BC and then Bob still needs time to go to Alice and reveal S before she is able to spend along the cltv_expiry_AB path. In other words, cltv_expiry_BC must be before cltv_expiry_AB.

Review

• Hash and Time Lock Contract (HTLC): A special output script in the commitment transaction that has one hash-locked path and one time-locked path
• Check-locktime verify (CLTV): The absolute time lock used in HTLCs which must decrease along the payment route from the sender to the receiver

References

• BOLT2
• LN Things Part 4: HTLC Overview by nostr:nprofile1qqswrt9pnxatlplu49h6meld8svmwqt87wwvk256rqk07n6eu4qeh5gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dszpfjtz
• Timelocks