Progress pill
A Liquidity Network

HTLC – Hashed Time Locked Contract

Lightning Network Theory

HTLC – Hashed Time Locked Contract

  • How HTLCs Work
  • Expiration and management of HTLCs in case of problems
  • Representation of HTLCs in commitment transactions
In this chapter, we will explore how Lightning enables payments to transit through intermediary nodes without requiring trust, thanks to HTLC (Hashed Time-Locked Contracts). These smart contracts ensure that each intermediary node will only receive the funds from its channel if it forwards the payment to the final recipient; otherwise, the payment will not be validated.
The issue that arises for payment routing is therefore the necessary trust in intermediary nodes, as well as the trust among these intermediary nodes themselves. To illustrate this, let's revisit our simplified Lightning network example with 3 nodes and 2 channels:
  • Alice has a channel with Suzie.
  • Suzie has a channel with Bob.
Alice wants to send 40,000 sats to Bob, but she does not have a direct channel with him and does not wish to open one. She looks for a route and decides to go through Suzie's node.
If Alice naively sends 40,000 satoshis to Suzie, hoping that Suzie will transfer this sum to Bob, Suzie could keep the funds for herself and not transmit anything to Bob.
To avoid this situation, on Lightning, we use HTLCs (Hashed Time-Locked Contracts), which make the payment to the intermediary node conditional, meaning Suzie must meet certain conditions to access Alice's funds and transfer them to Bob.

How HTLCs Work

An HTLC is a special contract based on two principles:
  • Access condition: The recipient must reveal a secret to unlock the payment due to them.
  • Expiration: If the payment is not fully completed within a defined period, it is canceled, and the funds return to the sender.
Here's how this process works in our example with Alice, Suzie, and Bob:
Creating the secret: Bob generates a random secret noted as s (the preimage), and calculates its hash noted as r with the hash function noted as h. We have:
Using a hash function makes it impossible to find s with only h(s), but if s is provided, it's easy to verify that it corresponds to h(s).
Sending the payment request: Bob sends an invoice to Alice asking, for payment. This invoice notably includes the hash r.
Sending the conditional payment: Alice sends an HTLC of 40,000 satoshis to Suzie. The condition for Suzie to receive these funds is that she provides Alice with a secret s' that satisfies the following equation:
Transferring the HTLC to the final recipient: Suzie, to obtain the 40,000 satoshis from Alice, must transfer a similar HTLC of 40,000 satoshis to Bob, who has the same condition, namely that he must provide Suzie with a secret s' that satisfies the equation:
Validation by the secret s: Bob provides s to Suzie to receive the 40,000 satoshis promised in the HTLC. With this secret, Suzie can then unlock Alice's HTLC and obtain the 40,000 satoshis from Alice. The payment is then correctly routed to Bob.
This process prevents Suzie from keeping Alice's funds without completing the transfer to Bob, as she must send the payment to Bob to obtain the secrets s and thus unlock Alice's HTLC. The operation remains the same even if the route includes several intermediary nodes: it is simply a matter of repeating Suzie's steps for each intermediary node. Each node is protected by the conditions of the HTLCs, as unlocking the last HTLC by the recipient automatically triggers the unlocking of all other HTLCs in a cascading effect.

Expiration and management of HTLCs in case of problems

If, during the payment process, one of the intermediary nodes or the recipient node stops responding, especially in the case of an internet or power outage, the payment cannot be completed because the secret needed to unlock the HTLCs is not transmitted. Taking our example with Alice, Suzie, and Bob, this problem arises, for instance, if Bob fails to transmit the secret s to Suzie. In this case, all the HTLCs upstream of the path are blocked, and the funds they secure are also blocked.
To avoid this, HTLCs on Lightning have an expiration that allows for the removal of the HTLC if it is not completed after a certain time. The expiration follows a specific order, starting with the HTLC closest to the recipient and then progressing to the transaction's issuer. In our example, if Bob never gives the secret s to Suzie, this would first cause Suzie's HTLC towards Bob to expire.
Then the HTLC from Alice to Suzie.
If the order of expiration were reversed, Alice could recover her payment before Suzie could protect herself from potential cheating. Indeed, if Bob comes back to claim his HTLC while Alice has already removed hers, Suzie would be at a disadvantage. This cascading order of HTLC expiration thus ensures that no intermediary node suffers from unfair losses.

Representation of HTLCs in commitment transactions

Commitment transactions represent HTLCs in such a way that the conditions they impose on Lightning can be transferred to Bitcoin in the event of a forced channel closure during the lifespan of an HTLC. As a reminder, commitment transactions represent the current state of the channel between the two users and allow for a unilateral forced closure in case of issues. With each new state of the channel, 2 commitment transactions are created: one for each party. Let's revisit our example with Alice, Suzie, and Bob, but look more closely at what happens at the channel level between Alice and Suzie when the HTLC is created.
Before the start of the 40,000 sats payment between Alice and Bob, Alice has 100,000 sats in her channel with Suzie, while Suzie holds 30,000. Their commitment transactions are as follows:
Alice has just received Bob's invoice, which notably contains r, the hash of the secret. She can thus construct an HTLC of 40,000 satoshis with Suzie. This HTLC is represented in the latest commitment transactions as an output called "HTLC Out" on Alice's side, since the funds are outgoing, and "HTLC In" on Suzie's side, since the funds are incoming.
These outputs associated with the HTLC share exactly the same conditions, namely:
  • If Suzie is able to provide the secret s, she can unlock this output immediately and transfer it to an address she controls.
  • If Suzie does not possess the secret s, she cannot unlock this output, and Alice will be able to unlock it after a timelock to send it to an address she controls. The timelock thus grants Suzie a period to react if she obtains s.
These conditions apply only if the channel is closed (i.e., a commitment transaction is published on-chain) while the HTLC is still active on Lightning, meaning the payment between Alice and Bob has not yet been finalized, and the HTLCs have not yet expired. Thanks to these conditions, Suzie can recover the 40,000 satoshis of the HTLC owed to her by providing s. Otherwise, Alice recovers the funds after the expiration of the timelock, because if Suzie does not know s, it means she has not transferred the 40,000 satoshis to Bob, and therefore, Alice's funds are not owed to her.
Furthermore, if the channel is closed while several HTLCs are pending, there will be as many additional outputs as there are ongoing HTLCs. If the channel is not closed, new commitment transactions are created after the expiration or success of the Lightning payment to reflect the new, stable state of the channel, which is now without any pending HTLCs. The outputs related to the HTLCs can therefore be removed from the commitment transactions.
Finally, in the case of a cooperative channel closure while an HTLC is active, Alice and Suzie stop accepting new payments and wait for the resolution or expiration of the ongoing HTLCs. This allows them to publish a lighter closing transaction, without the outputs related to the HTLCs, thereby reducing fees and avoiding the wait for a possible timelock.
What should you take away from this chapter?
HTLCs enable the routing of Lightning payments through multiple nodes without requiring trust in them. Here are the key points to remember:
  • HTLCs ensure the security of payments through a secret (preimage) and an expiration time.
  • The resolution or expiration of HTLCs follows a specific order: from the destination towards the source, in order to protect each node.
  • As long as an HTLC is neither resolved nor expired, it is maintained as an output in the most recent commitment transactions.
In the next chapter, we will discover how a node issuing a Lightning transaction finds and selects routes for its payment to reach the recipient node.
Quiz
Quiz1/5
What role does the timelock play in the operation of HTLCs?