Hash Lock

What Is a Hash Lock?

A hash lock is a cryptographic spending condition placed on funds that can only be satisfied by providing a value (called the preimage) that, when passed through a hash function, produces a specific expected output. Think of it like a lock that opens only when you present a secret key, but instead of a physical key, the "key" is a piece of data whose fingerprint (hash) matches the one stamped on the lock.

Hash locks are foundational to trustless, multi-party payment protocols. They were originally described in the context of cross-chain atomic swaps, where two parties on different blockchains need a mechanism to ensure that either both sides of a trade complete or neither does. The technique was later generalized into Hashed Time-Locked Contracts (HTLCs), which pair a hash lock with a time lock, and became the backbone of the Lightning Network's multi-hop payment routing.

How It Works

A hash lock works by exploiting a core property of cryptographic hash functions: they are easy to compute in one direction but practically impossible to reverse. Given a preimage x, anyone can compute H(x) instantly, but given only H(x), no one can recover x without already knowing it.

1. The receiver generates a random secret (the preimage), typically a 32-byte value
2. The receiver computes the hash of this secret using a function like SHA-256, producing the payment hash
3. The sender creates a transaction whose output is locked to this hash: "these funds can be spent by whoever reveals a value that hashes to H(x)"
4. To claim the funds, the receiver publishes the preimage. The network verifies that hashing the revealed value produces the expected hash.

In Bitcoin Script

On the Bitcoin base layer, a hash lock is expressed using Script opcodes. The simplest form uses OP_SHA256 (a single SHA-256 hash) or OP_HASH256 (double SHA-256):

# Locking script (scriptPubKey)
OP_SHA256 <expected_hash> OP_EQUAL

# Unlocking script (scriptSig)
<preimage>

When the unlocking script executes, the stack processor hashes the provided preimage and compares the result against the expected hash. If they match, the condition is satisfied. In practice, hash locks are always combined with a signature check (OP_CHECKSIG) so that only the intended recipient can claim the funds, not just anyone who observes the preimage on the blockchain.

In Multi-Hop Lightning Payments

Hash locks truly shine in multi-hop payments across the Lightning Network. When Alice wants to pay Carol through an intermediary (Bob), the same payment hash links every hop:

1. Carol generates preimage x and sends H(x) to Alice via a Lightning invoice
2. Alice creates an HTLC with Bob: "I will pay you 1,001 sats if you reveal the preimage for H(x) within 80 blocks"
3. Bob creates an HTLC with Carol: "I will pay you 1,000 sats if you reveal the preimage for H(x) within 40 blocks"
4. Carol knows x, so she reveals it to Bob and claims her 1,000 sats
5. Bob now knows x, so he reveals it to Alice and claims his 1,001 sats (keeping 1 sat as a routing fee)

The hash lock guarantees atomicity: Carol can only claim her payment by revealing the preimage, and revealing it automatically gives Bob the ability to claim his incoming HTLC. Either the entire chain settles or none of it does.

Hash Locks vs. Point Locks

Hash locks have a significant privacy limitation: the same hash value H(x) appears at every hop in a multi-hop payment. Any two colluding intermediaries (or a single entity operating multiple routing nodes) can observe the same hash and conclude they are part of the same payment. This undermines the privacy benefits of onion routing, which hides the sender and receiver from intermediaries.

Point Time-Locked Contracts (PTLCs) solve this by replacing hash-and-preimage pairs with elliptic-curve points and scalars. In a PTLC, each hop uses a different locking point, so no two hops share a correlatable value. The underlying mathematics of Schnorr signatures and adaptor signatures enable this: each intermediary adds a random "tweak" to the point, decorrelating the payment across hops while preserving atomicity.

For a deeper analysis, see PTLCs: the next evolution of Lightning.

Use Cases

Multi-Hop Payment Routing

The most widespread use of hash locks is in Lightning Network HTLCs. Every routed Lightning payment relies on a hash lock to ensure that intermediaries can only collect their routing fees if the final recipient actually receives the payment. This mechanism makes it safe to route payments through untrusted nodes without any risk of theft.

Cross-Chain Atomic Swaps

Hash locks were originally developed for atomic swaps between different blockchains. Both chains use the same hash to lock funds: the party who reveals the preimage on one chain simultaneously enables the counterparty to claim funds on the other chain. This ensures that either both legs of the swap complete or neither does, without requiring any trusted intermediary.

Submarine Swaps

Submarine swaps bridge on-chain Bitcoin and Lightning using hash locks. A service creates an on-chain HTLC locked to the same hash as a Lightning payment. When the Lightning payment settles and reveals the preimage, it can be used to claim the on-chain funds. This is how services like Loop enable channel liquidity management.

Conditional Escrow

Hodl invoices use hash locks to create conditional payment flows. The receiver withholds the preimage until business conditions are met (goods delivered, service confirmed, oracle verified), then reveals it to settle the payment. This enables trustless escrow patterns without third-party custodians.

Why It Matters

Hash locks are the cryptographic primitive that makes trustless, multi-party payment networks possible. Without them, every intermediary in a payment route would need to be trusted not to steal funds. The hash lock ensures that intermediaries can only profit by honestly forwarding payments: they learn the preimage only when the next hop settles, and they can claim their incoming payment only by using that same preimage.

For protocols built on Bitcoin's Layer 2 ecosystem, including Spark, understanding hash locks is essential because they underpin the security model of payment channels and routed payments. As the ecosystem evolves toward PTLCs, the core principle remains the same: cryptographic proof of knowledge replaces trust in counterparties.

Risks and Considerations

Payment Correlation

The most significant drawback of hash locks is the privacy leakage described above. Because every hop in a multi-hop payment uses the identical hash, any two colluding routing nodes can determine they are forwarding the same payment. For privacy-sensitive users, this is a material concern. The Lightning Network privacy analysis covers this issue in detail.

Preimage Exposure

Once a preimage is revealed to claim a hash-locked payment, it becomes known to every intermediary along the route. In a standard Lightning payment, this is by design: the preimage propagates backward, settling each hop. However, in more complex protocols that reuse the same hash across multiple contracts, preimage exposure in one context could unintentionally unlock funds in another. Protocols must ensure each hash lock uses a unique, purpose-specific hash.

On-Chain Footprint

When an HTLC must be settled on-chain (for example, during a force close), the hash lock adds data to the transaction. The preimage reveal, the hash, and the conditional branching script all consume block space. Taproot mitigates this for the cooperative case (where the hash lock resolves off-chain), but the uncooperative path still carries the full script weight.

Wormhole Attack

In a multi-hop payment, two colluding intermediaries who are not adjacent can exploit the shared hash to short-circuit the route. If node A and node C collude and both see the same hash, node C can forward the preimage directly to node A, allowing them to settle their incoming HTLCs while skipping the honest nodes between them. The skipped nodes forwarded liquidity but never receive their routing fees.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.