Understanding Time-Lock and Hashed Time-Lock

So, you’ve heard about time-locks in Bitcoin, right? These tools, known as time-locks, play a key role in maintaining security and legitimacy. Relinx will also utilize this technique, and it plays a very important role in Relinx too. In this blog post, we’ll delve into what time-locks entail, with a particular focus on CheckLockTimeVerify (CLTV) and CheckSequenceVerify (CSV). We’ll also discuss Hashed Time-Lock Contracts (HTLC) and how they differ from standard time-locks. Get ready, this is going to be an interesting journey!

CheckLockTimeVerify (CLTV) and CheckSequenceVerify (CSV)

CLTV and CSV are Bitcoin script operators that provide a time-lock feature to transactions. CLTV, which stands for OP_CHECKLOCKTIMEVERIFY, invalidates a transaction if the top stack item is greater than the transaction's nLockTime field. If not, the script evaluation continues as if an OP_NOP was executed. Simply put, CLTV allows a transaction to specify the earliest time or block number at which it can be added to the blockchain. This essentially locks the funds until a specified time or block height is reached.

Conversely, CSV stands for OP_CHECKSEQUENCEVERIFY. This marks a transaction as invalid if the relative lock time of the input is not equal to or longer than the value of the top stack item. In simple terms, it enables relative time-locking, making a transaction output unspendable for a specific period after its inclusion in the blockchain. This feature is especially beneficial for creating payment channels that need to close after a certain time frame.

These are very useful. Consider a scenario where Alice wants to send Bitcoin to Bob, but she wants to add the condition that Bob can only access the funds after a certain date, say a year from now. Alice can use CLTV to specify this condition when she creates the transaction. The transaction will be added to the blockchain immediately, but Bob will only be able to spend the output after the specified time has passed. The whole script is as follows:

<Next Year Timestamp>
OP_CHECKLOCKTIMEVERIFY
OP_DROP
OP_DUP
OP_HASH160
<Bob's Pubkey Hash>
OP_EQUALVERIFY
OP_CHECKSIG

Let’s examine a more complex scenario. Suppose Alice commits some funds that Bob can claim. If Bob doesn’t claim the funds within this period, Alice wants the transaction to reverse, returning the funds to her. To achieve this, Alice can use CSV and specify the time as a parameter in the transaction script. This makes the transaction output unspendable for Alice for a week, providing Bob with a chance to claim the funds. If Bob doesn’t claim the funds in that window, Alice can spend the transaction output, effectively retrieving her funds. This is especially used in HTLC. The script is as follows:

OP_IF
	<A Week>
	OP_CHECKSEQUENCEVERIFY
	OP_DROP
	OP_DUP
	OP_HASH160
	<Alice's Pubkey Hash>
OP_ELSE
	OP_DUP
	OP_HASH160
	<Bob's Pubkey Hash>
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG

Hashed Time-Lock Contracts (HTLC)

Hashed Time-Lock Contracts (HTLC) are a specific variety of time-lock contracts that utilize cryptographic hash functions and time-locks to guarantee that all parties involved fulfill their obligations. HTLCs play a crucial role in the operation of payment channels and Lightning Networks, as they ensure all parties complete their part of the deal within a certain period, failing which the transaction is voided. By adding an additional layer of security to Bitcoin transactions, they represent a significant innovation in the field.

Here’s an example of an HTLC script from https://voltage.cloud/blog/lightning-network-faq/how-do-htlc-work-lightning-network/

# Revocation
OP_DUP OP_HASH160 <RIPEMD160(SHA256(Revocation Public Key))> OP_EQUAL
OP_IF
  OP_CHECKSIG
OP_ELSE
  <Remote HTLC Public Key> OP_SWAP OP_SIZE 32 OP_EQUAL
  OP_IF
    # Redemption
    OP_HASH160 <RIPEMD160(Secret)> OP_EQUALVERIFY
    2 OP_SWAP <Local HTLC Public Key> 2 OP_CHECKMULTISIG
  OP_ELSE
    # Refund
    OP_DROP <Payment Expiry Block> OP_CHECKLOCKTIMEVERIFY OP_DROP
    OP_CHECKSIG
  OP_ENDIF
OP_ENDIF

In this scenario, the Time-lock serves as a refund mechanism if the Hashed Time-Lock Contract (HTLC) setup is unsuccessful. Both Check Lock Time Verify (CLTV) and Check Sequence Verify (CSV) can be used in this context. Within an HTLC, a hash of a secret functions as part of the contract. To claim the funds, the recipient must reveal the secret that corresponds to the specified hash within the time-lock period. If they fail to do so, the sender can reclaim the funds after the time-lock expires. This principle is fundamental to the functioning of Lightning Networks, which use HTLCs to enable off-chain transactions.

Now you see the differences between Time-Lock and Hashed Time-Lock?

While both time-locks and hash time-locks serve to secure Bitcoin transactions, their modes of operation are different. The standard time-lock (CLTV and CSV) is focused on the timing of the transaction, either specifying a future time or block number for the transaction to be added to the blockchain or a certain time period after which the transaction output becomes spendable. However, the hash time-lock in HTLC adds a condition to the time-lock. It requires the recipient to provide the correct hash value within the time-lock period to access the funds, adding another level of security and complexity to the transaction.

Can you now identify the differences between the two concepts? When we say ‘time-lock’, we’re referring to a mechanism that restricts the spending of funds until a specific time or block has been reached. This guarantees that the money stays untouched until that predetermined time has arrived. On the other hand, a ‘hashed time-lock’ imposes a different condition. It requires a certain action to be taken within a specified time frame. If this is not achieved, the mechanism triggers a refund. In summary, the time-lock in HTLC is a specific application of Time-Lock.