Bitcoin address types explained: legacy, SegWit and Taproot

A Bitcoin address is a short encoding of the script that locks your coins. Its first characters tell you the type: 1 is legacy P2PKH, 3 is P2SH (often nested SegWit), bc1q is native SegWit (P2WPKH or P2WSH) and bc1p is Taproot (P2TR). All types can pay each other. Newer types cost less to spend because more of their data sits in the discounted witness, and Taproot makes complex spending conditions look like ordinary payments.

Updated 2026-10-20 · 8 min read

The five Bitcoin address types at a glance

An address isn't stored on the blockchain. It is a human-friendly way to write an output's scriptPubKey, the small script that says what is needed to spend the coins. Wallets decode the address back into that script when you send. The address checker shows which type any address is.

P2PKH: legacy addresses starting with 1

Pay to Public Key Hash is the original address type. The output script is:

OP_DUP OP_HASH160 <20-byte public key hash> OP_EQUALVERIFY OP_CHECKSIG

To spend, you reveal your public key and a signature. P2PKH predates the BIP process, so no BIP defines it, though later BIPs describe it (for example BIP 381's pkh() descriptor). The address is the version byte 0 plus the 20-byte hash, encoded in Base58Check, which is why it starts with 1.

Signatures and public keys sit in the input's scriptSig, which pays full price, so P2PKH is the most expensive common type to spend. Wallets following BIP 44 use these addresses.

P2SH: addresses starting with 3

Pay to Script Hash (BIP 16, Gavin Andresen) lets you send to the hash of any script. The receiver reveals the full script, called the redeem script, only when spending:

OP_HASH160 <20-byte script hash> OP_EQUAL

Before P2SH, a sender had to put the full script, such as a multisig with three public keys, in their own transaction. P2SH moved that cost and complexity to the receiver, behind a short address. BIP 13 defined the address format: version byte 5, which always encodes to a leading 3. P2SH was enforced from April 2012.

A 3 address can hide many things, most commonly:

• Multisig, such as 2-of-3 (see the multisig guide).
• Nested (wrapped) SegWit: a SegWit script inside P2SH, so that wallets which couldn't send to bc1 addresses could still pay SegWit users. P2SH-P2WPKH, used by BIP 49 wallets, has a redeem script of 0x0014{20-byte key hash}. P2SH-P2WSH is the multisig equivalent.

You can't tell which from the address alone. That only becomes visible when the coins are spent.

P2WPKH: native SegWit addresses starting with bc1q

Segregated Witness (BIP 141) moved signatures out of the scriptSig into a separate witness, which counts for less toward the block limit. Native SegWit outputs are a version number plus a witness program:

OP_0 <20-byte public key hash>

A 20-byte program at version 0 is P2WPKH (Pay to Witness Public Key Hash), the single-key SegWit type. BIP 173, by Pieter Wuille and Greg Maxwell, encodes it with Bech32 using the prefix bc, so the address starts with bc1q (the q is version 0). Version 0 addresses are always 42 or 62 characters; P2WPKH is the 42-character one. BIP 84 wallets use this type.

P2WSH: SegWit script addresses (62 characters)

Pay to Witness Script Hash is SegWit's version of P2SH. The witness program is the 32-byte SHA-256 hash of the script:

OP_0 <32-byte script hash>

Because the program is 32 bytes, P2WSH addresses are 62 characters long, though they also start with bc1q. Length is the quickest way to tell them from P2WPKH. P2WSH is mainly used for multisig and other scripts, such as the 2-of-2 outputs that open Lightning channels. BIP 141 notes that the longer 32-byte hash improves security against collision attacks compared with P2SH's 20 bytes, and that scripts can be up to 10,000 bytes instead of P2SH's 520.

P2TR: Taproot addresses starting with bc1p

Taproot (BIP 341, with BIP 340 Schnorr signatures and BIP 342 Tapscript) is SegWit version 1, activated at block 709,632 in November 2021:

OP_1 <32-byte x-only output key>

The output is a single public key, which can also commit to a hidden tree of scripts. It can be spent in two ways:

• Key path: one Schnorr signature. This is the cheapest and most private spend, and it looks the same whether the key belongs to one person or is a MuSig2 aggregate of several.
• Script path: reveal one script from the tree, plus a proof that it was committed to. The other scripts stay hidden.

Version 1 is encoded as p, so Taproot addresses start with bc1p and are 62 characters long. Single-key Taproot wallets use BIP 86. Silent payments (BIP 352) also pay to Taproot outputs.

P2A: the "fees" anchor address

BIP 433 describes Pay to Anchor (P2A), a tiny keyless output (OP_1 <0x4e73>) that anyone can spend. It exists as a hook for fee bumping with child-pays-for-parent, mostly in Lightning and other layer 2 protocols. Its mainnet address is the short bc1pfeessrawgf, chosen to spell "fees". You won't receive payments to it; it's useful to recognize if you see it in a block explorer.

Base58Check vs Bech32 vs Bech32m

The three encodings differ in how they protect against typos and how they display:

• Base58Check (legacy and P2SH) uses 58 characters with mixed case and a 4-byte checksum from double SHA-256. Mixed case is awkward to read aloud, and it takes a lot of space in QR codes.
• Bech32 (BIP 173) uses 32 characters and is case-insensitive, so it can be written all in lowercase or put in a QR code in uppercase, which BIP 173 notes is 45% more compact. Its BCH checksum is guaranteed to detect any error affecting at most 4 characters.
• Bech32m (BIP 350, Pieter Wuille) fixes a weakness found in Bech32: when the last character is p, extra q characters could be inserted or removed just before it without breaking the checksum. This didn't affect version 0 addresses, because they must be exactly 42 or 62 characters, but it could affect future versions. Bech32m changes one constant in the checksum and is used for SegWit version 1 and above, including Taproot.

BIP 173 vs BIP 350 compares the two in detail.

Testnet, signet and regtest addresses

Test networks use different prefixes so test coins can never be confused with real ones:

BIP 13 sets testnet P2SH to version byte 196, which encodes to 2. BIP 173 chose tb for testnet because it is the same length as bc but visibly different.

Which address type has the lowest fees?

Fees depend on transaction size in virtual bytes (vbytes). Under SegWit, witness data counts one quarter as much as other data, so moving signatures into the witness makes inputs cheaper. Typical sizes for single-key spends:

The input sizes assume compressed keys and typical ECDSA signature sizes; exact numbers vary by a byte or so.

Two things stand out. Spending a legacy input costs more than twice as much as a native SegWit or Taproot input. And Taproot doesn't make every transaction smaller: its outputs are 12 vB larger than P2WPKH outputs, but its inputs are about 10.5 vB smaller, so over a coin's whole life the two cost about the same. Taproot's bigger savings come with multisig and complex scripts, where a key-path spend still needs only one signature. Try your own combinations with the transaction size calculator.

Address types and privacy

Every address type is pseudonymous, and none hides amounts. A few differences still matter:

• Address reuse links payments. Use a new address for every payment, whatever the type. Silent payments are one way to publish a single reusable address without this problem.
• Mixing types can reveal your change. If you pay a bc1q address from bc1p inputs, the bc1p output is probably your change. Using the same type as the people you pay helps.
• Spending reveals the script. P2SH and P2WSH reveal the whole script when spent, so observers can see, for example, that you used 2-of-3 multisig. Taproot reveals nothing extra on a key-path spend, and only the one script used on a script-path spend.

Can I send from one address type to another?

Yes. Every address type can send to every other type; the network only cares that the output script is valid. The only limit is software: a wallet must understand an address format before it can pay it. A wallet that predates BIP 173 can't send to bc1q addresses, and one that implemented BIP 173 but not BIP 350 can't send to bc1p addresses. That's why nested SegWit (3 addresses) existed as a bridge.

Which address type should I use?

There's no single right answer, but the trade-offs are clear:

• Native SegWit (bc1q) is cheap to spend and widely understood by sending software.
• Taproot (bc1p) costs about the same for single-key use, and is cheaper and more private for multisig and complex scripts. Make sure the services that pay you can send to it.
• Nested SegWit (3) and legacy (1) mainly matter for compatibility with old software or old wallets you're recovering.

Each type lives on its own derivation path, so the same seed phrase gives different addresses for each. If a restored wallet looks empty, check that it is scanning the type you actually used.