When someone asks for your Bitcoin address, they mean a string that starts with either 1, 3, bc1q, or bc1p. Those four prefixes correspond to four different address formats — each with different rules, different fee characteristics, and different capabilities. Any modern wallet supports at least three of them. Knowing which format you are handing over is not a technicality; it changes what fees you pay, how much of the sender's fee they save, and what smart-contract features become available.
Legacy: P2PKH (prefix 1)
Legacy addresses — technically Pay-to-Public-Key-Hash — start with a 1. They are the original Bitcoin format, dating to 2009, and they are still supported everywhere. You send a legacy address, someone signs a spend with a private key, and the network confirms it. Simple, ancient, and now expensive.
Legacy addresses carry the highest fee cost per transaction. They pre-date SegWit's witness-data discount, so every byte of the transaction — including large signature data — counts against the block size limit and against the fee. Sending BTC from a legacy address today can cost twice as much as an equivalent SegWit or Taproot transaction, sometimes more when the mempool is busy.
There is no functional reason to receive to a legacy address in a new wallet. The only case is compatibility: some very old exchanges or ATMs still cannot send to bech32 addresses. That gap is closing every year.
Nested SegWit: P2SH-P2WPKH (prefix 3)
Nested SegWit addresses start with 3. They were the compromise format introduced with SegWit in 2017 — technically Pay-to-Script-Hash wrapping a SegWit output. The idea was to give SegWit's benefits (lower fees, malleability fix) to users who had to send from old wallets that only understood the 3-prefix format.
Nested SegWit sits in the middle. Fees are meaningfully lower than legacy but noticeably higher than native SegWit, because the wrapper adds bytes. Nested addresses are still widely used by exchanges as change addresses and default receive addresses, mostly for historical reasons and edge-case compatibility.
Not a bad choice if compatibility matters. Not the best choice if you have a modern wallet.
Native SegWit: P2WPKH (prefix bc1q)
Native SegWit — Pay-to-Witness-Public-Key-Hash — is the format most modern wallets default to. Addresses start with bc1q. Any wallet that says "bech32 support" means this.
Fees are meaningfully lower because the signature data gets a 4x discount in block-weight accounting. Sending from a native SegWit address is typically 20-30% cheaper than legacy for the same transaction, and the receiver gets the same reduction if they later spend those coins. There is no downside for the sender or receiver as long as both sides support bech32, which any wallet updated since 2018 does.
Native SegWit also enables Lightning channels — Lightning uses SegWit outputs under the hood — and better transaction malleability protection, which matters for channel security.
If you are choosing today and do not need Taproot's specific features, this is the sensible default.
Taproot: P2TR (prefix bc1p)
Taproot — Pay-to-Taproot — activated on Bitcoin mainnet in November 2021. Addresses start with bc1p. Taproot combines three long-discussed upgrades — Schnorr signatures, MAST (Merkelized Alternative Script Trees), and TAPROOT itself — into a single new output type.
For simple single-signature spends, Taproot fees are similar to Native SegWit — a few percent cheaper because Schnorr signatures are more compact. The real gains show up with multisig and complex contract spends: a Taproot 3-of-5 multisig can look on-chain like a single-signature spend, meaning it costs the same in fees and reveals nothing about the underlying script. Native SegWit multisig always reveals the full script.
Taproot is also the substrate for Ordinals (BRC-20 tokens are inscribed as Taproot witness data), for BitVM, and for future covenant proposals. Where Bitcoin's smart-contract layer is going, Taproot is the base.
When to send to which
You do not usually choose the recipient's format — they do. But when you receive, you do choose. A few practical rules:
- New wallet, no legacy dependency: default to Taproot if your wallet supports it (most do), Native SegWit otherwise.
- Multisig setup, especially with hardware wallets: Taproot if all devices support it, Native SegWit if any device does not.
- Sending to an older exchange or ATM that rejects bc1: use Nested SegWit as the compatibility bridge, then move funds to a Taproot address once received.
- Long-term cold storage generating fresh addresses: Taproot. The savings compound over dozens of spend events, and the format is the base layer for future upgrades.
Backward compatibility works one direction
A wallet that supports Taproot can send to any of the older formats. A legacy-only wallet cannot send to a bc1p address. That is the entire reason older formats are still around: they are the lowest common denominator that guarantees delivery.
The gap keeps closing. Every major wallet, exchange, and payment processor now supports at least Native SegWit, and Taproot support is standard on modern hardware wallets and mobile apps. Legacy is not going away — the format will be supported forever because coins locked in legacy outputs still need to be spendable — but new receiving activity in legacy is dwindling to nothing.
The one thing to check
Before sending a significant amount to a new address, verify the format. Not just the prefix — verify that your wallet and the recipient's wallet actually support the format the address implies. Sending a substantial amount to a bc1p address only to discover the receiver's exchange does not credit bc1p deposits is a preventable mistake. The bech32 vs bech32m distinction (Native SegWit vs Taproot) has caused this exact class of error, because they look similar and some services support one but not the other.
Modern wallets warn on format mismatches. Trust the warning. Confirm the address type in the sender's wallet UI before broadcasting.
