OP_HASH160

OP_HASH160 (opcode 0xa9) consumes the top item on the stack, computes RIPEMD160(SHA256(x)) of that item, and pushes the resulting 20-byte digest back onto the stack. This double-hash construction, often written HASH160, is the reason classic Bitcoin addresses are 160 bits wide: SHA-256 provides the heavy cryptographic lifting while RIPEMD-160 compresses the output to a shorter, more compact commitment. Every legacy P2PKH payment and every P2SH contract ever spent has run this opcode on the way to validation.

Why two hash functions instead of one

Nesting RIPEMD-160 over SHA-256 serves two purposes. First, it hedges: a structural weakness discovered in either primitive alone does not immediately break the composition, since an attacker must defeat both layers. Second, it saves space — a 20-byte hash instead of a 32-byte one shaves twelve bytes off every output that carries it, a meaningful economy in a system where every UTXO lives in memory on tens of thousands of nodes indefinitely. The 160-bit width still offers 80 bits of collision resistance and 160 bits of preimage resistance, comfortably beyond any practical attack, though it is the tightest security margin in Bitcoin's hash toolbox and one reason newer output types moved to full 32-byte commitments.

Role in the standard scripts

In the canonical Pay-to-Public-Key-Hash locking script — OP_DUP OP_HASH160 <20-byte-hash> OP_EQUALVERIFY OP_CHECKSIG — OP_HASH160 hashes the public key the spender just revealed so it can be compared against the hash committed in the address before signature verification runs. The elegance is that the blockchain never learns the public key until spend time; until then only its fingerprint exists on-chain. In Pay-to-Script-Hash the same opcode hashes the revealed redeem script, letting arbitrarily complex spending conditions hide behind a fixed-size commitment — the conceptual ancestor of Taproot's script commitments. SegWit v0 kept the identical 160-bit digest for its P2WPKH witness programs, merely relocating the data into the witness, while P2WSH and Taproot moved to 32-byte SHA-256-based commitments.

Reading it in the wild

For anyone learning to dissect raw transactions, OP_HASH160 is a landmark: seeing a9 14 in a scriptPubKey (the opcode followed by a 20-byte push) instantly identifies a P2SH output, while 76 a9 14 marks P2PKH. Block explorers and wallet debug tools lean on these byte patterns to classify outputs, and a repair-minded node operator who can spot them can audit what kind of coins a wallet actually holds without trusting any third-party interpretation — the same verify-it-yourself discipline that applies to hardware applies to script bytes.

Related opcodes and modern context

The construction also shaped Bitcoin's address encodings. A Base58Check legacy address is essentially a HASH160 digest wrapped with a version byte and checksum, and a P2SH address is the same wrapper around a script's HASH160. When a wallet displays an address beginning with 1 or 3, it is showing you a human-readable envelope around exactly the 20 bytes this opcode produces — which is why address and script validation can be done offline, with no chain access at all.

OP_HASH160 sits in a family: OP_SHA256 and OP_HASH256 produce 32-byte digests, and OP_RIPEMD160 applies the shorter function alone. In Bitcoin Script's hash-lock idiom — pay to whoever can reveal a preimage — HASH160 was the traditional choice, and it still appears in cross-chain atomic swap contracts and Lightning-adjacent constructions built before the ecosystem standardized on plain SHA-256 hashlocks. The opcode remains fully valid in Tapscript, so new contracts can still use it where a compact 20-byte commitment earns its keep. It is best understood next to the signature check it typically precedes, OP_CHECKSIG: one opcode proves you hold the committed key, the other proves you can sign with it — together they are the two-step handshake at the heart of the oldest and still most common way to own bitcoin.