Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Protocol & Mining

Bitcoin address types, and what the prefix tells you

An address is not an account and not a key. It is a compact, error-checked encoding of a spending condition, and the characters at its start identify which family of condition it encodes. Four families are in common use, and they differ in how they are encoded and what they cost to spend.

Protocol referenceSource: BIP 13, BIP 16, BIP 141, BIP 173, BIP 350Prefixes and encodings follow the BIPs named in the sources below.

What an address actually is

The word address suggests a location, and the analogy misleads. A Bitcoin address is a string that encodes a spending condition — the same condition that sits on an output — together with a checksum that lets a wallet detect a typo before it sends anything. When a payer sends bitcoin to an address, the wallet decodes the string, extracts the condition, and builds an output that pays to it. The address itself never appears on the chain. What appears is the condition, and the address is the human-readable form of it.

This is why the same underlying key can be represented by more than one address, and why an address should not be reused. Each address encodes a condition, and a wallet that generates a fresh condition for every payment gives an observer less to link together. Reuse is not forbidden by the protocol; it is simply poor practice, because it publishes the same condition repeatedly and makes the payments trivially connectable.

The families below are distinguished by the kind of condition they encode and by the encoding used to write it down. The encoding matters because it determines what a payer's wallet must support, and the condition matters because it determines what a spender's wallet must provide and how much block space the spend consumes.

The four families

Legacy P2PKH. The original form, specified in the first version of the protocol and still the most widely recognised. The condition is a public key hash: the output can be spent by anyone who presents a public key that hashes to the recorded value, together with a signature that verifies against it. The address is the hash with a version byte prepended, encoded in Base58Check, and it begins with the digit 1. Its weakness is size: the public key must be included in full when the output is spent, and the signature is encoded in the older format, so a P2PKH spend occupies more block space than the newer forms.

P2SH. Pay to script hash, introduced by BIP 16, moves the complexity out of the address and into the spend. The output records the hash of a script rather than a public key hash, and the spender supplies the script itself along with whatever satisfies it. The address is again Base58Check and begins with the digit 3. The advantage is that the payer does not need to know what the condition is — a multi-signature arrangement, a timelock, anything expressible in Script — and the condition is revealed only when it is spent. P2SH is also the wrapper that made SegWit available to wallets that had not yet adopted the new address format.

Native SegWit, bech32. BIP 173 introduced a new encoding for SegWit outputs, and BIP 141 defined the outputs themselves. The address is written in bech32, a format designed for error detection and for use in QR codes, and it begins with the prefix bc1. Because bech32 is case-insensitive in a controlled way and carries a stronger checksum than Base58Check, it catches more transcription errors. The witness data that satisfies the output is discounted under the block-weight rule, so a native SegWit spend is cheaper in fee terms than the equivalent legacy spend. The SegWit page covers the mechanism.

Taproot, bech32m. BIP 341 defined the Taproot output, and BIP 350 defined bech32m, a variant of bech32 with a different checksum constant, because the original bech32 checksum was found to be weaker than intended for the longer witness programs Taproot uses. A Taproot address also begins with bc1, and the two are distinguished by their length and by the checksum variant rather than by a different prefix. The condition can be satisfied either by a single Schnorr signature — the key path — or by revealing one branch of a script tree, and the two are indistinguishable on-chain. The Taproot page covers the privacy gain that follows.

Choosing between them

For a payer, the practical question is compatibility. A wallet that supports only legacy addresses cannot pay a bech32 address, and a wallet that supports bech32 may or may not support bech32m. Modern wallets support all four, and the choice is usually made for the recipient rather than the payer: the address a recipient publishes determines what the payer must be able to handle.

For a recipient, the question is cost and privacy. A native SegWit or Taproot output is cheaper to spend than a legacy one, because the witness discount applies to the data that satisfies it. Taproot adds a privacy property the others do not have: a spend that uses the key path looks identical to a spend that uses a script path, so an observer cannot tell whether a complex condition was involved. For an arrangement that would otherwise be visibly a multi-signature script, that is a real improvement.

What none of the families change is the underlying model. Every one of them encodes a condition on an output, and every one of them is spent by satisfying that condition. The UTXO model page explains why that is the case, and the block size and weight page explains how the witness discount is calculated.

Sources

Related reading