Bitcoin Address Types: From Legacy P2PKH to Taproot

Bitcoin address types have evolved significantly since the network launched in 2009. What started as a single format (addresses beginning with "1") has branched into four distinct types, each with different fee characteristics, privacy properties, and script capabilities. Understanding these formats is essential for developers building wallets, exchanges, or any application that interacts with the Bitcoin network.

This article covers each Bitcoin address type in depth: P2PKH, P2SH, P2WPKH (native SegWit), and P2TR (Taproot). We will examine the underlying scripts, the BIP standards that define them, transaction fee differences, and practical guidance for choosing the right format.

How Bitcoin Addresses Work

A Bitcoin address is a human-readable encoding of a locking script (also called a scriptPubKey). When you send Bitcoin to an address, you are creating a UTXO locked by the script that address represents. To spend that UTXO, you must provide data (typically a signature) that satisfies the script conditions.

Different address types encode different script templates. Legacy addresses use Base58Check encoding, while newer formats use Bech32 or Bech32m. The encoding determines what the address looks like, while the underlying script determines how the locked funds can be spent.

Each address type is also associated with a specific derivation path in HD wallets, governed by its own BIP standard. This means the same seed phrase can generate addresses across all four types by using different derivation paths.

P2PKH: Legacy Addresses (1...)

Pay-to-Public-Key-Hash (P2PKH) is the original Bitcoin address format, available since the genesis block in January 2009. These addresses always start with the number "1" and use Base58Check encoding, which excludes visually ambiguous characters (0, O, I, l) to reduce transcription errors.

How P2PKH scripts work

A P2PKH locking script contains the hash of a public key. To spend a P2PKH output, the spender must provide two things in the scriptSig: their full public key and a valid ECDSA signature. The Bitcoin Script interpreter then verifies that the public key hashes to the expected value and that the signature is valid for the transaction.

The scriptPubKey follows this pattern: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. This is one of the most well-understood script templates in Bitcoin and remains supported by every wallet and exchange on the network.

Derivation path

P2PKH addresses follow BIP44, which defines the derivation path m/44'/0'/0'/0/0 for the first Bitcoin address. The "44" at the purpose level indicates P2PKH, and coin type "0" specifies Bitcoin mainnet.

Limitations

P2PKH transactions are the largest by virtual size. A typical single-input, two-output P2PKH transaction weighs approximately 226 vBytes. Because all transaction data (including the signature) counts at full weight with no discount, P2PKH users pay the highest fees per transaction compared to any newer format.

P2SH: Script Hash Addresses (3...)

Pay-to-Script-Hash (P2SH) was introduced in 2012 via BIP16. These addresses start with "3" and use the same Base58Check encoding as P2PKH. The key innovation: instead of locking funds to a public key hash, P2SH locks funds to the hash of an arbitrary script.

How P2SH scripts work

The locking script simply checks that the provided script (called the "redeem script") hashes to the expected value. The redeem script itself can contain any valid Bitcoin Script logic: multisignature requirements, timelocks, hash preimage checks, or combinations of these.

This design offers two advantages. First, the sender does not need to understand the spending conditions: they just send to a standard-looking address. Second, the complexity of the redeem script only hits the blockchain when the output is spent, not when it is created.

Common P2SH use cases

• Multisig wallets requiring m-of-n signatures (e.g., 2-of-3 corporate treasury setups)
• Wrapped SegWit (P2SH-P2WPKH): a transitional format that embeds a SegWit script inside a P2SH wrapper for backward compatibility
• HTLCs used in Lightning payment channels and atomic swaps

Derivation path

Nested SegWit addresses (P2SH-P2WPKH) follow BIP49 with the path m/49'/0'/0'/0/0. The "49" at the purpose level signals nested SegWit. Extended public keys use the "ypub" prefix to distinguish them from standard BIP44 xpubs.

P2SH-P2WPKH was a bridge: When SegWit activated in 2017, many wallets and exchanges could not yet parse Bech32 addresses. P2SH-P2WPKH let users benefit from SegWit's fee savings while keeping compatibility with legacy senders. Today, with native SegWit widely supported, this wrapped format is largely obsolete.

P2WPKH: Native SegWit Addresses (bc1q...)

Pay-to-Witness-Public-Key-Hash (P2WPKH) is the native Segregated Witness format, activated on August 24, 2017 at block 481,824 via BIP141. These addresses start with "bc1q" and use Bech32 encoding as defined in BIP173.

The SegWit witness discount

SegWit's core innovation is moving signature data (the "witness") to a separate structure that receives a 75% weight discount. Witness data still exists in the transaction, but each byte of witness data counts as only 0.25 weight units instead of 1. This discount is what makes SegWit transactions cheaper.

A typical single-input, two-output P2WPKH transaction weighs approximately 141 vBytes, compared to 226 vBytes for the equivalent P2PKH transaction. That translates to roughly 38% lower fees for the same operation.

Bech32 encoding

Unlike Base58Check, Bech32 uses a lowercase alphanumeric character set with no mixed case. This makes addresses easier to read, copy, and encode in QR codes. Bech32 also includes a stronger error-detection algorithm that can identify up to four character errors and locate up to two of them.

Derivation path

P2WPKH addresses follow BIP84 with the path m/84'/0'/0'/0/0. Extended public keys use the "zpub" prefix. Most modern wallets default to this format when generating new receive addresses.

P2TR: Taproot Addresses (bc1p...)

Pay-to-Taproot (P2TR) is the newest address format, activated on November 14, 2021 at block 709,632 via BIP341. Also referred to as SegWit v1, Taproot addresses start with "bc1p" and use Bech32m encoding (BIP350), a modified version of Bech32 that fixes an edge-case mutation vulnerability in the original encoding.

Schnorr signatures and key path spending

Taproot replaces ECDSA with Schnorr signatures (BIP340). Schnorr signatures are exactly 64 bytes, compared to ECDSA signatures which vary between 71 and 73 bytes. This fixed size enables predictable fee estimation: wallets know the exact transaction weight before signing.

The most common spending path for P2TR is the "key path" spend, where a single Schnorr signature authorizes the transaction. On-chain, a key path spend is indistinguishable from any other P2TR spend, regardless of whether the underlying key is a single key or an aggregated MuSig2 multisignature.

Script path and MAST

P2TR also supports script path spending via Merklized Alternative Script Trees (MAST). A P2TR output can commit to a Merkle tree of alternative spending conditions. When spending via the script path, only the branch being used is revealed on-chain. All other branches remain hidden, improving both privacy and efficiency.

This architecture is particularly valuable for complex contracts. A timelock fallback, a multisig override, and a hash preimage condition can all coexist in the same MAST tree. The spender reveals only the path they actually use.

Derivation path

P2TR addresses follow BIP86 with the path m/86'/0'/0'/0/0. BIP86 specifies key-only spending with no script tree commitment, making it the simplest P2TR derivation scheme. Wallets that want to include MAST trees use custom derivation logic on top of the BIP86 base.

Taproot and Ordinals: The Taproot upgrade enabled the Ordinals protocol, BRC-20 tokens, and Runes. All of these asset types are stored exclusively in P2TR outputs, using the script path and OP_RETURN mechanisms that Taproot made practical. Building a wallet that supports these assets requires P2TR support.

Address Type Comparison

The following table compares the four address types across key dimensions relevant to developers and users.

Transaction Fee Comparison

Transaction fees depend directly on the virtual size (vBytes) of a transaction. The following table shows approximate sizes for a typical single-input, two-output transaction at each address type, based on data from the Bitcoin Optech transaction size calculator.

A nuance in the numbers: P2TR outputs are larger (43 bytes vs. 31 bytes for P2WPKH) because Taproot public keys are 32 bytes using x-only encoding. However, P2TR inputs are the smallest of any type at 57.5 vBytes for single-sig, saving 15% over P2WPKH inputs. This means P2TR becomes increasingly efficient in transactions with many inputs, which is the common case for UTXO consolidation and merchant payment aggregation.

Predictable fees matter: ECDSA signatures used by P2PKH and P2WPKH vary between 71 and 73 bytes depending on the nonce. Wallets must assume the worst case (73 bytes) when estimating fees, sometimes overpaying. Schnorr signatures in P2TR are always exactly 64 bytes, enabling precise fee calculation every time.

Multisig: Where Taproot Excels

The fee advantages of P2TR are most dramatic in multisignature setups. With legacy P2SH or native P2WSH multisig, every participating public key and signature must appear on-chain. A 2-of-3 multisig input using P2WSH weighs approximately 104.5 vBytes.

With P2TR key path spending using MuSig2 or FROST threshold signatures, all signers aggregate their keys and signatures off-chain into a single public key and a single 64-byte Schnorr signature. The on-chain footprint of a 2-of-3 multisig P2TR key path spend is just 57.5 vBytes: a 45% reduction compared to P2WSH.

This aggregation also benefits privacy. On-chain, a P2TR key path spend from a multisig wallet looks identical to a single-sig spend. Outside observers cannot determine whether one person or ten people authorized the transaction.

Privacy Considerations

Address types leak information. When a network has a mix of address formats, the type itself becomes a fingerprint. A transaction spending from a P2PKH input to a P2TR output reveals that the sender uses legacy software while the recipient uses a modern wallet.

Change output heuristics

Wallets typically send change back to an address of the same type. If a transaction has one P2WPKH output and one P2TR output, an observer can often guess which is the payment and which is the change. Using P2TR for both sending and receiving eliminates this heuristic, since all outputs look the same.

Taproot's script privacy

In pre-Taproot script types, the full spending conditions are revealed when the output is spent. A P2SH multisig reveals all public keys and the threshold. With P2TR, key path spends reveal nothing about alternative spending conditions. Even if a MAST tree contains ten different script branches, spending via the key path hides all of them.

Wallet Compatibility and Adoption

Not all wallets and exchanges support all address types equally. Legacy P2PKH and P2SH have near-universal support. Native SegWit (bc1q) is supported by the vast majority of wallets and exchanges. Taproot (bc1p) support has grown steadily since 2021, though a minority of older services still cannot send to Bech32m addresses.

According to on-chain data from Glassnode, Taproot's share of Bitcoin transactions grew to around 42% in 2024, largely driven by Ordinals and BRC-20 activity. That share has since fluctuated as market conditions and on-chain asset usage patterns shift.

Choosing the right address type

For new wallets and applications in 2026, the recommendation is straightforward:

• Default to P2TR (Taproot) for new development: it offers the best input efficiency, predictable fees, Schnorr signature support, and MAST capability
• Use P2WPKH (native SegWit) as a fallback if you need to interact with services that do not yet support Bech32m
• Avoid P2PKH and bare P2SH for new applications: the fee overhead is significant and there is no technical advantage
• For multisig setups, P2TR with MuSig2 or FROST is strongly preferred for both fee savings and privacy

The Address Gap Limit

When recovering a wallet from a seed phrase, the wallet software scans the blockchain for used addresses along the derivation path. The address gap limit defines how many consecutive unused addresses the wallet checks before stopping. The standard gap limit is 20, as specified in BIP44.

This becomes relevant when switching address types. If a wallet was originally set up with BIP44 (P2PKH) addresses and you recover it using BIP84 (P2WPKH) or BIP86 (P2TR) derivation paths, the wallet will not find the old addresses. You need to scan all relevant derivation paths to recover the full balance. Most modern wallets handle this automatically, but developers building recovery tools should account for all four path types.

Extended Public Keys Across Types

Each address type uses a distinct version prefix for its extended public key to prevent confusion:

• BIP44 (P2PKH): "xpub" prefix (version bytes 0x0488B21E)
• BIP49 (P2SH-P2WPKH): "ypub" prefix (version bytes 0x049D7CB2)
• BIP84 (P2WPKH): "zpub" prefix (version bytes 0x04B24746)
• BIP86 (P2TR): no widely adopted distinct prefix yet; many wallets use standard "xpub" with explicit path metadata

When importing an extended public key into a watch-only wallet, verifying the prefix ensures the wallet derives addresses using the correct script type. Importing a zpub into a tool expecting an xpub will generate incorrect addresses.

Taproot in Practice: Spark and Modern Protocols

Modern Bitcoin Layer 2 protocols are built on Taproot. Spark, for example, uses P2TR addresses for all on-chain interactions. Deposits go to Taproot addresses, and final settlements are Taproot transactions. This choice is not cosmetic: Spark relies on FROST threshold signatures, which produce aggregated Schnorr signatures that can only be verified in a Taproot context.

The MAST capability of P2TR is equally important for Layer 2 designs. Pre-signed exit transactions, timelock fallbacks, and cooperative close paths can all coexist in a single MAST tree. On-chain, the cooperative case (key path spend) looks like a simple single-signature transaction, minimizing fees and revealing no information about the protocol's internal structure. Only if a dispute arises does the relevant script branch get revealed.

This pattern extends beyond Spark. The Ark protocol, Lightning channels using PTLCs, and covenant proposals all assume Taproot as the base output type. For developers building on Bitcoin today, P2TR is the foundational address format.

Dust and small UTXOs: Taproot's larger output size (43 bytes) means the dust threshold for P2TR outputs is slightly higher than for P2WPKH. At a fee rate of 3 sat/vB, the dust limit for P2TR is 330 satoshis compared to 294 satoshis for P2WPKH. This is rarely a practical concern, but it matters for protocols that create many small outputs.

Getting Started with Taproot

For developers looking to build Bitcoin applications with Taproot support, the Spark SDK documentation provides a practical starting point for integrating Taproot-based deposits, transfers, and settlements. If you are building a consumer wallet, General Bread demonstrates what a Spark-powered wallet experience looks like in production.

For deeper reading on the Bitcoin Script fundamentals that underpin all four address types, see our article on Bitcoin Script programmability. For a broader view of how address types fit into the transaction lifecycle, see Bitcoin transaction lifecycle explained.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.