Bitcoin Address Formats Explained: Legacy, SegWit, Taproot
Complete guide to Bitcoin address formats: P2PKH, P2SH, P2WPKH, P2WSH, and P2TR. Learn which format to use, fee differences, and compatibility.
Bitcoin Address Formats Overview
Bitcoin has five active address formats, each corresponding to a different script type and era of protocol development. The format you choose affects transaction fees, privacy, compatibility with wallets and exchanges, and access to advanced features like Schnorr signatures and script trees. Understanding the differences is essential for developers building wallet software and for users who want to minimize costs.
The table below summarizes the key properties of each format. Detailed breakdowns follow in subsequent sections.
| Format | Prefix | Encoding | BIP | Derivation Path | Signature | Activated |
|---|---|---|---|---|---|---|
| P2PKH (Legacy) | 1 | Base58Check | BIP 44 | m/44'/0'/0' | ECDSA | 2009 |
| P2SH (Nested SegWit) | 3 | Base58Check | BIP 49 | m/49'/0'/0' | ECDSA | 2012 |
| P2WPKH (Native SegWit) | bc1q | Bech32 | BIP 84 | m/84'/0'/0' | ECDSA | 2017 |
| P2WSH (SegWit Script) | bc1q | Bech32 | BIP 84 | m/84'/0'/0' | ECDSA | 2017 |
| P2TR (Taproot) | bc1p | Bech32m | BIP 86 | m/86'/0'/0' | Schnorr | 2021 |
P2PKH: Legacy Addresses Starting With 1
Pay-to-Public-Key-Hash (P2PKH) is the original Bitcoin address format, present since the genesis block in 2009. The sender locks funds to the hash of the recipient's public key. To spend, the recipient must reveal the full public key and provide a valid ECDSA signature.
P2PKH addresses use Base58Check encoding and always start with 1. They are universally supported by every Bitcoin wallet, exchange, and service. The tradeoff is cost: P2PKH transactions are the largest in virtual bytes because the signature and public key are stored in the main transaction body rather than in the segregated witness structure. A typical single-input, two-output P2PKH transaction weighs approximately 226 vbytes.
Legacy addresses remain useful when sending to recipients on very old software that does not support newer formats. Outside that scenario, there is no technical reason to prefer P2PKH over SegWit or Taproot addresses.
P2SH: Nested SegWit Addresses Starting With 3
Pay-to-Script-Hash (P2SH) was introduced in 2012 via BIP 16. Instead of locking funds to a public key hash, P2SH locks funds to the hash of an arbitrary script. This enabled multisig wallets, timelocks, and other complex spending conditions without burdening the sender with the full script details.
When SegWit activated in 2017, P2SH gained a second life as a backwards-compatible wrapper for SegWit scripts. P2SH-P2WPKH (nested SegWit) addresses start with 3 and allow SegWit transactions to be sent from wallets that only understand the P2SH format. This was a critical transitional mechanism, but it comes with overhead: the wrapping adds extra bytes compared to native SegWit. Nested SegWit transactions save roughly 24% on fees compared to P2PKH, but native SegWit saves 35% or more.
Today, P2SH-wrapped SegWit is considered a legacy compatibility format. Most modern wallets default to native SegWit (P2WPKH) or Taproot (P2TR) instead.
P2WPKH and P2WSH: Native SegWit Addresses Starting With bc1q
Native SegWit (BIP 141, BIP 173) moved witness data (signatures and public keys) into a separate structure outside the main transaction body. Because witness bytes are discounted at 0.25 weight units each (compared to 1.0 for non-witness bytes), SegWit transactions consume significantly less block space.
P2WPKH is the single-sig variant: 42 characters long, always starting with bc1q, encoded in Bech32. A typical 1-input, 2-output P2WPKH transaction is roughly 141 vbytes, a 38% reduction from P2PKH. P2WSH is the script-hash variant used for multisig and complex scripts. P2WSH addresses also start with bc1q but are 62 characters long (using SHA-256 hashing alone, without RIPEMD-160).
Native SegWit adoption has reached approximately 90-95% of all Bitcoin transactions. It is the recommended default for most wallets and applications due to its wide compatibility and low fees.
P2TR: Taproot Addresses Starting With bc1p
Pay-to-Taproot (P2TR) was activated in November 2021 through BIPs 340, 341, and 342. It represents the most significant upgrade to Bitcoin's script capabilities since SegWit. P2TR addresses are 62 characters long, start with bc1p, and use Bech32m encoding (BIP 350).
Taproot introduces three key innovations. First, Schnorr signatures replace ECDSA. Schnorr signatures are 64 bytes (versus ECDSA's variable 71-73 bytes) and enable key aggregation: multiple signers can produce a single compact signature that looks identical to a single-key spend. Second, MAST (Merkelized Alternative Script Trees) allows complex spending conditions to be committed in a Merkle tree, where only the executed branch is revealed on-chain. Third, all P2TR outputs look identical on the blockchain regardless of whether they involve a single key, a multisig arrangement, or a complex script, significantly improving privacy.
For single-sig key-path spends, P2TR saves approximately 15% on input costs compared to P2WPKH. The witness data for a P2TR input is about 16.5 vbytes versus 27 vbytes for P2WPKH. Additionally, Schnorr signatures have a fixed size, which means wallets can calculate exact fees in advance rather than estimating based on worst-case ECDSA signature lengths.
Spark uses Taproot as the foundation for its Bitcoin layer 2 protocol, leveraging Taproot's script tree capabilities and Schnorr key aggregation to enable efficient off-chain state management. For a deeper look at how Taproot enables new Bitcoin functionality, see our research article on Taproot and Schnorr signatures.
Fee Comparison by Address Format
Transaction fees are directly proportional to the virtual size (vbytes) of a transaction. The following table compares typical transaction sizes and relative fee costs for a standard single-input, two-output transaction across each format.
| Format | Typical Size (1-in, 2-out) | Fee Savings vs P2PKH | Witness vbytes per Input | Fee Predictability |
|---|---|---|---|---|
| P2PKH | ~226 vbytes | Baseline | N/A (no witness) | Variable (ECDSA) |
| P2SH-P2WPKH | ~170 vbytes | ~24% | ~27 vbytes | Variable (ECDSA) |
| P2WPKH | ~141 vbytes | ~38% | ~27 vbytes | Variable (ECDSA) |
| P2WSH (2-of-3) | ~240 vbytes | ~50% vs P2SH multisig | Varies by script | Variable (ECDSA) |
| P2TR (key path) | ~211 vbytes (2-in, 2-out) | ~15% vs P2WPKH per input | ~16.5 vbytes | Fixed (Schnorr) |
The fee savings compound with transaction complexity. For a UTXO consolidation transaction with many inputs, switching from P2PKH to P2WPKH can cut fees by 38%, and P2TR saves an additional 15% per input on top of that. Use our consolidation calculator to estimate savings for your specific scenario.
Compatibility and Wallet Support
Not all wallets and exchanges support every address format. When choosing a format, consider where you will be sending to and receiving from.
- P2PKH (
1...): universally supported by all Bitcoin software - P2SH (
3...): supported by virtually all wallets and exchanges since 2012 - P2WPKH (
bc1q...): supported by all major wallets and most exchanges since 2020 - P2TR (
bc1p...): supported by most modern wallets; some exchanges still do not support Taproot withdrawals
A practical approach: use P2WPKH as your default for broad compatibility, and P2TR when you confirm your counterparties support it. You can verify any address format using our address validator tool.
Which Address Format Should You Use?
The right format depends on your priorities:
For maximum compatibility: P2WPKH (native SegWit) is the best default in 2026. It offers significant fee savings over legacy formats and is supported by essentially all active wallets and exchanges.
For lowest fees on standard transactions: P2TR (Taproot) provides the smallest input sizes for single-sig spends. It also gives you fixed-size signatures for precise fee estimation. Choose this when your counterparties support bc1p addresses.
For multisig wallets: P2TR with key aggregation via MuSig2 can make a multisig spend look identical to a single-sig spend on-chain, saving substantial fees and improving privacy. For conservative setups, P2WSH remains mature and widely audited across hardware signers.
For Ordinals, BRC-20, and Runes: P2TR is required. These protocols store inscription data in Taproot script-path spends.
For building on layer 2: Taproot is the foundation for modern Bitcoin layer 2 protocols. Spark uses Taproot's script tree capabilities for its off-chain state model, and the Ark protocol similarly relies on Taproot for its virtual UTXO design.
Taproot Adoption in 2026
Taproot adoption peaked at approximately 42% of Bitcoin transactions in 2024, driven largely by the Ordinals and inscriptions trend. As inscription activity declined, Taproot usage settled to roughly 15-20% of transactions by late 2025. SegWit (V0) adoption, by contrast, has matured to 90-95% of all transactions.
The adoption trajectory mirrors SegWit's own history: SegWit took approximately two years to reach 50% adoption and four years to reach 80%. Wallet developers, exchanges, and payment processors adopt new formats incrementally based on their own development cycles. Taproot support continues to expand as HD wallet libraries and hardware signers integrate BIP 86 derivation paths.
Address Format Security Considerations
All five formats provide strong security under current cryptographic assumptions. However, there are nuances worth considering:
- P2PKH and P2WPKH only reveal the public key hash until funds are spent. Once you spend from an address, the full public key is exposed in the transaction. Reusing addresses after spending degrades privacy and increases theoretical quantum risk
- P2TR always exposes the public key (technically a tweaked key) in the output. This has led to discussion about quantum computing vulnerability, though practical quantum attacks on Bitcoin remain speculative and years away
- BIP-360, a draft proposal for post-quantum signature support, is under development and could provide quantum-resistant spending paths for Taproot outputs
- Bech32 and Bech32m encodings include stronger error detection than Base58Check, reducing the risk of sending funds to a mistyped address
For a deeper look at key management across address types, see our guide on Bitcoin custody solutions.
Frequently Asked Questions
What is the difference between bc1q and bc1p addresses?
Both are native SegWit addresses, but they represent different versions. bc1q addresses are SegWit V0 (P2WPKH or P2WSH), activated in 2017, and use ECDSA signatures with Bech32 encoding. bc1p addresses are SegWit V1 (P2TR/Taproot), activated in 2021, and use Schnorr signatures with Bech32m encoding. Taproot addresses offer slightly lower fees per input, fixed-size signatures, and enhanced privacy for complex scripts.
Which Bitcoin address format has the lowest fees?
P2TR (Taproot) has the lowest per-input cost for single-sig transactions, saving roughly 15% compared to P2WPKH at the input level. For standard single-input transactions, P2WPKH and P2TR are close in total cost. The gap widens with more inputs: a 10-input consolidation transaction saves approximately 110 vbytes by using P2TR over P2WPKH. Legacy P2PKH addresses are the most expensive option.
Can I send Bitcoin from a legacy address to a Taproot address?
Yes. Bitcoin address formats are fully interoperable at the protocol level. You can send from any address format to any other format. The sender's wallet must support creating outputs to the recipient's address type, but all modern wallets support sending to bc1p addresses. If a sender's wallet rejects a Taproot address, it typically means the wallet software needs an update.
Why do some exchanges not support Taproot withdrawals?
Exchange support for new address formats is driven by development priorities, security audits, and infrastructure updates. Taproot requires Bech32m encoding support, updated signing libraries for Schnorr, and thorough testing. Most major exchanges added Taproot support by 2024, but some smaller platforms lag behind. Check your exchange's withdrawal page to confirm bc1p address support before generating a Taproot receive address.
Is Taproot less secure than SegWit because of quantum computing?
Taproot exposes the public key in the output script, while P2WPKH only reveals a hash of the public key until funds are spent. In theory, this gives a quantum attacker more time to derive the private key from a Taproot output. In practice, no quantum computer capable of breaking elliptic curve cryptography exists, and estimates place such capability years to decades away. Additionally, BIP-360 proposes adding post-quantum signature options to Bitcoin. The privacy and efficiency benefits of Taproot outweigh this theoretical concern for most users today.
What address format does Spark use?
Spark is built on Taproot (P2TR). It leverages Taproot's script tree capabilities and Schnorr key aggregation to manage off-chain state efficiently. When you deposit Bitcoin into Spark or withdraw back to the base layer, the on-chain transactions use Taproot outputs. This design enables Spark to support features like stablecoins (USDB) and instant transfers while inheriting Bitcoin's base-layer security.
How do I identify which address format a Bitcoin address uses?
Look at the first characters. Addresses starting with 1 are P2PKH (legacy). Addresses starting with 3 are P2SH (possibly nested SegWit). Addresses starting with bc1q are native SegWit (P2WPKH if 42 characters, P2WSH if 62 characters). Addresses starting with bc1p are Taproot (P2TR, always 62 characters). You can also paste any address into our address validator to automatically detect the format and check its validity.
This guide is for informational purposes only and does not constitute financial advice. Transaction size estimates are approximate and based on typical single-sig scenarios. Actual sizes vary based on the number of inputs, outputs, and script complexity. Always verify current fee rates and wallet compatibility before transacting.
Build with Spark
Integrate bitcoin, Lightning, and stablecoins into your app with a few lines of code.
Read the docs →
