Hashed Timelock Contracts (HTLCs)

Published in

Coinmonks

6 min readMay 9, 2022

Overview
The Bitcoin network keeps a public ledger of transactions. Due to the size limit of blocks, the Layer 1 blockchain itself cannot handle a large volume of transactions. The Lightning Network solves this issue of scalability through the use of “payment channels”.

Payment channels are established between two parties such that they can make numerous payments between themselves within the capacity of the channel (value of BTC used to fund the channel) without being recorded on the blockchain. Only the funding and closing transactions need to be recorded on-chain.

Because payment channels are between two parties, it would not be economical for one user to open a payment channel to transact with each different entity they wanted to pay. This is where we can utilize the ability to trustlessly route payments along multiple channels on the Lightning network, as one only needs to figure out a path of connected nodes (other participants in the lightning network) to route payments through to your destination. This allows disconnected nodes to pay each other.

One practical example could be that Alice wants to pay Eric for the pizza she bought at his store. Alice does not have a payment channel with Eric but has one with Bob. Bob in turn has a channel with Carol who has a channel with Diana who in turn then has a channel with Eric.
Alice can then route the payment through Bob, Carol, and Diana to Eric.

To route payments trustlessly, the lightning network makes use of Hashed Timelock Contracts (HTLCs)

What are HTLCs?

A Hashed Timelock Contract is a type of smart contract that is both hashlocked and timelocked.
The hashlock restricts the spending of funds locked to a hash until a cryptographic proof is provided while the timelock restricts the spending of funds until a certain time or block height in the future.

“HTLCs have two fundamental clauses: a payment clause secured with a hash lock and a refund clause secured with a time lock. To open a hash lock and claim a payment, the receiver needs to reveal the preimage to a hash digest encoded in the contract. To open a time lock and receive a refund, the spender needs to wait until after a certain time encoded in the contract.”
— Bitcoin Optech

HTLCs are used in different payment implementations such as in atomic swaps — cross-chain trading across cryptocurrencies, and zero-knowledge contingent payments which allow a fair exchange of sold goods and payments across the Bitcoin network, and the Lightning network among others.
For this article, I would be focusing on their use in the Lightning network.

HTLCs in the Lightning Network

HTLCs serve as the fairness protocol for payments made over the Lightning Network.
The process of routing payments on the network starts with an invoice being generated by the recipient and sent to the sender. This invoice contains relevant information such as the payment hash, payment amount, routing hints, etc.
The payment hash `H` is essentially a large random number that has been hashed before being sent to the sender. When the sender receives an offer of the requested amount from one of their channels, they will offer in return the preimage (that hashes to the payment hash) which both allows the payment to settle and which acts as proof that the receiver has received the funds as they are the only one that knows the preimage.

Here is the Bitcoin Script that executes this:

The script has two possible spending paths. The first path sends funds to Bob if Bob can produce `R`

OP IF
    OP HASH160 <Hash160 (R)> OP EQUALVERIFY

If this path is not satisfied, the second path redeems the funds to Alice after the timelock expires.

OP ELSE
    2 <Alice1> <Bob1> OP CHECKMULTISIG
OP ENDIF 1> <Bob1> OP CHECKMULTISIG
OP ENDIF

As simulated earlier, HTLCs can facilitate Alice’s payment of 1BTC to Eric for the pizza she bought as shown below:

Payment routing using HTLCS. Image source — Magomed Aliev

Eric generates a secret(`R`), hashes that secret, and sends it to Alice. The secret is only known by Eric.
Alice’s node calculates the shortest routing path, computes the fees(0.003BTC) for the intermediary nodes together with Eric’s payment(1BTC), and creates an HTLC to pay Bob 1.03BTC if he can provide the secret(also known as preimage) within the next 10 blocks, otherwise, the funds will be refunded to Alice.
The HTLC from Alice incentivizes Bob to create an HTLC to pay Carol who he has a payment channel, 1.02BTC if she can provide the secret(`R`) within the next 9 blocks, otherwise, the funds will be refunded to him.
Carol in turn creates an HTLC to pay Diana 1.01BTC if she can provide the secret(`R`) within the next 8blocks, otherwise, the funds will be refunded to her.
Diana then creates an HTLC to pay Eric 1BTC if she can provide the secret(`R`) within the next 7 blocks, otherwise, the funds will be refunded to her(Diana).
On receiving the HTLC, Eric as the final destination and recipient provides the secret(`R`) he generated and unlocks the HTLC to get the 1BTC payment.

Since Diana now has the secret(`R`), she provides this secret to Carol to unlock her HTLC and retrieve the funds locked in. This secret is back-propagated also through Bob and then to Alice. This is illustrated in the illustration above, steps 6–9.
All nodes in this routing path can claim the funds locked in the HTLCs and complete a successful payment routing.

Limitations

Since the same payment hash is used for all HTLCs throughout a payment route, this could theoretically lead to some issues:

Invoice reuse would lead to a privacy breach and make it easy for nodes who have earlier routed payments using that invoice to be able to spend that HTLC since they already have the preimage/secret.
Susceptibility to wormhole attack: Payment interception and claiming of funds/fees.

Two nodes sharing information (for example, because they’re owned by the same person) can know if they are in a route together by seeing that they have received HTLCs with the same hash. This not only gives them information about routing that we don’t want them to have access to, but it also allows them to perform a “wormhole attack” which consists of them working together to steal the fees of all intermediate hops between them
-SuredBits

Improvement

Point Timelock Contracts(PTLCs) are proposed as a fix to HTLCs.
A PTLC is a bitcoin transaction that locks bitcoin to a point (read: very large number) on Bitcoin’s elliptic curve. It differs from HTLCs in their primary locking and unlocking method.
PTLC point locks are locked using a public key (another point on Bitcoin’s elliptic curve) and unlocked by providing a corresponding signature from a satisfying signature adaptor.

Conclusion
HTLCs are a fundamental part of multipayment channels as they act as escrow to ensure that intermediary nodes route payments trustlessly without anyone cheating. However, the use of the same payment hash throughout the payment route poses some threat to the role of HTLC as a fairness protocol as nodes that know this payment hash might be able to intercept and claim funds (and abruptly end the routing) during back-propagation of the preimage to the sender to confirm payment.

Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing

Hashed Timelock Contracts (HTLCs)

Also, Read

Written by Jennifer Ezeobi