Hashed Time-Locked Contracts (HTLCs): Advanced Operations
Behind The Scenes: How HTLCs Enable Lightning
HTLCs are the cornerstone technology that makes the Lightning Network possible. They create conditional payment channels where funds are locked until specific cryptographic conditions are met, or a timeout occurs.
At its core, an HTLC is a sophisticated combination of two distinct types of Bitcoin script conditions:
Hash Lock
Funds are cryptographically locked with a hash of a secret (preimage). The recipient must reveal the correct preimage value that produces the hash to claim the payment.
OP_HASH256 <hash> OP_EQUALVERIFY
Time Lock
The payment channel contract includes a timelock that allows the sender to reclaim their funds after a specified time period if the hash lock isn't satisfied.
OP_CHECKLOCKTIMEVERIFY <timeout> OP_DROP
The HTLC Script in Detail
Let's examine the actual Bitcoin script conditions that comprise a standard HTLC:
IF OP_HASH256 <hash_of_secret> OP_EQUALVERIFY <recipient_pubkey> OP_CHECKSIG ELSE <timeout_blocks> OP_CHECKLOCKTIMEVERIFY OP_DROP <sender_pubkey> OP_CHECKSIG ENDIF
Success Path
If the recipient knows the preimage of the hash, they can use the first execution path to claim the funds immediately by providing the secret and their signature.
Timeout Path
If the timeout period has elapsed and the hash lock hasn't been satisfied, the sender can reclaim their funds using the second execution path with just their signature.
Multi-Hop HTLC Propagation
The true power of HTLCs becomes apparent in multi-hop Lightning payments. Here's how HTLCs chain together across multiple payment channels:
Payment Initiation
The sender generates a random secret (preimage) and calculates its hash. The payment amount and hash are sent along the route to the recipient, but the secret is kept private.
HTLC Chain Formation
Each node along the route creates an HTLC with the next node, committing funds conditionally based on the same hash but with decreasing timelocks to ensure proper flow of the secret.
Secret Revelation
Once the recipient receives the HTLC, the sender reveals the preimage to them through a secure channel. The recipient uses this secret to claim the funds from the final node.
Reverse Secret Propagation
The secret now propagates backward through the chain. Each node reveals the secret to claim funds from the previous node, creating a cascade of settled payments.
Advanced HTLC Considerations
Timelocks Management
Correctly decreasing timelock values is critical. Each hop must have enough time to claim funds if the next hop reveals the secret, but also enough time for the previous hop to claim a refund if something fails.
Fee Considerations
HTLCs require calculating fees correctly across multiple hops. Each intermediary node must reduce the amount they forward to account for their fee while maintaining proper routing information.
HTLC Jamming Attacks
Attackers can lock up channel liquidity by creating many small HTLCs and not revealing the preimage. Timeout values must balance payment reliability with attack vulnerability.
Advanced HTLC Implementations
PTLCs (Point Time-Locked Contracts)
The next evolution of HTLCs that uses Schnorr signatures and point-based cryptography instead of hash functions, offering improved privacy by making all hops in a route look indistinguishable on-chain.
Atomic Multipath Payments (AMPs)
Extending HTLCs to split payments across multiple routes using multiple preimages that all hash to the same value, enabling larger payments to be made through channels with limited individual capacity.