Bitcoin address types explained: Legacy, SegWit, and Taproot

Bitcoin address types explained: Bitcoin address types are the different formats a valid Bitcoin receiving address can take, each produced by a distinct script standard and encoding scheme. Four main formats exist on the network today: Legacy (P2PKH), Nested SegWit (P2SH), Native SegWit (P2WPKH), and Taproot (P2TR). They differ in how they lock and unlock funds, how much block space they consume, what privacy properties they carry, and which wallets and exchanges accept them. Understanding the distinctions matters for anyone who moves bitcoin regularly, manages a self-custody wallet, or builds software that interacts with the Bitcoin protocol.

What is a Bitcoin address?

A Bitcoin address is a compact, human-readable string that represents a destination for funds. Under the surface, it encodes a locking script — a set of cryptographic conditions that must be satisfied before the coins can be spent. The address format determines how that script is structured, encoded, and communicated between sender and receiver.

Addresses do not store bitcoin directly. The blockchain records unspent outputs locked to specific script conditions; an address is simply a shorthand for one of those conditions. When a sender broadcasts a transaction to your address, the network locks new outputs against your script. When you spend, you provide the matching cryptographic proof — a signature, a public key, or a more complex condition — and the script releases the funds.

How an address is generated

Every Bitcoin address derives from a private key through a defined sequence:

1. A private key is generated (a 256-bit random number).
2. Elliptic curve multiplication produces the corresponding public key.
3. The public key is hashed — first with SHA-256, then with RIPEMD-160 — to produce a 20-byte hash.
4. A version byte and checksum are added, then the result is encoded in the format defined by the address type (Base58Check for Legacy and P2SH; Bech32 or Bech32m for SegWit and Taproot).

The address format itself is the visible layer that distinguishes one type from another. It tells the sender’s wallet which script template to use when constructing the locking output.

The four main bitcoin address types

Legacy addresses (P2PKH) — starting with “1”

Pay-to-Public-Key-Hash (P2PKH) is the original Bitcoin address format, present since the genesis block in January 2009. A Legacy address locks funds to the hash of the recipient’s public key. To spend, the holder must present the full public key and a valid ECDSA signature.

Legacy addresses use Base58Check encoding, which produces strings of 25–34 characters starting with the digit 1. The character set excludes visually ambiguous characters (0, O, I, l) to reduce transcription errors.

Characteristics:

• Prefix: 1
• Encoding: Base58Check
• Script type: P2PKH
• Transaction size: largest of the four formats
• Fee efficiency: lowest — more bytes consumed per input

Legacy transactions carry the full signature in the main transaction body, consuming more block space per input. On networks with limited block capacity, this translates directly to higher fees. Legacy addresses remain universally supported by every wallet and exchange, which makes them useful when interoperability with very old software is required. Outside that scenario, there is no technical reason to prefer them over newer formats.

Nested SegWit addresses (P2SH-P2WPKH) — starting with “3”

Pay-to-Script-Hash (P2SH) was introduced via BIP 16 in April 2012. It allowed funds to be locked to the hash of an arbitrary script rather than directly to a public key hash. This enabled multi-signature wallets and more complex spending conditions without forcing the sender to know the full script upfront.

When Segregated Witness (SegWit) activated in August 2017, P2SH gained a second use: wrapping SegWit scripts inside a P2SH envelope. This produced “Nested SegWit” addresses (technically P2SH-P2WPKH), which look like P2SH addresses to older wallets but carry SegWit transaction logic internally.

Characteristics:

• Prefix: 3
• Encoding: Base58Check
• Script type: P2SH wrapping P2WPKH
• Transaction size: smaller than Legacy, larger than Native SegWit
• Fee efficiency: moderate — partial SegWit discount applies

Nested SegWit served as a compatibility bridge. Wallets that could not yet send to Bech32 addresses could still send to 3... addresses and receive SegWit fee savings on the recipient’s side. That transitional purpose is largely fulfilled. Most major wallets and exchanges now support Native SegWit natively, making Nested SegWit a legacy compatibility layer rather than a recommended format for new wallets.

Native SegWit addresses (P2WPKH) — starting with “bc1q”

Native SegWit (P2WPKH) is the purest implementation of BIP 141, the Segregated Witness proposal that activated in August 2017. SegWit restructured how transaction data is organized: signature data (called “witness” data) is separated from the main transaction body and stored in a dedicated segment of the block.

Under Bitcoin’s weight unit system, witness data counts at one-quarter the weight of non-witness data. This discount directly reduces the fee a sender pays when spending from a Native SegWit address, because inputs from these addresses contribute less to the transaction’s total weight.

Characteristics:

• Prefix: bc1q
• Encoding: Bech32 (BIP 173)
• Script type: P2WPKH
• Transaction size: significantly smaller than Legacy
• Fee efficiency: approximately 30–40% lower transaction weight compared to P2PKH inputs

Bech32 encoding uses only lowercase letters and digits, with the character set further restricted to exclude characters that look alike. This makes Native SegWit addresses longer visually (42 characters for P2WPKH) but less error-prone in manual entry. Error detection is also more robust — Bech32 can detect and locate up to four substitution errors, a meaningful improvement over Base58Check.

Native SegWit also fixed transaction malleability, a long-standing protocol issue where a third party could alter a transaction’s ID without invalidating the signature. That fix was a prerequisite for the Lightning Network, Bitcoin’s primary off-chain payment protocol.

Taproot addresses (P2TR) — starting with “bc1p”

Pay-to-Taproot (P2TR) is the newest Bitcoin address format, activated via a soft fork at block 709,632 in November 2021. It introduced two major cryptographic changes: Schnorr signatures (BIP 340) and Merklized Alternative Script Trees (MAST, part of BIP 341).

Schnorr signatures replace the ECDSA algorithm used in all earlier address types. They are mathematically simpler, smaller on-chain, and enable native key aggregation — multiple signers can produce a single combined signature that is indistinguishable from a single-key signature. This has significant implications for multi-signature wallets, which previously revealed their multi-party nature in every on-chain transaction.

MAST allows a Taproot output to encode multiple spending conditions in a Merkle tree. Only the condition that is actually used is revealed when spending; all unused branches remain hidden. A complex smart contract and a simple single-key payment look identical on-chain, as long as the simple path is taken.

Characteristics:

• Prefix: bc1p
• Encoding: Bech32m (BIP 350)
• Script type: P2TR
• Transaction size: comparable to or smaller than Native SegWit
• Fee efficiency: best for multi-signature and complex script use cases; comparable to Native SegWit for simple payments
• Privacy: highest — spending conditions not revealed unless actually needed

Comparison table: all four Bitcoin address types

Format	Prefix	Standard	Activated	Fee efficiency	Privacy	Malleability fix
Legacy (P2PKH)	1...	BIP original	2009	Lowest	Low	No
Nested SegWit (P2SH)	3...	BIP 16 / BIP 141	2012 / 2017	Moderate	Low	Partial
Native SegWit (P2WPKH)	bc1q...	BIP 141 / BIP 173	2017	High	Moderate	Yes
Taproot (P2TR)	bc1p...	BIP 340/341/342	2021	Highest (complex txs)	Highest	Yes

How SegWit changed Bitcoin’s fee structure

To understand why address types affect fees, it helps to examine the block weight system SegWit introduced. Before SegWit, all bytes in a transaction counted equally. The theoretical block capacity was 1 MB. In practice, blocks were frequently full during periods of heavy network demand, pushing fees higher.

SegWit replaced the byte limit with a weight unit (vbyte) system. One weight unit equals one byte of non-witness data; witness data costs only 0.25 weight units per byte. The block limit became 4 million weight units rather than 1 MB of flat bytes.

The practical effect: a transaction spending a Native SegWit input is lighter than the same transaction spending a Legacy input, because the signature — the largest component of an input — sits in the cheaper witness segment. Consider a simple one-input, one-output transaction:

• Legacy input transaction: approximately 192 virtual bytes (vbytes)
• Native SegWit input transaction: approximately 110 vbytes
• Taproot input transaction: approximately 57 vbytes

The numbers vary by transaction structure, but the directional relationship is consistent. At a given fee rate, SegWit and Taproot transactions cost less to confirm because they occupy less effective block space.

What this means in practice

Wallet software calculates fees based on vbytes multiplied by the current fee rate (measured in satoshis per vbyte). A sender using a Legacy wallet pays more in absolute fee terms for the same fee rate as a Native SegWit or Taproot sender, assuming similar transaction complexity.

The fee savings do not apply to the output side. Any wallet, regardless of its own address type, can send to any format. The address type of the recipient determines nothing about the sender’s fee. The address type of the input being spent is what determines how much the transaction weighs.

Privacy differences between address types

Bitcoin transactions are publicly visible on the blockchain. Address type affects how much information is exposed when a transaction is broadcast and when funds are spent.

Script revelation at spend time

In P2PKH and P2SH transactions, the full spending script is revealed when an output is spent. For multi-signature arrangements, this exposes the number of required signers and all public keys involved. Anyone inspecting the blockchain can identify a 2-of-3 multisig wallet by examining how its inputs are constructed.

Native SegWit improves on this modestly: the public key is not revealed until spend time (the address only contains the key hash), though the SegWit structure is identifiable from the address prefix.

Taproot changes the privacy model more substantially. When a Taproot output is spent using the “key path” — the Schnorr signature from the combined key — it appears identical on-chain to a simple single-key payment. The Merkle tree of alternative scripts is never revealed. Only if a more complex spending condition is used (the “script path”) does additional script information become visible.

Change address detection

Blockchain analysis often works by identifying change outputs — the portion of a transaction sent back to the sender after accounting for the payment and fee. One common heuristic checks whether an output uses the same address format as the inputs. A transaction with all bc1q inputs and one bc1q output alongside one 3... output suggests the 3... is the payment and the bc1q is change, or vice versa.

Taproot’s uniformity makes this heuristic less reliable. When inputs and outputs all begin with bc1p, the analysis becomes harder, even if the underlying wallet structure is complex.

Which Bitcoin address type should you use?

The right format depends on what you are doing and what your counterparties support.

For standard self-custody wallets

Native SegWit (P2WPKH, bc1q...) is broadly supported, offers meaningful fee savings over Legacy and Nested SegWit, and is the default for most modern hardware and software wallets. It is a reasonable default choice for most users.

Taproot (P2TR, bc1p...) provides additional privacy benefits and better fee efficiency for multi-signature setups. Support across wallets and exchanges has grown steadily since the November 2021 activation, though a small number of platforms still lack full compatibility.

For multi-signature setups

Taproot with Schnorr-based key aggregation (MuSig2 or FROST) allows multiple signers to produce a combined signature that is indistinguishable from a single-key spend on-chain. This improves both privacy and fee efficiency for collaborative custody arrangements. P2WSH (the Native SegWit equivalent for multi-sig scripts) remains a solid alternative where Taproot multisig is not yet supported.

For compatibility with older services

Legacy (1...) and Nested SegWit (3...) remain universally accepted. If a service or wallet generates an error when asked to send to a bc1q or bc1p address, sending to a 3... address with Nested SegWit provides partial fee benefits without compatibility issues.

For receiving from exchanges

Most major exchanges support sending to all four formats. If an exchange lists address format options when withdrawing, Native SegWit or Taproot will typically result in lower withdrawal fees on the user’s side, since the receiving address type does not affect the sender’s fee — but many exchanges pass the network fee cost through to the user, and their own internal UTXO management may vary.

Common misconceptions about Bitcoin addresses

“An address is a Bitcoin account”

Addresses are not accounts. There is no stored balance attached to an address object on the Bitcoin network. The blockchain tracks unspent transaction outputs (UTXOs) locked to scripts. A wallet adds up all UTXOs locked to addresses it controls and presents the total as a “balance.” One wallet can control thousands of addresses.

“Reusing the same address is safe”

Every time an address receives funds, the association between the address and its UTXO is visible on-chain. Reusing addresses concentrates blockchain history, making it easier to connect multiple transactions to a single user. Best practice is to generate a new address for each incoming transaction. Modern HD (hierarchical deterministic) wallets do this automatically using derivation paths defined by BIPs 32, 44, 84, and 86.

“The “1” prefix means it’s the original Bitcoin, and therefore safer”

The prefix describes the address format, not the security model or the asset. Legacy addresses are not more secure than Native SegWit or Taproot addresses. Taproot’s Schnorr signatures are generally considered a cryptographic improvement over ECDSA.

“All addresses starting with “3” are the same”

3... addresses can be either plain P2SH (multi-signature, timelocks, or other scripts) or Nested SegWit (P2SH wrapping P2WPKH). From the address string alone, there is no way to distinguish them. The underlying script is only revealed at spend time.

FAQs

What is the difference between a Legacy and a Native SegWit Bitcoin address? Legacy addresses start with 1 and use the original P2PKH script format from 2009. Native SegWit addresses start with bc1q and use the SegWit structure introduced in 2017. The main practical differences are fee efficiency — SegWit inputs are roughly 30–40% lighter in virtual bytes — and the fix for transaction malleability that Native SegWit provides.

Can I send bitcoin from a Legacy address to a Taproot address? Yes. All four address formats are compatible as payment destinations. Any wallet can send to any format, regardless of its own address type. The address type of the sender’s inputs determines transaction weight and fees; the recipient’s address type does not restrict who can send to it.

Why do some exchanges not support Taproot addresses yet? Taproot activated in November 2021, and adoption has been gradual. Some exchange platforms have not yet updated their withdrawal or deposit systems to handle Bech32m encoding (used by Taproot) separately from Bech32 (used by Native SegWit). Support has expanded steadily; checking the specific platform’s documentation is the most reliable way to confirm current compatibility.

Are Taproot addresses more private than Native SegWit addresses? In most spending scenarios, yes. Taproot’s key-path spending produces on-chain outputs that are indistinguishable from simple single-key transactions, even when the underlying arrangement is multi-signature or involves complex script conditions. Native SegWit reveals the SegWit structure via its bc1q prefix and exposes the public key hash at receive time.

Is there a fee difference between receiving to a Native SegWit versus a Taproot address? The recipient’s address type does not affect the sender’s fee. Fees are determined by the weight of the transaction inputs being spent, not the outputs being created. The difference appears when you later spend the funds: Taproot inputs are slightly more efficient than Native SegWit inputs, particularly in multi-signature scenarios where key aggregation applies.

What does “P2PKH” or “P2TR” mean in address type names? These are script descriptor abbreviations. P2PKH stands for Pay-to-Public-Key-Hash (Legacy). P2SH stands for Pay-to-Script-Hash. P2WPKH stands for Pay-to-Witness-Public-Key-Hash (Native SegWit). P2TR stands for Pay-to-Taproot. Each name describes the mechanism by which the script locks and unlocks funds.

Can one wallet manage multiple address types at the same time? Yes. Most modern non-custodial wallets derive all four address types from the same seed phrase using different BIP derivation paths — BIP44 for Legacy, BIP49 for Nested SegWit, BIP84 for Native SegWit, and BIP86 for Taproot. The wallet displays balances across all formats under one interface, though they sit in separate derivation branches.

Disclaimer

This article is written for educational and research purposes by an independent publication. It does not constitute financial, investment, or legal advice. Bitcoin and other digital assets carry significant risks, including the potential loss of principal. Nothing in this article should be interpreted as a recommendation to buy, sell, or hold any asset. Readers are encouraged to conduct their own research and consult qualified professionals before making any financial decisions.

Understanding bitcoin address types gives you practical visibility into why transactions cost what they do, what your wallet is telling you when it shows a bc1q versus a 1, and how protocol upgrades like SegWit and Taproot have shaped Bitcoin’s architecture over time. The shift from Legacy to Native SegWit to Taproot is a compressed history of the network’s scaling and privacy engineering — each format a response to the limitations of the one before it. For most uses today, Native SegWit is a reliable default; Taproot is the direction the protocol is moving.

Our featured kindness arrives like a soft morning inside our healing corner every single day.