OP_HASH160

One byte, 0xa9, standing in for two of the most studied hash functions in cryptography. The pairing shrinks a 32 byte output down to 20 and hedges against a weakness in either algorithm, at the cost of roughly 80 bits of collision resistance instead of 128. It is the reason a bitcoin address is short enough to read aloud over a phone.

How it works

OP_HASH160 pops one item of any length and pushes exactly 20 bytes, and the same input always produces the same digest.

The two functions come from unrelated design lineages. RIPEMD-160 was published in 1996 by a European academic team working in the open; SHA-256 came out of the NSA and was standardized by NIST in 2001. Chaining them was a conservative choice. A structural break in one would still leave the other standing between an attacker and a useful forgery, and in three decades neither has been broken in a way that threatens this construction.

The size cut is not cosmetic. Twelve bytes saved on every output mattered when the goal was to keep a permanent global ledger small, and it is why the classic locking script is 25 bytes rather than 37.

Twenty bytes does have a ceiling. Finding two inputs that share a 160 bit digest takes on the order of 2 to the 80th operations rather than 2 to the 128th, which is comfortable when only you choose the key being hashed and much less comfortable when a counterparty helps choose the script being committed to. That reasoning is exactly why segregated witness moved script commitments to a single 32 byte SHA-256 in P2WSH while keeping the shorter form for single key outputs.

Where you see it

OP_HASH160 lives in two script templates, and its output lives inside nearly every address you have ever copied.

Legacy outputs run it on a public key. Pay-to-script-hash outputs run it on a redeem script. In both cases the address you see is that 20 byte digest with a version byte in front, 0x00 for the addresses starting with 1 and 0x05 for those starting with 3, wrapped in a Base58Check checksum. Native segwit single key outputs carry the identical 20 bytes with no opcode present at all, because the rules for that output type are built into the validator rather than written as script.

Taproot broke the habit. A bc1p output commits to a 32 byte public key with no hashing step in between, so a Taproot address contains no hash160 anywhere.

This is also the practical reason that checking an address on a hardware wallet screen works. Two addresses differing anywhere at all produce two unrelated digests, so a substituted address cannot look almost right; comparing the first and last handful of characters on the device against what your computer shows is enough to catch clipboard malware.

OP_HASH160 vs SHA-256

SHA-256 is a hash function; OP_HASH160 is an instruction that happens to call it once. The function turns up all over bitcoin with no script involved: proof of work hashes a block header with it twice, transaction identifiers are a double application of it, and merkle trees are built out of it. The opcode exists only inside Bitcoin Script, runs only while an output is being spent, and always yields 20 bytes rather than 32. The composition it performs, RIPEMD-160 of SHA-256, is common enough to have its own name in wallet code, hash160, which is worth recognizing when you read through a library's function list.