Understanding Hashed Time-locked Contracts (HTLCs)

During our last AMA with our CTO, Paddy Cerri, we’ve quickly mentioned the topic of interoperability with other blockchains. Recently, users have realized that moving from one blockchain ecosystem to another without centralized entities might be an endeavor worth pursuing.

Yet, many cross-chain bridges fall short of being a long-term solution, as Vitalik Buterin (founder of Ethereum) pointed out.

Trading one supposedly trustless cryptocurrency for another using a centralized exchange or a custodial bridge (one has to trust) seems inconsequential at best and comes with the risk of loss of funds at worst.

Fortunately, one technology enables trustless exchange between different cryptocurrencies across chains without involving third parties or bridges. That technology are Hashed time-locked contracts (HTLCs).

What are Hashed time-locked contracts?

By now, most crypto enthusiasts are familiar with smart contracts, and despite their potential, Hashed time-locked contracts seem less known.

Like smart contracts, they establish a transactional agreement to produce conditional payments. In a very simple scenario, a sender of a payment can create a transaction with a deadline. Suppose Alice wants to send Bob $100 in crypto for his upcoming ski trip. She sets the deadline to Friday before his departure to make sure that he gets the payment before being off the radar for weeks. If Bob acknowledges the receipt of the payment before that Friday, he’ll receive the money. If not, it’s automatically refunded to Alice.

Hashed time-locked contracts can establish one-directional payments, or bi-directional, if, for example, Bob were to send something back to Alice.

To do so, they combine two concepts:

• Hashlock: is a type of restraint that restricts spending of an output until a specified kind of data is available — in the case of crypto transactions, an acknowledgment from the recipient.
• Timelock: locks out a transaction until a preset or pre-determined time is reached. Neither the sender nor the recipient can access the funds during that time.

How do HTLCs work?

Hashed time-locked contracts use multi-sig. Multi-sig is short for multiple signatures and enforces that HTLCs require various private and public key pairs to verify and validate transactions.

Private key: the key that allows a cryptocurrency owner to spend the crypto associated with it. Never share your private key with others, because that’d enable them to spend your funds. Could be compared to your PIN code to access your bank account in traditional finance.

Public key: this key is also known as public address. When shared with others they can send cryptocurrency to that address, which you will be able to spend using your private key. In a TradFi context, this would be your IBAN/SEPA/ Account number.

In very simple terms HTLCs involve a sender of a transaction locking cryptocurrency up in a contract, and sharing a secret with the recipient. If the recipient can provide the correct secret before a set deadline, they can spend the funds. If not, the funds go back to the sender.

We can visualize the process using Alice who wants to send money to Bob for his Ski Trip.

1. Alice creates a Hashed Time-Locked contract address and deposits the crypto she wants to send to Bob in it.
2. She then generates a key and hashes it. This is the passcode also called a ‘preimage’ that will unlock the transaction.
3. Alice sends the preimage to Bob.
4. Bob can use this preimage to claim the funds before the deadline Alice has set.
5. If he doesn’t claim the funds before his ski trip, the cryptocurrency is automatically returned to Alice.

While in this example, Alice used a deadline set after a certain period of time, Timelocks can be set either using:

• CheckLockTimeVerify: This lets users specify a time and date for releasing it. When using this in a contract, constraints are hard-coded to the specific time and Alice can’t cancel or amend the transaction before that deadline.
• CheckSequenceVerify: when using this in a contract, the expiry of the transaction isn’t dependent on time, but on the number of blocks generated. Instead of adding a fixed time, Alice could define that her transaction will expire after 1000 blocks.

While the process might sound complicated, and it does indeed involve a lot of cryptography, various apps, and wallets make it user-friendly. With a few clicks, and copy-pasting the preimage, anyone should be able to create a Hashed Time-Locked contract.

Benefits and Limitations of HTLCs

HTLCs offer various benefits for users looking for alternative ways to interact with others without intermediaries. Major benefits include:

• Efficiency: traders won’t have to wait forever to find out whether payments have gone through, and if they didn’t they will automatically receive their funds back.
• Trustless: instead of relying on a bank to broker transactions, the entire process is based on code, in line with the idea of “code is law”.
• Validation: transactions and secret sharing are based on well-researched and frequently used cryptographic functions.
• Cross-chain: while it currently often requires bridges to trade between different Blockchains, with HTLCs one can transfer across different currently silo-ed blockchain ecosystems.

Yet, there are still a few limitations to HTLCs, outside of not being well-understood by mainstream users yet. The biggest one is adaptability. For currencies to be exchanged cross-chain, they need to fulfil certain requirements such as sharing the same hash algorithm, support for HTLCs, and having certain programming functionalities.

The number of wallets supporting HTLCs is still low but continues growing. One development, in particular, has recently driven interest in this technology: the growth of the Lightning Network in the past year. It experienced its most famous implementation to date when the state of El Salvador announced it would make Bitcoin legal tender.

Bitcoin Lightning

Proof-of-Work chains don’t scale on the base layer. And with Bitcoin’s increased adoption, transaction fees have increased making it unsuitable for day-to-day payments. That’s where layer-2 scaling solutions like Lightning come into play.

While transacting on the mainchain is expensive, users can rely on the Lightning Network, a second layer, to route their transactions through peer-to-peer channels. This network of payment channels operated by individuals and institutions is only possible thanks to Hashed Time-Locked Contracts.

In the previous transaction example, we had a transfer from Alice directly to Bob. But what if they could transfer without having to establish a channel between the two of them?

Suppose Alice has an existing payment channel with her friend Charlotte and wants to transfer crypto to Bob.

1. Charlotte opens a payment channel to Bob.
2. Bob generates a random number and then uses the SHA256 algorithm to create a hash of that number. He hands that hash to Alice.
3. Alice now sends the crypto payment to Charlotte, along with the Hash she received. She adds a condition to the payment that Bob will have to share the data used to produce the hash to claim the payment.
4. Charlotte sends the crypto to Bob using her payment channel. She adds the same condition that Alice put on the payment.
5. Bob, who has the pre-image (data used to generate the Hash) can now claim his payment.
6. When doing so, he also makes the pre-image available to Charlotte.
7. Charlotte now uses the pre-image to finalize her payment from Alice.

While it looks like a complicated process, it all comes down to everyone in the chain only being able to claim their payment once they have shared the pre-image, and routed payments according to instructions.

Thanks to HTLCs payment channels between individuals can connect and create a network of chained transactions. Without HTLCs there would have been no guarantee for individuals that payment operators would route their payments to the final destinations.

Another exciting use case for HTLCs are the so-called Atomic Swaps.

Atomic Swaps

In computing, the word “atomic” is used to describe processes that either finalize as intended or don’t initiate at all. Atomic swaps refer to a token swap across blockchains that doesn’t involve any intermediaries, not even a DEX (decentralized exchange).

The first proposal of such a trustless exchange was made by Sergio Demian Erner in 2012, but it wasn’t until 2013 when Tier Nolan introduced a first full account of the procedure for atomic swaps.

For four years swaps remained in the realm of theory. Then in 2017 Decred and Litecoin were the first blockchain ecosystems to successfully complete an atomic swap.

When Alice wants to trade her Litecoin for Decred with Bob, she doesn’t have to go to an exchange anymore. She can use atomic swaps to initiate a true peer-to-peer exchange.

1. Alice generates a hash with her private key, which is then used to create the contract address of the HTLC. She then sends the hash to Bob. Bob does the same.
2. Both add their funds to the channel, Alice sends Litecoin, and Bob adds Decred.
3. Alice now uses the hash she received to unlock her Decred. When doing so, she unlocks the address and reveals the necessary information to Bob.
4. Bob now can take out his Litecoin.

Atomic swaps are exciting because they facilitate an exchange of tokens across different blockchains without requiring a centralized exchange or a token bridge as an intermediary. They empower users to exchange tokens on a peer-to-peer basis with anyone anywhere in the world, without having to worry about losing any funds to a dishonest party.

HTLCs on Minima

Minima is a Proof-of-Work blockchain, using the same UTXO (Unspent transaction output) model as Bitcoin does. That means instead of tying balances to accounts, what users actually hold is a transaction output. If Alice has a 10 BTC balance, that means she has Unspent Transaction Outputs worth 10 BTC.

Minima supports the creation of Hashed-Time-Locked contracts. Suppose 0xFF was the public address of Alice, and she wanted to send Minima Coins to Bob, whose address is 0xEE. With the following contract, she could establish that Bob would only be able to reclaim the coins if he had the pre-image, and managed to claim before 1000 blocks.

IF @BLOCK GT 1000 AND SIGNEDBY(0xFF) THEN

RETURN TRUE

ENDIF

RETURN ( SIGNEDBY(0xEE) AND KECCAK(STATE(1)) EQ 0x546FCD56E.. )

Minima employs the quantum secure SHA3 hash function, Keccak, as standard, but the scripting language supports SHA2–256 to allow for cross-chain hash lock contracts with legacy chains.

Users on the other chain, for the sake of the example, let’s say Bitcoin, would then just re-create the same contract on Bitcoin. After sending their Bitcoin to the contract, they could then collect their coins on Minima after showing the pre-image.

Once our Mainnet goes live in Q2 2022, we’re expecting to see user-friendly dApps that will help anyone anywhere in the world to swap their favorite tokens using atomic swaps to and from the Minima ecosystem.

If you have an idea for a dApp using atomic swaps or would like to discuss the technology with us, join the community Discord. We’re looking forward to your thoughts.

‍