Skip to main content

Glossary Cryptography and payment

HTLC

Also: Hash Time-Locked Contract, hash time-locked contract

Origin: The construction was specified by Joseph Poon and Thaddeus Dryja in 'The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments' (2016); precursor ideas date to 2013-2015 Bitcoin developer discussion.

A cryptographic payment construction in which a payment is conditional on the receiver disclosing a pre-image of a known hash within a defined time window; if disclosure does not occur the payment is reclaimable by the sender. The foundational primitive on which the Bitcoin Lightning Network's multi-hop payment routing is built.

A Hash Time-Locked Contract is a cryptographic payment construction in which a payment is conditional on the receiver disclosing a pre-image of a known hash within a defined time window; if disclosure does not occur the payment is reclaimable by the sender. The receiver can claim the payment by revealing the pre-image (and signing as themselves); the sender can reclaim the payment after the time window expires (and signing as themselves) if the receiver has not claimed it. The two outcomes are mutually exclusive.

The construction is the foundational primitive on which the Bitcoin Lightning Network’s multi-hop payment routing is built. In a Lightning multi-hop payment, the sender selects a route through a chain of payment channels — channel A, channel B, channel C, etc. — and asks each intermediate node to forward the payment to the next under an HTLC: the intermediate node locks up funds in favour of the next hop, conditional on the next hop disclosing the pre-image. The receiver, who generated the pre-image originally, discloses it on the final hop; the disclosure propagates backwards through the channel chain, each intermediate node claiming its HTLC by re-using the now-public pre-image.

The privacy property the HTLC procures is in the routing layer. The intermediate nodes do not learn the identities of the sender and the receiver; they learn only the immediately-adjacent channels and the amount being forwarded (minus their fee). The construction is paired with onion-routed payment messages — the Sphinx packet — so that an intermediate node learns the next hop in the route but not the full route. The aggregate privacy is asymmetric: stronger than on-chain Bitcoin, weaker than Monero’s default-private transaction surface.

HTLCs also underpin atomic swaps between chains — Bitcoin and Litecoin, Bitcoin and Monero through the COMIT framework — where the cross-chain transaction uses the same hash-lock primitive to ensure that both legs of the swap complete or both fail.

For an offshore-hosting operator that accepts Lightning, the HTLC mechanism is what makes the payment route privacy-positive on the routing layer (compared with conventional on-chain Bitcoin) and what makes sub-second settlement possible (compared with the multi-confirmation wait on-chain Bitcoin requires). The publication describes the operational picture in the Lightning payment dossier.