Timechain Wiki

Bitcoin addresses

11 min read

A Bitcoin address is the human-shareable encoding of a payment destination — derived from a public key (and, in some types, from a script) via a chain of hashing and encoding steps. Bitcoin's address system has evolved through five major types since 2009 — P2PKH (legacy 1...), P2SH (3...), P2WPKH and P2WSH (native SegWit v0, bc1q...), and P2TR (Taproot, bc1p...) — each enabling new protocol capabilities while preserving backward compatibility, and all coexisting in 2026. Three text encodings are in use across the types: Base58Check (legacy), Bech32 (SegWit v0), and Bech32m (Taproot v1). Address type determines fee cost per spend, which signature scheme is required, and what privacy properties the on-chain footprint exhibits. This note treats the structural mechanics; operational guidance on which type to use lives in Self-custody configuration ladder and Hardware wallets overview.

Why this note matters

Every Bitcoin payment flows through an address as the destination of an output. The address determines:

  • Which signature scheme is needed to spend (ECDSA for pre-Taproot types; Schnorr for P2TR — see Signature schemes in Bitcoin)
  • What fees the spend will incur (witness types are cheaper per byte)
  • What on-chain footprint is left (different types leak different information to chain analysis)
  • What spending policies are possible (P2SH and P2WSH allow scripts; P2TR allows both key-path and script-path spends)

Address types are also the most visible surface of Bitcoin’s protocol evolution. The progression from 1... (P2PKH) through 3... (P2SH and wrapped SegWit) to bc1q... (native SegWit) and bc1p... (Taproot) is a compact summary of the protocol’s upgrades since 2009.

The derivation chain

The basic derivation flow runs:

private key → public key → hash(es) → encoding → address string

For the simplest type, P2PKH:

  1. Generate a 256-bit private key
  2. Compute the secp256k1 public key (see Public key cryptography)
  3. Compute HASH160 = RIPEMD160(SHA-256(public_key)) — produces a 20-byte hash
  4. Prepend a 1-byte version (0x00 for mainnet P2PKH)
  5. Append a 4-byte checksum (first 4 bytes of double-SHA-256 of the versioned payload)
  6. Encode the result in Base58

The output is a string like 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa — Satoshi’s address from the genesis block.

The hashing layer (HASH160 = RIPEMD160 over SHA-256) shortens the 33-byte compressed public key into a 20-byte hash. This makes addresses shorter to share and adds an optional layer of forward-secrecy: before the address is spent from, only the hash is on the chain; the underlying public key is not revealed until spend time. This property is part of why some analyses suggest unspent P2PKH/P2WPKH outputs have marginally better quantum-resistance than those whose public keys have already been exposed.

Subsequent address types use the same general flow with different specifics — different hash chains, different encodings, different version bytes.

The five principal address types

P2PKH — Pay-to-Public-Key-Hash (legacy)

Prefix: 1... on mainnet. Encoding: Base58Check. Era: 2009 onward (original). Spending: ECDSA signature in scriptSig.

The original Bitcoin address format. Output script: OP_DUP OP_HASH160 <20-byte HASH160> OP_EQUALVERIFY OP_CHECKSIG. Spender provides a public key and an ECDSA signature; the script verifies the public key hashes to the expected value and that the signature is valid.

P2PKH is still spendable in 2026 but no longer the recommended format for new outputs. Substantial UTXO supply remains in this format, including most of Satoshi’s holdings.

P2SH — Pay-to-Script-Hash

Prefix: 3... on mainnet. Encoding: Base58Check. Era: 2012 onward (BIP-13, BIP-16). Spending: Reveal the script, plus whatever inputs the script requires.

P2SH was introduced in BIP-16 (2012) to enable multisig and other complex spending conditions without forcing senders to know the script details. The recipient computes a hash of their spending script; that hash becomes the address. Funds locked to a P2SH output can only be spent by:

  1. Revealing the original script (must hash to the address’s HASH160)
  2. Providing the inputs that script requires (e.g., M signatures for an M-of-N multisig)

P2SH became the dominant format for multisig configurations and any non-standard scripts. It also became the format for nested SegWit (P2SH-P2WPKH and P2SH-P2WSH) — a transitional bridge that allowed wallets to use SegWit’s lower fees while remaining compatible with services that only knew how to parse legacy 3... addresses.

P2WPKH — Native SegWit v0 (key)

Prefix: bc1q... short (42 characters) on mainnet. Encoding: Bech32. Era: 2017 onward (BIP-141, BIP-173). Spending: ECDSA signature in the witness (not in scriptSig).

The native SegWit version of P2PKH. The signature data is moved out of the transaction body and into a separate witness structure, which is what gives SegWit its weight discount (witness data counts as 1 weight unit per byte; non-witness data counts as 4). The result is roughly 30-50% lower fees for the same spend.

P2WPKH also eliminates third-party transaction malleability — the input scriptSig is empty, so attackers can no longer modify it without invalidating the signature. This is a load-bearing precondition for Lightning Network construction.

P2WSH — Native SegWit v0 (script)

Prefix: bc1q... long (62 characters) on mainnet. Encoding: Bech32. Era: 2017 onward. Spending: Reveal the witness script, plus its inputs.

The native SegWit version of P2SH. Same script-locking semantics as P2SH but with witness-segregated data and a 32-byte hash (SHA-256 of the witness script, not HASH160). The longer hash provides ~256-bit security against collision attacks, where P2SH’s 20-byte HASH160 only provides ~80 bits — a substantive upgrade for high-value multisig configurations.

P2TR — Pay-to-Taproot (SegWit v1)

Prefix: bc1p... (62 characters) on mainnet. Encoding: Bech32m. Era: 2021 onward (BIP-341, BIP-350). Spending: Schnorr signature, key-path or script-path.

Taproot outputs commit to a 32-byte x-only public key. Spending happens one of two ways:

  • Key path: A single Schnorr signature on the output’s key. This is the dominant case — most Taproot spends use the key path. Indistinguishable on-chain from single-sig (even when the underlying construction is M-of-N multisig via Schnorr key aggregation).
  • Script path: Reveal an alternative script committed to via the TapTree Merkle structure (see Merkle trees). Used when the multisig participants fail to cooperate, or for any other scripted spending policy.

P2TR is the privacy-best address type — even complex multisig setups look like single-sig spends on the chain when the key path is used. Adoption has been gradual but increasing throughout 2022-2026.

Nested SegWit (P2SH-P2WPKH / P2SH-P2WSH)

Transitional types: P2SH addresses (3...) where the underlying script commits to a SegWit witness program. Allowed wallets to obtain SegWit’s fee benefit while keeping 3... address compatibility for senders that didn’t understand Bech32.

By 2026, nested SegWit is mostly historical — Bech32 awareness is nearly universal across wallets and exchanges. New wallets default to native SegWit or Taproot directly.

Encoding formats

Three text encodings are used across the address types:

Base58Check (legacy types P2PKH, P2SH):

  • Alphabet of 58 characters omitting visually ambiguous ones (0, O, I, l)
  • 4-byte truncated double-SHA-256 checksum at the end
  • Detects single-character errors well, but not perfectly
  • Case-sensitive
  • Versioned with a leading byte that distinguishes types

Bech32 (SegWit v0 types P2WPKH, P2WSH):

  • Alphabet of 32 characters (no visually ambiguous ones; no uppercase ambiguity)
  • BCH (Bose-Chaudhuri-Hocquenghem) code checksum, mathematically optimal for ≤4-character errors
  • Lowercase by default (uppercase allowed but discouraged in mixed-case)
  • Prefixed with a human-readable part (bc for mainnet, tb for testnet)
  • Versioned with a separator and an in-string witness version

Bech32m (Taproot type P2TR):

  • Same alphabet and structure as Bech32
  • Slightly different checksum constant (corrects a bug in Bech32 where certain trailing-zero patterns produced non-detected errors)
  • Used for SegWit v1 and any future SegWit versions

The Bech32 family was designed by Pieter Wuille specifically to improve error-detection over Base58Check. The cost-benefit is asymmetric: a single typo in a Base58 address frequently produces a valid-looking but wrong address; Bech32 catches the typo with near-certainty.

Address-reuse and chain-analysis implications

A Bitcoin address can be reused — there is no protocol-level restriction against receiving multiple payments to the same address. But address reuse leaks information substantially:

  • Linkability. All payments to the same address are obviously linked to the same recipient. The recipient’s transaction history is observable on the chain.
  • Spend exposure. When the recipient spends from the address, the public key is revealed (for P2PKH and P2WPKH) — increasing the surface area for quantum-threat exposure for any further deposits to the same address.
  • Cluster heuristics. Chain-analysis firms cluster addresses likely to belong to the same wallet using heuristics including common-input ownership, change-output identification, and address-reuse patterns. Reusing an address makes clustering trivial.

The standard self-custody practice is to use a fresh address for every transaction. HD wallets (BIP-32 / BIP-44) generate effectively unlimited addresses from a single seed; the displayed “address” in modern wallets is typically the next-unused address from the derivation tree.

For substantive engagement with chain-analysis exposure, see Address reuse and chain analysis (Privacy practice within Self-custody).

Tradeoffs and design choices

Why HASH160 instead of the full public key for P2PKH? Three reasons:

  1. Shorter addresses. 20 bytes versus 33 bytes for a compressed public key — shorter strings are easier to share and copy.
  2. Forward-secrecy until spend. Until the address is spent from, the public key isn’t on the chain. This is a marginal benefit in 2026 (most spent addresses have their public key visible from prior spends), but it was a defensible design choice in 2009.
  3. Quantum-resistance optionality. If quantum computing eventually breaks ECDLP, unspent P2PKH/P2WPKH outputs have a HASH160-based layer of protection that P2TR (which exposes the x-only public key in the output) lacks. The substantive engagement is in Quantum computing threat to Bitcoin.

Why Base58Check originally, then Bech32? Base58Check was Satoshi’s pragmatic choice in 2008 — adequate error detection plus visually-distinguishable characters. Bech32 was designed in 2016-2017 specifically for the SegWit upgrade and offers mathematically superior error-detection. The practical difference (typos caught reliably) matters more than the underlying mathematics, but the mathematics is what makes it work.

Why Bech32m for Taproot? During SegWit v0 deployment, a subtle issue was discovered in Bech32: certain trailing-zero patterns could produce errors that the checksum didn’t detect. Bech32m (the ‘m’ for “modified”) corrects this with a different constant in the checksum polynomial. The error condition is rare in practice but the fix is essentially free.

The address-type fee gradient. Per spend, in approximate order of decreasing fee:

  1. P2PKH (legacy 1...) — most expensive
  2. P2SH (3...) — slightly cheaper than P2PKH for the same payload due to encoding
  3. Nested SegWit (P2SH-P2WPKH) — ~25% cheaper than P2PKH via the SegWit weight discount
  4. P2WPKH (native SegWit, bc1q... short) — ~40% cheaper than P2PKH
  5. P2TR (Taproot, bc1p...) — typically the cheapest, especially for multi-input or multisig spends

These differences compound across many spends; users with high transaction frequency see substantial fee savings from modern address types.

The privacy gradient. Taproot’s key-path spend is the privacy-best option (single-sig and multisig look identical on-chain). Native SegWit is intermediate. Legacy P2PKH (especially with address reuse) is the most chain-analysis-tractable. Privacy-conscious holders should default to P2TR if their wallet supports it, P2WPKH otherwise.

For substantive engagement with the chain-analysis implications of address-type choice, see Address reuse and chain analysis (Privacy practice) and KYC leakage (Privacy practice). For the quantum-threat dimension of P2TR’s exposed public keys, see Quantum computing threat to Bitcoin (Criticisms section).

Open questions for further development

  • Will Taproot adoption eventually push legacy P2PKH/P2SH usage to near-zero, or will the long tail of legacy UTXOs and conservative wallets keep those types in active use indefinitely? The 2026 distribution is shifting but slowly.
  • For post-quantum migration: do new address types emerge alongside post-quantum signature schemes (e.g., P2QR for quantum-resistant signatures), or does the existing address-type taxonomy get reused?
  • What’s the right convention for displaying multiple address types to a non-technical holder? Modern wallets generally pick the most efficient type silently; some advanced wallets offer per-type display.
  • Are there structural reasons to expect further address-type proliferation, or is the P2TR-and-future SegWit-versions framework adequate indefinitely?

Canonical sources for this note

Bitcoin Improvement Proposals (primary sources)

  • BIP-13 — Address format for P2SH (2011).
  • BIP-16 — Pay-to-Script-Hash activation (2012).
  • BIP-141 — Segregated Witness (consensus layer); defines P2WPKH and P2WSH.
  • BIP-143 — Transaction signature verification for v0 witness programs.
  • BIP-173 — Bech32 encoding; defines the address format for SegWit v0.
  • BIP-341 — Taproot; defines P2TR.
  • BIP-350 — Bech32m encoding; defines the address format for SegWit v1 and beyond.

Bitcoin engineering references

  • Mastering Bitcoin, Andreas Antonopoulos (chapter 4: “Keys, Addresses”) — the canonical engineering treatment. See Mastering Bitcoin - Andreas Antonopoulos.
  • Programming Bitcoin, Jimmy Song (chapter 6: “Script”, chapter 13: “SegWit”) — working-programmer treatment.

Graph View

Backlinks