A Bitcoin address type determines the encoding format and script family used to lock and unlock your coins, which directly affects the transaction fees you pay and whether the sender's wallet or exchange can process the transfer. Legacy addresses (starting with "1" or "3") use older encoding and produce larger transactions. SegWit addresses (bc1q) move signature data into a separate witness structure for significant fee savings. Taproot addresses (bc1p) add Schnorr signature support and advanced scripting while maintaining similar fee efficiency to SegWit. Choosing the right address type is primarily a question of compatibility with whoever is sending you bitcoin and the fee savings available at that format level. This guide covers identification by prefix, what each format does at the protocol level, how fees differ across types, and how to pick the right default for your situation.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include BIP 141 (Segregated Witness), BIP 173 (Bech32 encoding), BIP 341 (Taproot), and BIP 350 (Bech32m encoding) as published on the Bitcoin BIPs repository (github.com/bitcoin/bips). Address format specifications referenced from learnmeabitcoin.com technical documentation. SegWit and Taproot adoption statistics sourced from transactionfee.info and mempool.space. All technical details independently verified against protocol documentation current as of April 2026.
How can you identify a Bitcoin address type by its prefix?
The fastest way to determine any Bitcoin address type is to check the first characters. Each prefix maps to a specific script family and encoding method. Legacy P2PKH addresses start with "1," P2SH addresses (including nested SegWit) start with "3," native SegWit addresses start with "bc1q," and Taproot addresses start with "bc1p."
Prefix-to-type mapping
Prefix | Type | Script | Encoding | Example |
|---|---|---|---|---|
1 | Legacy P2PKH | Pay-to-Public-Key-Hash | Base58Check | 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa |
3 | P2SH (may wrap SegWit) | Pay-to-Script-Hash | Base58Check | 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy |
bc1q | Native SegWit | P2WPKH or P2WSH | Bech32 | bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq |
bc1p | Taproot | P2TR | Bech32m | bc1pmfr3p9j00pfxjh0zmgp99y8zftmd3s5pmedqhyptwy6lm87hf5sspknck9 |
Testnet addresses use different prefixes ("m," "n," or "2" for legacy; "tb1q" for SegWit; "tb1p" for Taproot). You will not encounter these on mainnet.
Why encoding matters for error prevention
Legacy addresses use Base58Check encoding, which includes visually similar characters like "0" versus "O" and "l" versus "1." These similarities create opportunities for manual transcription errors. Bech32 and Bech32m encoding (used by SegWit and Taproot respectively) eliminate ambiguous characters entirely by restricting the character set to 32 lowercase alphanumeric values. Both formats also include error-detecting checksums that catch typos before you broadcast a transaction (source: Bitcoin Wiki). The practical difference: if you mistype a character in a Bech32 address, your wallet rejects it. With Base58Check, some errors are caught, but the detection is less comprehensive.
What does a Bitcoin address actually represent?
A Bitcoin address is not a balance or an account. It encodes a set of spending conditions that define how the coins locked to that address can later be moved. When someone sends you bitcoin, they create a transaction output locked to your address. Your wallet holds the private key needed to satisfy those spending conditions and unlock the funds.
From private key to address
Your wallet generates a private key, derives a public key from it using elliptic curve multiplication, then transforms that public key into an address. The transformation differs by address type: Legacy applies SHA-256 followed by RIPEMD-160 hashing to produce a 20-byte hash, then Base58Check-encodes it. SegWit applies the same hashing but Bech32-encodes the result with a witness version prefix. Taproot uses a tweaked public key with Bech32m encoding. The address type you choose changes how the spending conditions are structured and encoded, not who controls the bitcoin.
Cross-type compatibility
You can send bitcoin between different address types without any protocol-level issue. A Legacy wallet can send to a Taproot address, and a Taproot wallet can send to a Legacy address. The receiver's address determines the output type the sender creates. The only constraint is practical: the sender's software must recognize the recipient's address format. Some older wallets and exchange withdrawal systems cannot parse Bech32 or Bech32m addresses, which is why compatibility matters when choosing your receiving format.
How do Legacy addresses work, and when should you still use them?
Legacy addresses are the original Bitcoin address formats, operational since the network launched in 2009. They remain functional because every Bitcoin node supports them, making universal compatibility their primary value. However, they produce the largest transactions and the highest fees among all current address types.
P2PKH addresses (prefix "1")
Pay-to-Public-Key-Hash addresses lock coins to a hash of your public key. Spending requires providing the full public key and a valid signature in the transaction's ScriptSig field. Because the signature data sits in the main transaction body rather than a separate witness structure, P2PKH inputs consume more block space. A typical single-input P2PKH transaction runs approximately 192 bytes compared to roughly 141 virtual bytes for the equivalent native SegWit transaction (source: Bitcoin Optech).
P2SH addresses (prefix "3")
Pay-to-Script-Hash addresses can wrap various script types. A "3" address might be a pure legacy multisig, a nested SegWit output (P2SH-P2WPKH), or another script construction. You cannot determine which script is inside from the address alone. Nested SegWit wraps SegWit spending rules inside a P2SH format for compatibility with systems that recognize "3" addresses but reject "bc1q" addresses. This provides moderate fee savings (roughly 10-25% over pure P2PKH) because SegWit witness discounts apply when the output is spent.
When Legacy formats still make sense
Some exchange withdrawal systems still cannot process Bech32 addresses. Corporate treasury platforms and older payment processors may only support "1" or "3" addresses. If you are importing an old seed phrase, the wallet may default to Legacy derivation paths. In these situations, using Legacy is the correct choice. If you control the receiving side and compatibility is not a constraint, prefer newer formats for lower fees.
How does SegWit reduce transaction fees?
Segregated Witness, activated in August 2017, separates signature (witness) data from the base transaction data. This structural change introduced a weight discount that makes SegWit transactions cheaper to include in blocks. Native SegWit (bc1q) provides the full discount; nested SegWit (3) provides a partial discount.
The weight calculation
Block capacity changed from a 1 MB size limit to a 4 million weight unit (WU) limit. The formula: weight = (base size x 3) + witness size. Since witness data counts at one-quarter the rate of base data, transactions that move signatures into the witness field consume fewer weight units. Miners prioritize transactions by fee-per-weight-unit (sat/vB), so lower weight means lower fees for the same priority level.
Fee savings in practice
Transaction type | Approximate size | Fee at 10 sat/vB | Fee at 50 sat/vB |
|---|---|---|---|
P2PKH (Legacy), 1-in 2-out | ~226 bytes | ~2,260 sats | ~11,300 sats |
P2SH-P2WPKH (Nested SegWit), 1-in 2-out | ~167 vbytes | ~1,670 sats | ~8,350 sats |
P2WPKH (Native SegWit), 1-in 2-out | ~141 vbytes | ~1,410 sats | ~7,050 sats |
P2TR (Taproot), 1-in 2-out | ~152 vbytes | ~1,520 sats | ~7,600 sats |
Native SegWit saves roughly 35-40% on fees compared to Legacy for single-input Bitcoin transactions. These savings compound with multi-input transactions because each additional input benefits from the witness discount.
Bech32 error detection
Beyond fees, SegWit addresses use Bech32 encoding defined in BIP 173. The character set excludes "1," "b," "i," and "o" to prevent visual confusion. A built-in checksum detects up to four character substitutions and flags length changes. This error detection happens locally in your wallet before any transaction is broadcast, catching mistakes before they cost money.
SegWit adoption
As of early 2026, native SegWit outputs account for approximately 80-85% of Bitcoin transactions, making bc1q the dominant address format on the network (source: Transactionfee). Most major exchanges and wallet providers support bc1q addresses for both deposits and withdrawals. From an exchange operator's perspective, the migration to native SegWit has meaningfully reduced withdrawal processing costs across the industry, and the remaining address-format support tickets almost always involve users attempting to withdraw to bc1p addresses on platforms that have not yet added Taproot support.
What does Taproot add beyond SegWit?
Taproot, activated in November 2021 at block 709,632, introduced three connected upgrades: Schnorr signatures (BIP 340), Taproot script structure (BIP 341), and Tapscript (BIP 342). For typical single-signature transactions, Taproot behaves similarly to SegWit. The meaningful differences appear in multi-signature setups, complex spending conditions, and on-chain privacy.
Schnorr signatures and key aggregation
Schnorr signatures replace ECDSA for Taproot outputs. The practical benefit is linearity: multiple signatures can be aggregated into a single signature that validates as if one person signed. A 3-of-5 multisig wallets transaction, which would require three separate signatures with SegWit, can appear on-chain as a single-signature spend with Taproot. This reduces transaction size and makes complex transactions indistinguishable from simple ones when viewed on a block explorer.
MAST (Merkelized Abstract Syntax Trees)
Taproot uses a tree structure where multiple spending conditions are organized as branches. When you spend, you only reveal the branch you actually use. The other conditions remain hidden. A script with ten possible spending paths only reveals one path on-chain, keeping the rest private and the transaction compact.
What typical users notice
For routine single-signature payments, Taproot fees are comparable to native SegWit. Taproot inputs are slightly larger (approximately 57.5 vbytes versus 68 vbytes for SegWit inputs), but Taproot outputs are slightly smaller. The net result for a simple 1-input, 2-output transaction is roughly similar cost. The real savings appear in complex transactions where signature aggregation or MAST eliminates data that would otherwise appear on-chain.
Current adoption and limitations
Taproot transaction share peaked near 40% in 2024 during the Ordinals and inscriptions surge, then settled to roughly 15-25% of transactions by early 2026. Wallet support is broad among modern software (Sparrow, Electrum, Trezor Suite, Ledger Live), but some exchanges still do not support bc1p for deposits or withdrawals. Always verify support before using a Taproot address for an exchange interaction.
Taproot also enables Ordinals, BRC-20 inscriptions, and Runes through its expanded scripting capabilities. These newer Bitcoin applications rely on Taproot's script flexibility to embed data on-chain.
How should you choose your default address type?
Choosing an address type is a compatibility decision first and a fee optimization decision second. The best format is the most advanced one that both your wallet and the sender's system support. For most users in 2026, native SegWit (bc1q) offers the strongest combination of low fees, broad exchange support, and reliable error detection as a default.
Decision framework
Your situation | Recommended address | Why |
|---|---|---|
Wallet and exchange both support bc1p | Taproot (bc1p) | Best privacy for complex spends, comparable fees |
Wallet supports bc1p but exchange does not | Native SegWit (bc1q) | Lowest fees with broadest modern support |
Sender only recognizes "3" addresses | Nested SegWit (3) | Moderate fee savings, legacy-compatible |
Sender only recognizes "1" addresses | Legacy P2PKH (1) | Universal compatibility, highest fees |
Practical recommendation
Native SegWit (bc1q) remains the safest default for most users in 2026. It offers the lowest fees for simple transactions, near-universal exchange support, and strong error detection through Bech32 encoding. Use Taproot when you specifically benefit from its features (multisig privacy, Schnorr aggregation, or script-path flexibility) and your counterparty supports it. Fall back to "3" or "1" addresses only when the sender requires it.
From an operational standpoint, the address type you select for receiving matters more than the type you send from. Your receiving address determines the output type created, which determines the fee you pay when you later spend those coins. Receiving to a native SegWit or Taproot address means cheaper future spends compared to receiving at a Legacy address.
What are the most common mistakes with Bitcoin address types?
Address-type confusion accounts for a significant portion of support requests across exchanges and wallet providers. The most frequent errors involve exchanges rejecting unfamiliar address formats, users mistaking change addresses for theft, and concerns about cross-type compatibility. Nearly all of these situations are recoverable or preventable with basic verification habits applied before each transaction.
"The exchange rejected my address"
The exchange's withdrawal system does not support the address format you provided. Try a different address type from your wallet. Most wallets let you generate addresses in multiple formats. If your wallet only generates bc1p and the exchange rejects it, generate a bc1q or "3" address instead.
"I sent bitcoin to a different address type -- are my funds lost?"
No. Bitcoin transactions between different address types work normally at the protocol level. A send from a Legacy address to a Taproot address completes without issue. The confusion typically arises when someone sends bitcoin to an address on the wrong network entirely (for example, sending to a Litecoin address that also starts with "M" or "3"), which is a network mismatch rather than an address-type problem.
"My wallet shows an address I don't recognize"
This is almost always a change address your wallet generates automatically. Modern wallets create new addresses for change outputs to improve Bitcoin privacy. The address belongs to your wallet even though it looks unfamiliar. Check your wallet's address list to confirm.
Safe address habits
Copy and paste addresses rather than typing them manually. Verify the first four and last four characters after pasting. Use QR codes when available to eliminate transcription errors entirely. For significant amounts, send a small test transaction first and confirm receipt before transferring the full amount. These habits apply regardless of which address type you use and are part of broader security practices for managing bitcoin.
How do address types affect Lightning Network usage?
Lightning Network channels are opened and closed with on-chain transactions, and the address type used for those transactions affects the channel-open fee and the security properties of the funding output. Understanding this connection matters if you use Lightning Network for payments.
Channel funding and address types
Opening a Lightning channel requires creating an on-chain multisig output. SegWit is the minimum requirement for Lightning channels because the Lightning protocol depends on SegWit's fix for transaction malleability (the ability for third parties to alter a transaction's ID before confirmation). Legacy addresses cannot be used for Lightning channel funding. Most Lightning implementations default to native SegWit for channel opens, and some newer implementations support Taproot channels for improved privacy.
Practical impact
If you fund your Lightning wallet from an exchange, the withdrawal address format determines the on-chain fee for getting funds into your Lightning wallet. Withdrawing to a bc1q address costs less than withdrawing to a "3" address. The Lightning payments themselves happen off-chain and are not affected by your on-chain address type.
Frequently asked questions
Is Taproot more secure than SegWit?
Address type does not determine security in a meaningful way for typical users. Security depends on private key management, wallet software integrity, and operational habits like verifying addresses before sending. Both Taproot and SegWit rely on strong cryptographic assumptions. Taproot uses Schnorr signatures while SegWit uses ECDSA, and both are considered secure against current computational capabilities. Choose your address type based on compatibility and fee considerations, not security claims.
Can I convert an existing address from one type to another?
You cannot convert an address itself, but you can send bitcoin from an old address type to a new one. Generate a new address in your preferred format, then send your funds to it. This costs a normal transaction fee. Many users do this when migrating from Legacy to SegWit to benefit from lower fees on future transactions. The process is identical to any other bitcoin transfer.
Why do some wallets generate multiple address types simultaneously?
Wallets that support multiple derivation paths can manage Legacy, SegWit, and Taproot addresses from the same seed phrase. Each address type uses a different derivation path (BIP 44 for Legacy, BIP 84 for native SegWit, BIP 86 for Taproot). Your wallet tracks all of them and displays a combined balance. This gives you flexibility to receive in whatever format the sender supports.
What happens if I send bitcoin to a SegWit address from a Legacy wallet?
The transaction completes normally. Your Legacy wallet creates a SegWit output locked to the recipient's bc1q address. The sender's address type affects the fee the sender pays (Legacy inputs are more expensive), but the recipient receives the bitcoin regardless. The only scenario where this fails is if the sender's wallet software is too outdated to recognize Bech32 addresses at all.
Should I consolidate all my bitcoin into one address type?
Consolidation can make sense if you hold many small UTXOs across different address types and want to reduce future fee costs. Combine them into native SegWit or Taproot outputs during a low-fee period. However, consolidation links all those UTXOs publicly on-chain, which reduces privacy. Only consolidate when the fee savings justify the privacy trade-off and when the UTXOs already share known ownership.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include BIP 141 (Segregated Witness), BIP 173 (Bech32 encoding), BIP 341 (Taproot), and BIP 350 (Bech32m encoding) as published on the Bitcoin BIPs repository (github.com/bitcoin/bips). Address format specifications referenced from learnmeabitcoin.com technical documentation. SegWit and Taproot adoption statistics sourced from transactionfee.info and mempool.space. All technical details independently verified against protocol documentation current as of April 2026.
This article is for informational purposes only and does not constitute financial advice. Cryptocurrency trading involves substantial risk of loss. Past performance does not guarantee future results. Always conduct your own research and consider your financial situation before trading. BloFin does not guarantee the accuracy of third-party data referenced herein.