HASH160

HASH160 is the two-step hashing operation Bitcoin uses to turn a public key (or a script) into a short, fixed-length fingerprint. It is defined as RIPEMD160(SHA256(data)): first the input is hashed with the 256-bit SHA-256, then that digest is compressed with RIPEMD-160 into a 20-byte, 160-bit result — which is where the name comes from. Nearly every pre-Taproot Bitcoin address you have ever seen is, underneath its encoding, a HASH160 of something.

Why two different hash functions

The composition earns its place twice over. First, compactness: a compressed public key is 33 bytes, but its HASH160 is only 20, and in a system where every byte of every output lives in the UTXO set forever, that reduction matters at scale. Second, defense in depth: chaining two structurally different hash functions means an attacker must defeat properties of both to forge a preimage, hedging against an unforeseen cryptanalytic break in either algorithm alone. Satoshi's choice has aged well — RIPEMD-160 remains unbroken for this use, and SHA-256 anchors everything else in Bitcoin, from txids to the Merkle root to the proof-of-work your miners grind against.

Where it appears on-chain

In a Pay-to-Public-Key-Hash (P2PKH) locking script, the spender's public key is duplicated, passed through OP_HASH160, compared against the stored 20-byte hash with OP_EQUALVERIFY, and only then does OP_CHECKSIG validate the signature. A legacy address beginning with "1" is simply that hash wrapped in a version byte and checksum, Base58Check-encoded. P2SH addresses (beginning with "3") apply the same operation to an entire redeem script rather than a key, and SegWit v0 carried the pattern forward: a P2WPKH output commits to the HASH160 of a public key inside its 20-byte witness program, behind a bech32 address beginning "bc1q". The transitional P2SH-wrapped SegWit format stacked the operation twice — a "3" address whose redeem script is itself a witness program — which is why wallets from that era could adopt SegWit without waiting for the whole ecosystem to learn new address formats. Recognizing which of these a raw script represents is a genuinely useful bench skill when auditing transactions or recovering funds from an old wallet dump.

The security angle — and the Taproot departure

Hashing the key means the full public key stays off-chain until the coins are spent, a modest extra shield should the underlying elliptic-curve scheme ever weaken: an attacker facing an unspent P2PKH output sees only a hash, not a curve point to attack. The 160-bit length also sets the security arithmetic — roughly 2¹⁶⁰ work to find a preimage, and about 2⁸⁰ for a collision, which is why collision-sensitive multi-party constructions on P2SH warranted care. Taproot (P2TR) broke with this tradition deliberately: a "bc1p" output exposes a tweaked public key directly, with no HASH160 at all, trading the hash shield for key aggregation, script trees, and signatures that verify more efficiently. Understanding that contrast is a compact lesson in how Bitcoin's script generations evolved — see Taproot for the modern design.

Why it is worth knowing cold

For anyone who runs a node, audits a wallet, or reads raw transactions on the bench, HASH160 is foundational vocabulary: it is the link between the keys derived along a BIP44 derivation path and the address strings the world actually sees. Verify it yourself once — take a public key, run SHA-256 then RIPEMD-160, encode the result, and watch your own wallet's address appear — and the "magic" of addresses dissolves into plain arithmetic you can check any time, on hardware you own, with no one's permission. That is the whole Bitcoin ethos in miniature: don't trust the encoding, verify the hash.