This is the third post in our 3-part introductory series on payment channels! In the last deep dive, we talked about how hashlocks work to create atomic payments in payment channels. In this post, we'll go into timelocks, the second type of locks used to construct HTLCs. Timelocks establish timeouts for payments and enable trustless escrow services in the Lightning Network.

Timeouts with Timelocks

So, why do we need Timelocks in multi-hop payments?

Time is money, and without being able to account for time, it's impossible to process payments.

Imagine you have a payment route with four hops: (1) Alice, (2) Bob, (3) Charlie, and (4) Dave.

In the last post, we showed how Dave generates the random secret preimage (usually abbreviated as "R", but represented here as a key) and computes the hash (represented here as an "H" lock) to send to Alice. Alice locks up funds in HTLC with Bob, Bob does the same with Charlie, and Charlie with Dave. The result is shown in Fig. 1, with 100k sats locked in an HTLC with each peer in the route.

However, these HTLCs don't have any timelocks.

What happens if one of the nodes in the route crashes or goes offline?

Without timelocks, payments can get stuck.

Transactions are only atomic between hops, not for the route as a whole.

Consider what happens if Bob's node goes down after Dave receives his hashlock from Charlie (Fig. 2). Dave has the key that allows him to unlock the hashlock between him and Charlie. Dave sends the key to Charlie, who in turn sends the key to Bob. However, Bob doesn't respond because his node is offline.

But if Bob doesn't respond, Charlie can still use the secret to retrieve the funds from Bob by settling on the blockchain. Using the secret, Charlie will close/fail their channel by sending the last HTLC contract/commitment transaction to the blockchain.

But what happens to the funds between Alice and Bob?

Alice is the one who requested to make this payment, so she's not expecting her money back. However, it doesn't benefit anyone to have BTC stuck in a state where no one can move or claim it.

Alice could wait until Bob comes back online, which could take days or weeks. But what if Bob drops off the network and never responds again? The HTLC between them is valid indefinitely, so the money committed to the HTLC could be stuck there permanently.

What are Timelocks?

Timelocks are the other half of the condition inside of HTLCs.

HTLCs are hashlocks + timelocks, combined with an OR condition. The funds in each channel can only flow one way: forward to the recipient if the hashlock is unlocked, or backward, back to the sender if the timelock times out.

To receive or unlock payment in an HTLC, the recipient can either provide the key for the hashlock OR wait for the timelock to expire. If the hashlock is valid, it can be executed in the payment channel or on-chain; however, the timelocks are only executed on-chain as a failsafe.

How do timelocks "unstick" payments?

Timelocks require that parties in the contract acknowledge a deadline and agree to forfeit the ability to claim the payment, returning funds to the payer after a specific time and date.

Another way to think about this is that the timelock dictates how long Bob has to beat Alice and provide the secret. If Bob produces the secret before the timelock unlocks, he can claim the funds; if the timelock times out first, Alice can. The same logic applies for Charlie vs. Bob and Dave vs. Charlie.

If Bob goes offline after Dave receives his payment from Charlie, Dave can still claim the funds from Charlie, who will in turn try to claim the funds from Bob. Bob has the time remaining in the timelock to come back online and claim his funds from Alice. Because Charlie's transaction is on the blockchain, the secret has been made public and can easily be found. If the funds aren't claimed, after the timelock's deadline, Alice will be able to retrieve those funds, leaving Bob out of the money (Fig. 5).