hash160 → P2PKH / P2SH / P2WPKH addresses

What this page computes

You give it one value — a 20-byte hash160 — and it shows you every address that can be built from it, plus the raw bytes each address commits to. The hash itself is one line of arithmetic:

This page starts at the third box: the hashing is already done, and everything below is pure wrapping. That is the useful part to understand, because the same 20 bytes become a 1…, a 3…, a bc1q… or a tb1q… address depending only on which bytes are glued in front of them.

1. What a cryptographic hash function is

A hash function takes an input of any length and returns a fixed-length fingerprint. Cryptographers require three separate properties from it, and each one is doing different work inside a Bitcoin address.

The first property is the one people misread. The address is the hash, so there is nothing to "derive the address from" — see section 4. What preimage resistance really buys you is that the set of public keys mapping to a given address is effectively unreachable: to spend a P2PKH output you must reveal a public key with that exact hash160 and sign with its private key, and the attacker may choose both. If a preimage were findable in 2⁴⁰ steps instead of 2¹⁶⁰, an attacker would simply generate a fresh keypair whose public key hashes to your address and empty it. Preimage resistance is the property that makes a published address safe to leave unspent forever.

2. Why RIPEMD160(SHA256(x)) and not a single hash

Both halves are deliberate, and they are answering two different questions.

Read it as an assembly line. SHA-256 is a modern, well-studied 256-bit function; running it first makes the value that enters the second stage a uniformly random 32-byte string, so RIPEMD-160 never sees structured input from an attacker. RIPEMD-160 then shrinks the commitment to 20 bytes, and that saving is real money:

Twelve bytes multiplied by every unspent output in the chain, forever, is a strong argument. The second argument is defence in depth: a break of one function does not immediately break the construction. To forge a collision in RIPEMD160(SHA256(x)) an attacker must produce two inputs whose SHA-256 digests collide, that is to say they must break SHA-256 as well, or attack RIPEMD-160 through an interface where they control only 32-byte inputs.

3. The birthday bound, and why 160 bits is enough

Preimage attacks need work proportional to the output space, 2¹⁶⁰. Collisions are cheaper because of the birthday paradox: in a room of 23 people two share a birthday, and for hashes the expected search is about

2⁸⁰ is the honest weak point of hash160, and it is considered acceptable for three reasons: a collision only pays off if the attacker can then persuade someone to use one of the two colliding keys; the attacker must also match SHA-256, because the second stage takes only 32-byte inputs; and RIPEMD-160's 160-bit width was a standardised, internationally vetted choice (it was selected by the EU's RIPE project) rather than a first attempt. If you are generating addresses for somebody else and they never verify that you do not know the key, collision resistance is the property that is supposed to protect them — and it is the one with the smallest margin.

4. The address is not a secret — what actually protects your coins

Look at a real address's insides: 146ZNjH7…2UqT is nothing but Base58Check(0x00 ‖ hash160). The hash is in the address, published on every invoice, in every QR code, on every block explorer. Nobody is trying to hide it, and "you cannot reverse the hash to find my address" is not a security argument — the address was given away on purpose.

What protects the coins is a combination of three things:

• The private key. Spending requires a valid ECDSA signature over the transaction. Nothing in the address lets you produce one.
• Preimage resistance of hash160. An alternative public key that hashes to your address must be infeasible to find (≈ 2¹⁶⁰), because such a key could be spent with a signature the attacker makes themselves.
• The public key is not on-chain until you spend. In P2PKH the chain stores only the 20-byte hash while the output is unspent. The full point appears in the scriptSig of the transaction that spends it.

That last row is why hashing still matters in a post-quantum discussion. Shor's algorithm solves the elliptic-curve discrete logarithm, so it can recover a private key from a public key that is visible on-chain. For an unspent P2PKH output there is no point visible — only a hash — so a quantum attacker must attack the hash instead, where Grover's algorithm gives only a quadratic speed-up (2¹⁶⁰ → roughly 2⁸⁰ quantum steps). Taproot chose the opposite trade-off: its output key is a curve point sitting on-chain, which is what makes it cheap to verify and private to cooperate on, and also what makes it the first thing a quantum adversary could take.

5. Byte-level layout of everything this page prints

Note the double hashing in the P2SH-P2WPKH row. A nested SegWit address does not commit to your public-key hash directly; it commits to hash160 of the 22-byte redeemScript 0x0014 ‖ hash160, which is why its payload is a different 20 bytes from every other row.

6. Worked example with the sample hash160

These are the values this page actually prints for 21f57b6d…89012, computed here and not copied from anywhere:

Six different addresses, one hash, zero cryptography beyond the two hash calls that produced it. If you change a single input byte anywhere upstream, every row in that table changes.

7. A Taproot address cannot be built from a hash160

This is the one thing on the page that is not possible, and the reason is structural, not a limitation of this tool. A P2TR output commits to a 32-byte x-only output key, computed as

Producing that requires the full curve point: the tweak is taggedHash("TapTweak", x(P)), the addition needs a real point with a known y, and the result must be a point whose private key the owner can actually use. A hash160 is 20 bytes of digest; it is not a point, it has no y, and — crucially — nobody knows the discrete log of the point you would get by treating it as an x coordinate, even though the curve equation may well have a solution for it.

8. Where this value comes from and what comes next

• Upstream: compressed public key → hash160 → addresses shows the hashing step itself, and private key HEX → all formats starts from the very beginning.
• Downstream, Base58Check: Base58Check encoder / decoder takes the payloads printed above and shows the version byte, checksum and internal structure.
• Downstream, bech32: Bech32 / Bech32m decoder does the same for the bc1q… form, including the witness program and checksum.
• Addresses from the same key: P2PKH, P2SH-P2WPKH, P2WPKH.

9. Security notes and common mistakes

• An address is not a secret. A hash160 is public by construction; treat every published address as known to everybody forever.
• Hashing the wrong serialization. The compressed key (02…/03…) and the uncompressed key (04…) hash to different values, so one private key owns two P2PKH addresses. The demonstration values are 21f57b6d…9012 (compressed → 146ZNjH7…) and 3f0e966d…23f9 (uncompressed → 16kR3eis…).
• Assuming the checksum validates meaning. A Base58Check checksum proves the string was not mistyped; it says nothing about whether the version byte matches the network you are on.
• Believing 20 bytes is "weak". 160 bits of preimage resistance is beyond any classical attack; the weakest link is the 80-bit collision bound, and exploiting it requires more than brute force.
• Sending to the wrong address type. The four Base58/bech32 forms above are four different scriptPubKeys. Funds sent to one cannot be spent by a wallet that only knows another.

10. Quick reference