Skip to content

Bitcoin Address Prefixes: What 1, 3, bc1q and bc1p Encode

A Bitcoin address is a compact way to write down the condition that must be met to spend an output, not a bank-style account with a stored balance. The opening characters, 1, 3, bc1q, or bc1p, tell a wallet which script type will receive the coins. They do not tell you who owns the address, whether it is valid, or whether the sender picked the correct network.

Four families, four scripts

Legacy Pay-to-Public-Key-Hash addresses begin with 1. The output commits to a hash of a public key; spending it means revealing that key and signing. The format is still valid Bitcoin, but legacy inputs carry more transaction weight than SegWit inputs, so they tend to cost more in fees when block space is tight.

Addresses beginning with 3 are Pay-to-Script-Hash. The sender commits to a hash of a script rather than the script itself, which made multisig and other custom conditions practical. A 3 prefix identifies the P2SH family only. It does not prove the address is SegWit; wrapped SegWit is one use of P2SH, not the whole category.

bc1q addresses are native SegWit version 0, encoded with Bech32 as defined in BIP 173. Single-key wallets normally use P2WPKH, a 20-byte program that produces a 42-character mainnet address; P2WSH uses a 32-byte program and 62 characters. bc1p addresses are Pay-to-Taproot, witness version 1, and use a modified checksum called Bech32m from BIP 350. The q and p are not interchangeable spellings: version 0 uses Bech32, while versions 1 through 16 use Bech32m.

Why the prefix is not a validity check

A prefix is a recognition aid, not validation. A real address must also have the right length, checksum, network version, and witness-program size. Clipboard malware can swap in another perfectly valid address that passes every format check and sends the payment somewhere else. Format validation catches transcription errors; it does not authenticate the recipient.

The encodings differ in ways that matter when copying. Base58Check, used by 1 and 3 addresses, is case-sensitive and excludes 0, O, I, and l to reduce visual confusion. Bech32 and Bech32m use the 32-character set qpzry9x8gf2tvdw0s3jn54khce6mua7l, which drops 1, b, i, and o but keeps 0 and l. Mixed-case Bech32 is invalid; wallets display these addresses in lowercase.

Where fees come from

Bitcoin fees track transaction weight, not the number of coins moved. SegWit moved signatures into a witness structure that is counted at a lower weight, and native SegWit also skips the extra wrapper that nested SegWit needs. Spending P2WPKH inputs is generally lighter than spending comparable legacy inputs. Taproot key-path spends can be compact too, but the real cost depends on the mix of inputs and outputs and the fee rate. No format guarantees a fixed percentage saving.

A practical rule

Let the receiving wallet generate the address. Do not paste a string into a third-party converter to fix a withdrawal form; a different script type needs an address the wallet actually controls. Confirm the asset and network first: a plausible-looking address does not distinguish Bitcoin from Bitcoin Cash. Check the sender supports the format, verify the full address on a trusted screen, and use a small test transaction when the amount justifies it. Generate a fresh receive address for new payments: a newer prefix is not a privacy shield, and reuse creates clustering signals that Taproot key-path spending only partially obscures.

Adapted from Bitcoin Address Formats Explained: Legacy, SegWit, and Taproot.