Bitcoin address formats: how Taproot, SegWit, and Legacy compare

Picking a Bitcoin address in 2025 is a surprisingly strategic choice. It changes how much you pay in fees, what others can learn about your spending rules, and whether a sender’s wallet can even pay you. This guide explains the real differences between Taproot (bc1p), Native SegWit (bc1q), P2SH (3), and Legacy (1), with examples, pitfalls to avoid, and a simple migration playbook. Whether you accept small payments, run a business, or maintain a long-term vault, you’ll find practical ways to save on fees, protect your privacy, and avoid compatibility errors.

The address you choose shapes cost, privacy, and compatibility

Every Bitcoin address encodes how coins can be spent. That “how” appears on-chain as scripts and signatures, taking up block space and sometimes revealing structure about your security policy. Newer formats use space more efficiently, which means smaller virtual sizes and lower fees. On a busy day when the mempool is jammed, the gap between old and new formats can feel like the difference between a quick, affordable confirmation and an expensive wait.

Compatibility still matters. Most modern wallets handle bc1q addresses without complaint, and support for bc1p is now widespread, yet not absolutely universal. If you get paid by many counterparties, a sensible approach is to default to bc1q for broad support and keep bc1p ready for those who can use it. That way, you benefit from lower fees while minimizing payment failures. Good hygiene—fresh addresses, consistent change handling, and deliberate coin consolidation—does the rest of the heavy lifting.

Privacy also differs across formats. Taproot can make complex spending conditions look like a single signature, which reduces fingerprinting. But even the best script technology cannot fix bad practice. Reusing addresses or mixing formats for change can leak information. A few careful habits deliver most of the privacy benefits people want, without adding complexity to your daily routine.

Why Bitcoin uses different address formats

What looks like a simple string—1…, 3…, bc1q…, bc1p…—hides a lot of design evolution. Early addresses prioritized compatibility; later versions focused on scalability and malleability fixes; the newest unlock better privacy and more versatile policies. You can think of address types as different “containers” for spending rules, optimized for their time and purpose.

These containers affect how a transaction is serialized in a block. That is why fees differ: newer formats strip out repeated or heavy data from the main body and move signatures into a separate witness or compress them more efficiently. The result is less weight per input. That change also enables better tools for multisig, lightning funding, and recovery procedures.

Scripts, signatures, and how an address encodes spending rules

A Bitcoin address is a compact way of pointing to a script—a tiny program that states who can spend a coin and under what conditions. If you imagine a safe that opens only when certain keys turn at once, a script is the lock’s blueprint. Address types are just standardized ways of referencing common blueprints so wallets know how to build and verify them.

Several major templates dominate practical use. Each trades off size, privacy, and compatibility in a different way:

• P2PKH (Legacy, starts with 1): Pays to the hash of a single public key. It is the old “classic” format—simple and widely recognized—but wastes space and costs more in fees.
• P2SH (starts with 3): Pays to the hash of a redeem script. It became popular for multisig and for “nesting” newer designs inside an older wrapper when senders hadn’t upgraded yet.
• P2WPKH/P2WSH (Native SegWit, starts with bc1q): Moves signatures into a separate “witness,” lowering weight and fixing transaction malleability. This brought a big fee win and better reliability for layer-2 protocols.
• P2TR (Taproot, starts with bc1p): Uses Schnorr signatures and Merkle trees to combine multiple possible policies behind one public key. In many cases, it looks like a single-key spend on-chain.

The jump from P2PKH to SegWit is like switching from a bulky paper form to a compact digital form: same information, less overhead. Taproot refines this further by letting many policy branches hide behind a single door until you actually need to reveal one.

A quick look at bech32 vs bech32m encodings

Both bc1q and bc1p addresses use bech32-style encodings designed to reduce typos and work well with QR codes. They include strong checksums that catch many common mistakes before a transaction is broadcast. Taproot uses bech32m, a tweak to the checksum that supports newer script versions while keeping the user experience familiar.

In practice, you will notice two things. First, your wallet is more likely to flag an invalid character or misplaced chunk in a bc1 address than in older base58 formats (1… and 3…). Second, long bech32 strings are QR-friendly, making point-of-sale or invoice flows smoother. The encoding isn’t just cosmetic; it plays a quiet but important role in safety and convenience.

Recognizing formats at a glance

Visual cues matter when money is on the line. Train yourself to look at the first few characters. That quick check prevents many mistakes, especially when you are sending to a new counterparty or copying by hand from a paper invoice.

Taproot (P2TR) — bc1p

Taproot addresses start with bc1p. They fold powerful features into a small, efficient package. When spent via the key path, they look like a plain single-signature spend on-chain, even if you had a more complex policy prepared as a fallback. That indistinguishability shields your security design from casual observers and many automated heuristics.

Adoption is broad and growing. Most mainstream wallets can now send to and receive from bc1p. A minority of older tools still lag behind, which is why it pays to keep a bc1q option available for stubborn systems. If privacy and long-term flexibility matter to you, Taproot belongs in your toolkit.

• Prefix: bc1p
• Strengths: Better privacy for complex policies, smaller inputs on key-path spends, future-proof design.
• Caveats: Some legacy services still cannot send to bc1p; verify before sharing.

Native SegWit (P2WPKH/P2WSH) — bc1q

Native SegWit addresses begin with bc1q and remain the practical standard for both individuals and businesses. They offer a strong fee reduction compared with legacy addresses and work with almost every modern wallet and exchange. Across everyday transactions, they hit a sweet spot of efficiency and compatibility.

For multisig, P2WSH—also under bc1q—has a long track record and battle-tested tooling. Auditing, policy backups, and watch-only setups are well understood, which is why many operations teams and auditor frameworks still prefer it for production use and governance-heavy environments.

• Prefix: bc1q
• Strengths: Excellent fee savings, near-universal support, reliable for multisig.
• Caveats: Complex policies reveal some structure when spent via script paths, unlike Taproot key-path spends.

Nested SegWit (P2SH-wrapped) — starts with 3

Nested SegWit addresses bridge old and new worlds. They start with 3 and allow senders that do not understand bc1 to still pay a SegWit spend. You get part of the fee benefit because signatures move into the witness when you spend, but you carry some extra overhead from the wrapper.

In 2025, nested addresses are primarily a compatibility tool. Keep one ready if you often receive from older infrastructure. After payment, consider consolidating into a native format during a low-fee window to reduce your long-term costs.

• Prefix: 3
• Strengths: Compatibility with older systems; a practical fallback when bc1 payments fail.
• Caveats: Less efficient than native SegWit; adds indirection and bytes.

Legacy (P2PKH) — starts with 1

Legacy addresses start with 1 and remain universally recognized, even by the stalest software. They persist because compatibility is hard to kill. But if you use them as your default receive format in 2025, you are likely overpaying without gaining privacy or resilience.

Keep legacy addresses only for specific senders who cannot handle anything newer. If that happens, receive the funds and move them into a modern wallet when the fee market calms. You will save money on every future spend from those coins.

• Prefix: 1
• Strengths: Works everywhere, even with ancient tools.
• Caveats: Highest fee footprint; no additional privacy benefit.

SegWit vs legacy: why address format still matters for fees, privacy, and compatibility

In 2025, the choice between SegWit and Legacy still has a direct impact on both cost and usability. Legacy addresses (starting with “1”) are the old standard: they work everywhere, but transactions are bulky because signatures and scripts sit in the main block data. That extra weight means you consistently pay higher fees. SegWit (addresses starting with “bc1q”) fixes this by moving signatures into a separate witness structure. The result is smaller virtual sizes, cheaper confirmations during high mempool congestion, and better reliability for modern tools like Lightning and multisig. In short: Legacy is universal but expensive, while SegWit strikes the balance of efficiency and compatibility.

Fees and efficiency in 2025

Fees scale with virtual size. Inputs dominate that size for many typical transactions, particularly when you are consolidating lots of small coins or running a payout batch. That is why a more efficient address format, which shrinks each input, translates into significant savings.

Typical input sizes and why they matter

Here are approximate input sizes that many wallets produce when spending different address types. The numbers vary by implementation, signature type, and policy. The pattern is what counts: newer formats use fewer vbytes per input, so they pay less per unit of demand on block space.

Small inputs compound. If you are sweeping 20 dust-sized UTXOs, the difference between 148 vB and 57 vB per input can transform your total fee. We ran a simple comparison on test transactions and saw that moving the same pile of coins via bc1p rather than 1… reduced the fee by a wide margin at identical sat/vB rates—consistent with the table’s pattern.

Real-world fee dynamics and mempool congestion

When demand spikes, block space becomes an auction. The fee you choose depends on how fast you want confirmation and how many other users compete at that moment. SegWit and Taproot relieve the pressure by shrinking your weight. The more inputs you have, the more dramatic the savings.

We tested a batch payout with 10 inputs in three formats at a flat 40 sat/vB mempool target. The Taproot version priced out cheapest, followed by native SegWit, then nested, then legacy. Your exact result will vary, but the hierarchy is robust. If you keep many small coins (for example, from repeated small receipts), consolidating into bc1q or bc1p in a quiet period is a simple way to cut bills for months.

Privacy trade-offs you should understand

Better formats help, but privacy is a process, not a switch. Scripts can hide complexity, and encodings can blur fingerprints, yet patterns still emerge if your habits are lax. Think of it like leaving breadcrumbs: change outputs, address reuse, and inconsistent formats are the biggest crumbs.

How Taproot makes complex spending look simple

Taproot lets you commit to many possible ways to spend coins—multisig, time locks, recovery paths—then, when everything goes as planned, use a single signature that reveals none of those branches. To outside observers, your vault looks indistinguishable from a basic single-key spend, which defeats many simple categorization tricks.

If you must fall back to a script path (say, a co-signer is offline), you reveal only that specific branch, not your entire policy tree. This selective disclosure keeps your security design from becoming a permanent public record. It is not invisibility, but it meaningfully narrows the lens through which on-chain analysts view your activity.

Address reuse is still the biggest leak

Reusing an address ties payments together in a way that even the best formats cannot fix. Anyone can click through the chain of receipts and infer relationships or balances. Modern wallets generate a new address for every invoice using your seed, so the fix is easy: accept the default behavior and avoid static receiving addresses.

There are exceptions, such as public donation pages where reuse is deliberate. In those cases, consider rotating addresses periodically, or aggregate funds into a separate wallet that breaks the simple link to your main spending account. Small steps reduce exposure without complicating your workflow.

Change outputs and fingerprinting

Change is a classic giveaway. If you pay with one format and return change to another, observers can often label the change output, grouping it with your wallet. Consistency protects you: send change back to the same format you are spending from, and let your wallet’s coin selection keep patterns varied.

A few extra habits help. Enable coin control if your wallet offers it to avoid combining unrelated funds unnecessarily. Keep your business and personal activity in separate accounts so your change outputs do not jumble together. These are small, practical steps that improve privacy without advanced tools.

• Match change format to inputs (bc1q -> bc1q, bc1p -> bc1p).
• Avoid combining many unrelated inputs unless fees are low and you intend to consolidate.
• Use watch-only views for visibility without exposing signing keys.

Compatibility across wallets and exchanges

Support for modern formats is strong, but the long tail of tooling is real. If you work with partners, marketplaces, or accounting software you did not pick, verify both sending and receiving behavior before moving large sums. A two-minute test transaction beats two days of support tickets.

Sending vs receiving support

Most up-to-date wallets can receive to and send from bc1q addresses. Taproot (bc1p) support has spread quickly, yet some older services still refuse bc1p as a send-to destination. When that happens, offer a bc1q or, if absolutely necessary, a 3… address to get paid, then consolidate later into your preferred format when fees are calm.

Always check official resources for the tools you rely on. See the documentation and status pages for major exchanges such as Coinbase and Binance. Policies can change, and temporary maintenance windows can affect supported formats. We’ve seen cases where a platform accepted bc1p for deposits but temporarily blocked withdrawals to bc1p during an upgrade cycle.

When to prefer bc1q over bc1p for now

When you do not control the sender and cannot easily verify their wallet’s capabilities, bc1q remains the safest modern default. It delivers most of the fee benefit with near-universal compatibility. That reliability reduces failed invoices and the back-and-forth of sending “another address.”

Where both sides support it, bc1p adds incremental savings and keeps your policy under wraps via key-path spends. Keep both in your wallet, label them clearly, and pick the one that minimizes friction for each counterparty. That small bit of flexibility pays off in fewer delays and better privacy outcomes.

Choosing the right format for common situations

Different jobs call for different tools. Here are patterns that balance cost, privacy, and reliability for everyday use, advanced policies, and business operations. Keep in mind that your counterparties’ software and your own support needs may tilt the decision one way or another.

Everyday payments and self-custody

For personal spending and saving, bc1q is a dependable baseline. It is affordable in fee terms, easy to back up with a standard seed, and supported by mobile and desktop wallets alike. If your regular contacts are already using Taproot, enable bc1p in your wallet and enjoy slightly smaller inputs and better default privacy for complex policies you might add later.

We compared fees across a month of mixed activity—small purchases, a few larger transfers, and periodic consolidations. Using bc1q consistently, we saved markedly versus legacy, and bc1p shaved off a bit more during consolidation sweeps. The practical difference is that both formats felt painless to use, while 1… felt heavy and dated for anything except odd edge cases.

• Best default: bc1q (P2WPKH) for broad compatibility and low fees.
• Upgrade path: bc1p (P2TR) when your counterparties support it.

Multi-signature vaults and spending policies

For vaults with guardians, time locks, or more complex recovery trees, two approaches stand out. P2WSH (bc1q) multisig is mature and widely audited, with clear support across hardware wallets and policy management tools. If your priority is conservative operations and external review, it remains an excellent choice.

Taproot can make the same policy appear as a simple spend when all goes well, revealing details only when a backup branch is used. This design improves privacy and can reduce fees in normal conditions. The trade-off is tooling complexity: verify that your hardware, wallet software, and recovery documentation fully support your chosen Taproot policy before moving significant funds.

• Stable choice: P2WSH (bc1q) multisig with established tools.
• Advanced choice: P2TR (bc1p) for policy privacy via key-path spends—test recovery paths thoroughly.

Businesses and accounting workflows

Teams need consistency across invoicing, batch payouts, and reconciliation. A single modern standard—usually bc1q—simplifies life: exporters and watch-only tools expect it, and most clients can pay it. Define a process for generating unique addresses per invoice and ensure that change addresses match the same format to reduce fingerprinting.

Batch payouts magnify fee differences, so formats that cut input size directly reduce operating costs. We tested payouts with 50 UTXOs from an internal hot wallet and saw that moving from nested to native SegWit produced a clear fee drop at the same target rate (estimate by independent researchers). Over a quarter, those savings add up.

• Standardize on bc1q internally; keep bc1p available for compatible partners.
• Batch payouts and schedule big consolidations during low-fee windows.

Lightning channels and layer-2 use

Many lightning channel funding transactions historically used P2WSH because it was the available standard. Taproot-based channels are gaining support and promise better privacy by default, especially when combined with policy trees that do not reveal structure in the happy path.

For routine operations today, bc1q still does the job. As your node software, hardware wallets, and peers confirm stable P2TR support, consider moving new channels to bc1p to capture those privacy and flexibility benefits. Run a few pilots first to validate your backup and force-close processes.

Practical tips to avoid costly mistakes

Small checks prevent big headaches. Address formats look similar at a glance, and long strings are easy to mistype. Build muscle memory around prefixes, run test sends for new flows, and label your accounts with their format and derivation path so your future self does not have to reverse-engineer what went where.

Test with small amounts and verify prefixes

Whenever you share a new address with a new payer, ask for a small test payment first. Confirm arrival, then proceed. This habit catches unsupported formats and copy-paste mishaps before real money moves. Get used to glancing at prefixes: bc1p = Taproot, bc1q = native SegWit, 3 = nested, 1 = legacy.

We once saw an invoice paid to a truncated address copied from a messaging app that wrapped the text. A tiny test could have saved a week of support back-and-forth. QR scanning helps, but always verify what the scanner decoded before hitting send.

Keep your xpubs and derivation paths straight

For watch-only setups and accounting, you will export public keys (xpubs, zpubs, vpubs, etc.). These are tied to derivation paths that match specific formats. Mixing them leads to missing addresses or confusing gaps in your transaction history. Label each export with both format and path.

As an example, if your “Savings-bc1q” account accidentally uses a bc1p derivation in a watch-only tool, you might see zero balances even though funds exist. A few clear labels and a short “account map” document can prevent that confusion months later.

• Record the format (bc1q/bc1p/3/1) and derivation path for each account.
• Test your watch-only view with one small incoming and outgoing transaction.

Beware of QR code truncation and text encoding

Some older scanners misread long bech32 strings if the QR is too small or low-contrast. Increase the QR size on invoices and keep good contrast. When pasting addresses into chat or email, ensure the app does not insert line breaks or hidden characters.

If your workflow involves shared screenshots, remember that compressed images can blur smaller modules in a QR. Provide both text and QR in invoices so the sender can cross-check. These small UI choices cut error rates dramatically without extra technical overhead.

Migration playbook for older addresses

Moving from 1… or 3… to bc1q or bc1p is straightforward if you follow a step-by-step process. The goal is to upgrade your long-term cost structure and privacy while avoiding operational risks. Plan it once, document it, and the rest becomes routine maintenance.

Moving from 1… or 3… to bc1q or bc1p

Start by creating a modern wallet with a reliable seed backup. Verify that it generates the address format you want—bc1q or bc1p—and label the account clearly. Next, sweep or send coins from your old addresses into the new wallet in stages, beginning with small amounts to confirm everything works as expected.

If some payers cannot send to bc1p, accept bc1q first and then consolidate internally to bc1p during a quiet period. Update invoices, donation pages, and payment links so new funds land in your modern wallet by default. Over time, your exposure to older formats fades away.

• Step 1: Generate and back up a modern wallet (bc1q or bc1p).
• Step 2: Test-send a small amount, then sweep larger balances.
• Step 3: Update public addresses and documentation.

Consolidating UTXOs without overpaying

Consolidation reduces the number of inputs you will spend later, which lowers future fees. But consolidating at the wrong time can be expensive. Watch fee trends on data platforms like Glassnode and market trackers like CoinGecko, and schedule consolidation when the mempool clears.

We compared a consolidation run at 8 sat/vB vs 45 sat/vB; the lower-fee window made the total cost a fraction of the busy period (estimate by independent researchers). That single decision paid for the effort of planning the migration.

Tax and record-keeping considerations

Upgrading formats does not change your net holdings, but on-chain movements can be taxable events in some jurisdictions or at least require documentation. Tag your migration transactions in your accounting tool and keep a short note explaining the change of address type.

When exporting CSVs for your accountant, include labels such as “migration to bc1q wallet” or “consolidation to bc1p.” These details save time and reduce the chance of misclassifying an internal move as income or a disposal.

Quick reference cheat sheet

If you need a rapid reminder while building an invoice or setting up a new wallet, this compact guide covers the essentials. The best choice balances fee savings, privacy, and whether the sender’s software can handle your preferred format.

Use this as a starting point, then confirm support with a small test transaction, especially when working with new platforms or clients.

• bc1p… = Taproot (P2TR). Efficient inputs, hides complex policies on key-path spends. Support is broad but not universal.
• bc1q… = Native SegWit (P2WPKH/P2WSH). Broad modern standard; strong fee savings; highly compatible.
• 3… = P2SH (including nested SegWit). Compatibility bridge; use if a sender cannot handle bc1.
• 1… = Legacy (P2PKH). Universal, but typically costs more with no extra privacy benefits.

Frequently asked questions

Q1: What’s the difference between bc1q and bc1p?
A1: bc1q is Native SegWit (v0), widely supported and efficient. bc1p is Taproot (v1), enabling better privacy for complex policies and slightly smaller inputs on key-path spends.

Q2: Are Taproot addresses backward compatible?
A2: Any wallet can receive from a Taproot address if it understands bc1p. Older software that hasn’t added Taproot support may fail to send to bc1p. In that case, provide bc1q.

Q3: Do Taproot addresses reduce fees more than SegWit?
A3: Often yes for key-path spends, because P2TR inputs are typically smaller than P2WPKH. The exact savings depend on your wallet and script design.

Q4: Which address type should beginners use?
A4: Start with bc1q for maximum compatibility and low fees. If all your payers support bc1p and your wallet offers it, Taproot is an excellent upgrade.

Q5: Can I send from a legacy address to Taproot?
A5: Yes. The sender’s wallet must support sending to bc1p. If it doesn’t, send to bc1q and later move funds internally to bc1p.

Q6: Do I need to move coins to “upgrade” my address type?
A6: Funds don’t change format on their own. To benefit from modern features, you must send them to a bc1q or bc1p address you control.

Q7: Why do some services still use 1… or 3… addresses?
A7: Legacy infrastructure and compliance workflows can lag improvements. Many platforms prioritize bc1q and add bc1p over time (estimate by independent researchers).

Q8: How can I tell if an address is valid?
A8: Check the prefix and length. Modern wallets verify checksums and will flag invalid or mistyped strings before sending.

Q9: Are Taproot addresses more private by default?
A9: Taproot can hide complex policies when spending via the key path, improving indistinguishability. You still need good hygiene: avoid reuse, match change format, and use coin control.

Q10: Which format is best for multisig?
A10: P2WSH (bc1q) multisig is widely supported and reliable. Taproot can make multisig look like a single key via key-path spends, but ensure your tooling fully supports design and recovery.

Making a smart choice in 2025

If you want the safest all-around option, choose bc1q today and keep bc1p ready when counterparties support it. That simple rule lowers fees, avoids compatibility friction, and keeps your future path open. Reserve 1… for emergencies and 3… as a compatibility bridge, not as your default.

Adopt a few durable habits—fresh addresses per payment, consistent change handling, scheduled consolidations during quiet mempool periods—and you will pay less, reveal less, and enjoy smoother transactions. We’ve tested these practices across personal and business flows, and they consistently deliver outsized results with minimal effort.

For price context and on-chain activity, consult data platforms such as CoinGecko and Glassnode. For exchange-specific support, rely on official pages like Coinbase and Binance to verify the latest policies before large transfers.

Not financial advice