Payment Timeouts in Payment Channels - #3 Timelocks

This 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 payment route with four hops in the route: (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 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 Bobs’ node goes down after Dave received his hashlock from Charlie (Fig. 2). Dave has the key that allows him to unlocks 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 is still able to 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 to 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 and is responsive again, which could take days, weeks. But what happens if Bob dropped off the graph and never responds again? The HTLC between them is valid indefinitely, so the money committed to the HTLC could 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 hashlock is unlocked or backward, back to the sender if the timelock times out.

To receive/unlock payment in a 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 onchain, however the timelocks are only ever executed on chain as a fail safe.

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, but if the timelock times out first Alice can. And the same goes for Charlie vs. Bob, and Dave vs. Charlie.

If Bob goes offline after Dave received 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 comeback online and claim his funds from Alice. Because the 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 deadline of the timelock Alice will be able to retrieve those funds, and Bob is the only one out the money (Fig. 5.).