Bitcoin Address Types Explained: Legacy vs. SegWit vs. Taproot (1 vs 3 vs bc1)

 

The prefix on a Bitcoin address tells you which generation of the technology it belongs to and how much extra or less you will pay in fees for using it. Four common formats coexist on mainnet today: legacy addresses starting with 1, nested SegWit addresses starting with 3, native SegWit addresses starting with bc1q, and Taproot addresses starting with bc1p.

 

Only three differences matter between them: how much block space the same transfer occupies, which wallets and platforms can send to it, and how much your spending conditions reveal on chain. All four formats control the same bitcoin on the same chain, so switching address type does not turn your coins into a different asset.

 

The source of the fee difference is the SegWit upgrade activated in 2017. It moved signature data into the transaction's witness section, and witness data counts at one quarter weight when block occupancy is calculated, so the same transfer occupies fewer virtual bytes under the newer formats. For a typical single-input, two-output transaction, legacy runs roughly 226 virtual bytes, nested SegWit roughly 166, native SegWit roughly 141, and Taproot roughly 111.

 

The gap only becomes meaningful during congestion. Per mempool.space, high, medium and low priority fee rates all currently sit at 1 sat/vB, where the per-transaction difference between legacy and Taproot is under ten cents. In a 200 sat/vB congested environment, with bitcoin near $81,397, that gap widens to roughly $18.70.

 

 

 

The prefix identifies the format. A leading 1 means legacy, 3 means nested SegWit or a multisig script, bc1q means native SegWit, and bc1p means Taproot.

 

Space occupied falls in sequence. A single-input, two-output transaction runs roughly 226, 166, 141 and 111 virtual bytes respectively, saving roughly 26%, 38% and 51% against legacy.

 

Compatibility runs inversely to fee efficiency. Legacy and 3-prefixed addresses are accepted almost everywhere, bc1q is widely but not universally supported, and bc1p has the narrowest support.

 

Privacy differences concentrate in Taproot. All Taproot outputs look identical on chain regardless of whether the spend used a single signature or a complex script.

 

The constraint sits with the sender, not the receiver. Whether you can receive a given format depends on whether the sending party's software can construct that output type.

 

One seed phrase derives four sets of addresses. Restoring a seed in a wallet supporting only one derivation path may leave balances at other address types invisible.

 

 

Listing the encoding alongside the length allows a first check before pasting any address.

 

 

Several easily confused details deserve explanation.

 

A 3-prefixed address carries two possible meanings. It was originally a script hash address used for multisig and other script-based arrangements, and after SegWit activated, wrapping a SegWit output inside a script hash produced the nested SegWit address, which looks identical to an ordinary 3-prefixed address. The address alone therefore cannot tell you whether a 3-prefixed destination is multisig or nested SegWit.

 

A bc1q address comes in two lengths. The 42-character form is a single-public-key native SegWit address, while the 62-character form is a script-type SegWit address more common in multisig and contract arrangements.

 

bc1q and bc1p use different checksum algorithms. Bech32 was originally defined by BIP 173 for witness version 0, a flaw was later found in its checksum at certain lengths, and BIP 350 defined Bech32m for witness version 1 and later, which is Taproot. That difference is invisible to ordinary users but it is the direct reason some older wallets recognise bc1q while failing on bc1p.

 

Encoding also affects error tolerance. Base58 deliberately excludes the easily confused characters 0, O, I and l but provides no error correction, while the Bech32 family uses all lowercase with a stronger checksum capable of detecting multiple input errors and indicating where they occurred, which is why the newer formats are longer yet harder to mistype.

 

 

Understanding the fee difference requires understanding how block capacity is calculated, a point widely misunderstood.

 

Bitcoin's block limit is not measured directly in bytes but in weight units, capped at 4 million. The key is that two classes of data carry different weight: non-witness data counts at 4 weight units per byte while witness data counts at 1 weight unit per byte. Dividing weight by four gives virtual bytes, so block capacity amounts to 1 million virtual bytes.

 

The effect of that rule is a 75% discount on witness data. And signatures happen to be the largest component of an ordinary transfer, so moving them into the witness section under SegWit substantially reduced the virtual byte count for the same transfer.

 

Taproot's further compression comes from a change in signature scheme. It uses Schnorr signatures, where an individual signature is shorter than under the previous elliptic curve digital signature algorithm while the public key representation is also more compact, saving additional space within the witness section.

 

Comparing all four formats on the same standard transaction makes the difference concrete. The following are common estimates for a single-input, two-output transaction, with actual size varying by input and output count.

 

 

Worth noting is that these are estimates rather than fixed values. Actual transaction size depends on the number of inputs, the number of outputs and the combination of output types, and multi-input transactions typically save a higher proportion than single-input ones because each input carries its own signature.

 

 

Converting virtual bytes into currency is what determines when this difference deserves attention.

 

The table below takes a single-input, two-output transaction, converts at bitcoin near $81,397, and uses three fee rates corresponding to the current idle state, moderate congestion and severe congestion. The figures are our calculations.

 

 

The practical conclusion from that table is straightforward: during idle periods the fee difference from address type is negligible, while during congestion it scales up to a meaningful amount. Per current mempool.space data, high, medium and low priority rates all sit at 1 sat/vB with roughly 54,000 unconfirmed transactions, which is an idle state.

 

Two supplementary points deserve attention. First, fees are calculated on a transaction's virtual bytes rather than on the amount transferred, so sending $100 costs essentially the same as sending $100,000, which also means fees represent a very high proportion of small transfers during congestion. Second, the recipient's address type also affects cost, because the output type determines the size of the output portion, and both Taproot and native SegWit outputs are smaller than legacy outputs.

 

For bitcoin's current price and market data, see the BTC price page.

 

 

This is the most practical consideration when choosing an address type, and its logic is often inverted.

 

The key principle is that the constraint sits with the sender rather than the receiver. Whether you can receive a given format depends on whether the sending party's software can construct that output type, while whether your own wallet can send to a format depends on your wallet. When choosing a receiving address type, what actually matters is what the platforms and wallets that will send to you support.

 

Support runs in roughly the following tiers. Legacy and 3-prefixed addresses have the broadest support, with virtually every piece of Bitcoin software ever written able to send to them. Native SegWit addresses starting with bc1q became broadly supported after 2018 and all mainstream exchanges and wallets can now send to them, though a few long-unmaintained services may still reject them. Taproot addresses starting with bc1p have the narrowest support, since they require Bech32m encoding, and some platforms still cannot send to them.

 

That is precisely why nested SegWit addresses exist. They wrap a SegWit output inside a script hash so that to a sender they look identical to an ordinary 3-prefixed address, capturing part of the fee saving while retaining maximum compatibility. The trade-off is a saving of only around 26% against the 38% available from the native format.

 

Adoption data provides a reference, though its precision needs noting. Per Spark Money's tracker, roughly 85% to 90% of transactions spend at least one SegWit input, and by address type the estimates put native SegWit at roughly 60% to 70%, Taproot at roughly 15% to 20%, legacy at roughly 5% to 10% and script hash at roughly 5% to 8%. That page states these are estimates fluctuating daily, and figures differ between sources, so they should be read as orders of magnitude rather than precise data.

 

One further caution applies to interpreting Taproot's share. Its historical peaks correlate with inscription-related on-chain activity, making the share volatile, so changes in it should not be read directly as ordinary user migration progress.

 

Users buying bitcoin for the first time and choosing a withdrawal address type may find the deposit and withdrawal walkthroughs useful in our complete beginner's guide to buying bitcoin and how to buy BTC.

 

 

Privacy is the least intuitive of the four differences yet the most worth understanding.

 

Legacy and SegWit addresses differ in no essential way on privacy. Both reveal their complete unlocking conditions when spent, so a multisig spend is clearly identifiable as multisig on chain, with the number of participating public keys and the threshold exposed alongside it.

 

Taproot's improvement lies in hiding the spending path. It allows an output two spending paths: a key path signed directly with a single public key, and a script path satisfying some script condition. Both paths use the same output form on chain, so an outside observer cannot tell from the output itself whether a simple single signature or a complex multi-condition script sits behind the address. Only the path actually used is revealed when spending, while unused script branches never appear on chain at all.

 

The second improvement from Schnorr signatures is key aggregation. Multiple participants can aggregate their public keys into one and produce a single aggregate signature, so a spend under multiparty control can look identical on chain to an ordinary single-signature spend. Using multisig therefore no longer necessarily reveals itself as multisig.

 

But one counter-effect needs stating. Using a rare address format itself narrows the range of who you might be, because it reveals what kind of wallet or service you use. Under the current adoption structure, legacy addresses now stand out, since the proportion using them has fallen to a low level. From a privacy standpoint, using a widely adopted mainstream format is therefore generally better than using a rare one, which aligns with the fee consideration.

 

One final point needs clarity: all of these privacy improvements affect only how much of the spending condition is disclosed and do not change the basic fact that Bitcoin transactions are publicly auditable on chain. The flow of funds between addresses is transparent under every format.

 

 

Reducing the judgement to a few rules is more practical than remembering every technical detail.

 

The default choice is native SegWit, the bc1q format. Its fees run roughly 38% below legacy while support is essentially universal among mainstream platforms, balancing cost against availability.

 

The condition for choosing Taproot is confirming the sender can send to it. It carries the lowest fees and the best privacy for complex spending conditions, but if you need to withdraw from a platform lacking Bech32m support, the address cannot be used.

 

The condition for choosing nested SegWit is that the counterparty can only send to 3-prefixed addresses. It sacrifices part of the saving for maximum compatibility, making it the only workable compromise when facing older systems.

 

There is only one condition for choosing legacy: the counterparty cannot send to anything else. It carries the highest fees, with the extra cost most visible during congestion.

 

Three misconceptions warrant specific explanation.

 

The first holds that different formats correspond to different bitcoin. All four formats control the same asset on the same chain, with no bridging or conversion involved. Address format is simply a different encoding of the spending condition.

 

The second is the one most likely to cause real loss and the most frequently encountered: one seed phrase derives four mutually distinct sets of addresses. By common convention, legacy uses the m/44'/0'/0' path, nested SegWit uses m/49'/0'/0', native SegWit uses m/84'/0'/0' and Taproot uses m/86'/0'/0'. Restoring a seed in a wallet that supports only one of those paths shows only the balance under that path, leaving funds at other address types invisible. This is not lost money but a wallet failing to scan the relevant path, resolved by switching to a wallet supporting multiple paths or adding the derivation path manually. What many users describe as coins disappearing comes down to exactly this.

 

The third overlooks the case rule. Bech32-family addresses must be entirely lowercase or entirely uppercase, with mixed case invalid. Some systems display bc1 addresses in uppercase, which is legitimate, but a copy that produces mixed case will fail the checksum. Base58 addresses, by contrast, are case-sensitive and must be reproduced exactly.

 

One final practical reminder is unrelated to address format but equally important: whatever format you use, verify which network an address belongs to before transferring. A Bitcoin mainnet address is not interchangeable with addresses for similarly named assets on other networks, and transfers to the wrong network are usually unrecoverable.

 

Check live BTC/USDT pricing and order book depth on MEXC. A BTC activity page is also available for reference, and participants should read the applicable rules themselves.

 

 

For James Mitchell, discussion of address types has long been dominated by fee savings percentages, which happens to be the least important of the four differences. At the current 1 sat/vB, the per-transaction gap between legacy and Taproot runs under ten cents, and even in a 200 sat/vB congested environment it is only around $18.70. For most users that amount is insufficient grounds for a decision, while compatibility and seed restoration genuinely deserve attention, because the consequence of getting those wrong is not paying a few dollars extra but being unable to receive funds or unable to see a balance.

 

The directionality of compatibility is frequently inverted and bears repeating. The constraint sits with the sender rather than the receiver: what format you can receive depends on the software capability of whoever sends to you. When choosing a receiving address, the correct approach therefore starts by confirming what the source of funds supports rather than by picking the cheapest format. An older system that can only send to 3-prefixed addresses will not become usable because you prefer bc1p.

 

Taproot's real value, in my view, lies not in fees but in hiding spending conditions. All Taproot outputs look identical on chain whether a single signature or a complex script sits behind them, and unused script branches never reach the chain at all, while Schnorr key aggregation makes a spend under multiparty control indistinguishable from an ordinary single-signature spend. That property matters far more to institutional custody and multiparty arrangements than saving half the block space, though it does not change the basic fact that fund flows remain publicly auditable on chain.

 

On adoption data, I would take the order of magnitude and ignore the precision. Public trackers show roughly 85% to 90% of transactions spending at least one SegWit input, with native SegWit dominant and Taproot at roughly 15% to 20%. But figures differ between sources, and Taproot's historical peaks correlate with inscription activity, so changes in its share cannot be read directly as user migration progress. Only one conclusion is meaningful: SegWit has become the de facto standard while the legacy share has fallen to a low level.

 

For ordinary users my advice reduces to three sentences. Default to bc1q, which balances cost against compatibility best. Use bc1p only after confirming the sender supports it, rather than risking an unreceivable transfer to save a few cents. And record which derivation path or wallet type you used alongside your seed phrase, because the value of that one habit on the day you restore a wallet will far exceed every fee you have ever saved.

 

 

 

By the prefix. A leading 1 means a legacy address at 26 to 35 characters. A leading 3 means a script hash address, which may be multisig or nested SegWit, at 34 characters. A leading bc1q means native SegWit, where 42 characters is the single-public-key form and 62 characters the script form. A leading bc1p means Taproot at 62 characters. All bc1 formats are entirely lowercase.

 

 

Taproot. For a single-input, two-output transaction, legacy runs roughly 226 virtual bytes, nested SegWit roughly 166, native SegWit roughly 141 and Taproot roughly 111, saving roughly 26%, 38% and 51% against legacy. The actual amount depends on prevailing fee rates, with the legacy-to-Taproot gap under ten cents at an idle 1 sat/vB and roughly $18.70 at a congested 200 sat/vB with bitcoin near $81,397.

 

 

Because of different encoding standards. bc1q uses Bech32 as defined by BIP 173 while bc1p uses Bech32m as defined by BIP 350, the latter designed for witness version 1 and later. A platform not updated to support Bech32m cannot construct a Taproot output and therefore cannot send to a bc1p address. That limitation sits with the sender rather than your wallet, so the solution is using a format the sender supports.

 

 

No. All four formats control the same bitcoin on the same chain, with no bridging or conversion involved. You can use addresses of multiple formats simultaneously, and they can all derive from the same seed phrase. But note that different types correspond to different derivation paths, so when changing wallets, balances at other address types may not display if the new wallet supports only some paths.

 

 

The most common cause is a derivation path mismatch. By common convention, legacy uses m/44'/0'/0', nested SegWit uses m/49'/0'/0', native SegWit uses m/84'/0'/0' and Taproot uses m/86'/0'/0'. If the new wallet scans only one of those paths, funds under the others will not display. This is not lost money, and you can try a wallet supporting multiple paths or add the relevant derivation path manually within the wallet.

 

 

Hiding the spending condition. All Taproot outputs look identical on chain, so an outside observer cannot tell from the output whether a single signature or a complex script sits behind it, and only the path actually used is revealed when spending while unused script branches never reach the chain. Combined with Schnorr key aggregation, a spend under multiparty control can be indistinguishable from an ordinary single-signature spend. None of this changes the basic transparency of fund flows between addresses.

 

 

Default to native SegWit, the bc1q format, which balances fees against compatibility best. If the sender supports Bech32m, Taproot offers lower fees and better script privacy. If the counterparty can only send to 3-prefixed addresses, use nested SegWit. Use the 1-prefixed legacy format only when the counterparty cannot send to anything else, since it carries the highest fees.

 

 

The information above is provided for general technical information and explanation only and does not constitute investment advice, financial advice, legal advice, tax advice or a recommendation to trade, nor does it constitute a technical guarantee for any wallet, software or procedure. Digital asset prices can fluctuate sharply and past performance does not guarantee future results. The transaction size estimates, fee conversions, adoption data and asset prices cited here come from publicly available information at the time of publication or from our own calculations on public data, actual transaction size depends on the number and type of inputs and outputs, actual fees depend on network conditions at the time of sending, and adoption figures are estimates from different sources that diverge from one another and serve only as orders of magnitude. The derivation paths referenced are common conventions and individual wallet implementations may differ, so a wallet's official documentation should be consulted before restoring. On-chain transfers are irreversible, transfers to a wrong address or wrong network are usually unrecoverable, and addresses and networks should be verified independently before acting. The content and rules of any activity page referenced are governed by that page's official terms, which should be read before participating. Readers should conduct their own research and verify official information before making any decision or executing any on-chain action, consulting a qualified professional where appropriate. The MEXC Crypto Pulse team accepts no liability for any direct or indirect loss arising from the use of this information.

 

 

James Mitchell specializes in technical analysis, market trends, and trading strategies for both Bitcoin and altcoins. Based in London, he has over 10 years of experience in financial markets. Before joining MEXC Learn, James worked as a senior analyst at a leading European investment firm, where he developed expertise in risk management and quantitative trading. His transition to cryptocurrency markets began in 2017, and he has since become recognized for his data-driven approach. He holds a Master's degree in Financial Economics from the London School of Economics. His analytical approach combines traditional technical analysis with on-chain metrics to provide readers with actionable insights.

 

Areas of Expertise: Technical Analysis, Market Trends and Cycles, Trading Strategies, Bitcoin and Altcoin Analysis, Risk Management.

 

 

 

Want the fastest access to MEXC's latest updates? Join our official Telegram group now!

MEXC Platform: Download App | Zero Fee Trading | Buy USDT Now

Join MEXC Community: X (Twitter) | Telegram | Discord

Get Insights: MEXC Learn | Terms of Service | MEXC Blog | MEXC News

Account Verification: Understand KYC | How to Complete KYC

External Content Platforms: Substack | Medium | Paragraph | LinkedIn | X(News)