How is a Bitcoin address generated from a public key

05 September 2026

The path from a public key to a Bitcoin address is a fixed sequence of cryptographic steps. Different address formats exist, but the core hashing process is identical. Only the version byte and final encoding change.

The hashing pipeline

Every Bitcoin address starts with a public key. That key is first hashed with SHA-256, then the 256-bit result is hashed again with RIPEMD-160. This two-step hash is called HASH160. It produces a 20-byte hash.

SHA-256 then RIPEMD-160. Two different hash functions in sequence. This prevents security failures if one algorithm is ever broken, and the output is always 160 bits.

Adding the version byte

A version byte is prepended to the 20-byte hash. This byte tells wallets and software what type of address follows. The version byte is the first major difference between address formats.

For a Legacy address (P2PKH), the version byte is 0x00. For a Testnet address, it is 0x6F. For SegWit, the version byte is handled differently - but the hash160 step remains.

The checksum

Errors happen. Typing a wrong character, copying a truncated string. To catch this, Bitcoin adds a checksum.

Take the version byte plus the 20-byte hash and run that 21-byte string through SHA-256, then SHA-256 again. Take the first four bytes of the second hash. Those four bytes are the checksum. Append the checksum to the version-plus-hash string. The result is a 25-byte sequence. This is what gets encoded.

Base58Check encoding

Base58 is like Base64 but with confusing characters removed: 0, O, I, l, and some symbols. It avoids visual ambiguity. Base58Check means the full 25-byte payload (version, hash, checksum) is encoded.

This produces a string that starts with a recognisable character. For mainnet Legacy addresses, it starts with a 1. For Pay-to-Script-Hash addresses, it starts with a 3. The checksum check happens on decode. If you mistype a character, the checksum re-derived from the hash will not match, and the wallet will reject the address.

Bech32 (SegWit)

SegWit addresses - commonly called Bech32 - replace Base58Check. They still use SHA-256 and RIPEMD-160 for the same hash160 of the public key. But the version byte becomes a witness version (typically 0), and the encoding changes entirely.

Bech32 uses a different checksum (BCH code) and a smaller character set. It is more efficient to encode and decode in software. It also supports optional error correction, though this is rarely used. Bech32 addresses start with bc1 - the human-readable part “bc” followed by a separator.

Taproot (Bech32m)

Taproot addresses, introduced in 2021, use Bech32m. The hashing chain is the same. The version byte is set to 1 for the witness version. The encoding is a tweaked version of Bech32 called Bech32m. It fixes a vulnerability with length extension in the original Bech32.

The hash160 is still a SHA-256 then RIPEMD-160 of the public key. But for Taproot, the public key is usually a tweaked key that can represent multiple spending conditions. The hashing pipeline does not change.

What differs between formats

The core concept is fixed: HASH160 of a public key, with a version prefix, a double-SHA-256 checksum, and an encoding step.

Legacy (P2PKH): version byte 0x00, Base58Check.

SegWit (P2WPKH): witness version 0, Bech32.

Taproot (P2TR): witness version 1, Bech32m.

The hashing inside - SHA-256 then RIPEMD-160 - never varies. The public key has not been replaced. The address is always derived from it.

A note on this site

This page is hosted at babybitcoin.space. As of 31 August 2026, on-chain data shows a token called babybitcoin exists on Base chain as a Uniswap pair. It launched 30 July 2025. Its liquidity is thin at $1,100. Daily volume is $2.24. The site is not affiliated with Bitcoin core development or any financial product.

Different addresses. Same hash. Same public key. Just different envelopes.

Back to bitcoin