Bitcoin Address Formats Explained: Legacy, SegWit, and Taproot

A Bitcoin address format tells a wallet what kind of locking script should receive the coins. On Bitcoin mainnet, addresses beginning with 1 are usually legacy P2PKH, addresses beginning with 3 are commonly P2SH, bc1q addresses are native SegWit version 0, and Taproot addresses use bc1p with a 32-byte witness program. A bc1p prefix alone does not establish Taproot or even address validity. These formats are not interchangeable labels for the same output: they encode different script types, checksum rules, and spending capabilities. For a new single-signature payment, use a format supported by both the receiving wallet and the sender; native SegWit and Taproot are modern options.

The details come from Bitcoin’s own standards. BIP 173 defines the Bech32 format used for native SegWit version 0 addresses, while BIP 350 introduced Bech32m for witness version 1 and later, including Taproot. The practical lesson is simple: do not choose an address by appearance alone. Let the receiving wallet generate the address, verify the network and full string, and confirm the sending service supports that format.

Bitcoin address formats at a glance

The prefixes in this table describe lowercase mainnet addresses with valid encodings and the required program lengths. This table is a recognition aid, not a substitute for validation. A prefix can tell you the broad address family, but it cannot tell you who owns the address, whether a destination is trustworthy, or whether the sender selected the correct network.

What a Bitcoin address actually represents

A Bitcoin address is a human-friendly encoding of information used to construct a locking condition for an output. It is not the private key, and it is not a bank-style account number with a permanent balance.

Bitcoin tracks spendable outputs. When somebody pays an address, the transaction creates an output with a script that specifies the conditions required to spend it. Later, the owner satisfies those conditions with the appropriate signature or script data. This output-based design is why address choice, UTXO management and fee behavior are connected.

The Bitcoin Developer Reference documents how P2PKH and P2SH addresses are derived from version bytes, hashes, and checksums. On mainnet, P2PKH uses version byte 0x00, which commonly produces addresses beginning with 1, while P2SH uses 0x05, which commonly produces addresses beginning with 3. BIP 13 standardized the P2SH address format. Both formats encode a one-byte version, a 20-byte hash and a four-byte checksum: the first four bytes of SHA256(SHA256(version + hash)), followed by Base58 encoding.

The phrase “wallet address” can therefore be misleading. A wallet may generate many receive addresses, and a good wallet usually encourages address rotation rather than repeated reuse.

Legacy addresses: P2PKH and the 1 prefix

Legacy Pay-to-Public-Key-Hash addresses are the oldest widely recognized Bitcoin address format. On mainnet, they typically begin with 1.

A P2PKH output commits to a hash of a public key. To spend it, the owner reveals the public key and provides a valid signature. The format remains valid Bitcoin. “Legacy” does not mean invalid or unsafe by definition.

Its main disadvantage is efficiency. Legacy inputs do not receive the transaction-weight benefits associated with SegWit. A transaction spending legacy outputs will generally consume more block weight than an equivalent native SegWit spend, which can translate into higher fees when block space is expensive.

Legacy remains useful when a receiving system or old wallet does not support newer address types. But compatibility should be verified rather than assumed.

P2SH addresses: why an address beginning with 3 is not one thing

Pay-to-Script-Hash addresses generally begin with 3 on Bitcoin mainnet. P2SH was introduced to let the receiver commit to a script hash instead of forcing the sender to understand the full spending script.

That made P2SH useful for multisignature setups and other complex conditions. It later became a common compatibility wrapper for SegWit through P2SH-P2WPKH and P2SH-P2WSH.

This is an important edge case: seeing a 3 prefix does not prove that the address is “SegWit.” A 3 address identifies the P2SH family. The redeem script determines what actually sits behind it.

For users, this means a wallet or exchange that says it supports “addresses starting with 3” may be supporting several script constructions. The safest approach is still to use the receive address generated by the destination wallet and follow the sender’s compatibility rules.

Native SegWit: bc1q and Bech32

Segregated Witness changed the way witness data is committed to and measured in Bitcoin transactions. BIP 141 defines SegWit, including native witness programs. BIP 173 defines Bech32 addresses for native witness version 0 outputs.

On Bitcoin mainnet, those addresses use the human-readable part bc and normally begin with bc1q.

For single-signature wallets, the common native SegWit construction is P2WPKH. For more complex scripts, P2WSH can be used. Both use witness version 0. P2WPKH has a 20-byte witness program and a 42-character mainnet address; P2WSH has a 32-byte program and a 62-character mainnet address. Other version-0 program lengths are invalid.

Native SegWit is widely supported and is often the practical default for ordinary Bitcoin transfers because it combines broad compatibility with more efficient transaction weight than legacy spending.

Bech32 has a six-character checksum designed to detect common transcription errors. Its lowercase data alphabet is qpzry9x8gf2tvdw0s3jn54khce6mua7l: it excludes 1, b, i and o, but includes 0 and l. This is not Base58’s exclusion of 0, O, I and l. The alphabet restriction applies to the data part, not the human-readable part or separator. A valid checksum does not prove that an address belongs to the intended recipient, however. Malware can replace a copied address with another valid address.

Taproot: bc1p and Bech32m

Taproot outputs use Pay-to-Taproot, or P2TR: native witness version 1 with a 32-byte program. Their lowercase mainnet addresses begin with bc1p and are 62 characters long. A version-1 program of another length is not P2TR; some other lengths can pass generic witness-address decoding without receiving Taproot spending rules. Do not use an arbitrary bc1p string as a Taproot destination.

Taproot uses witness version 1. BIP 350 changed the checksum construction for witness version 1 and future versions from Bech32 to Bech32m after a weakness was identified in the original checksum’s behavior for upgraded witness versions.

That distinction matters technically:

• witness version 0 uses Bech32;
• witness version 1 through 16 use Bech32m;
• a bc1q address is therefore not simply an older spelling of a bc1p address.

BIP 341 defines Taproot spending. A key-path spend does not reveal whether alternative script paths exist. A script-path spend reveals the executed script and its commitment proof, not all unused scripts; it is distinguishable from a key-path spend. These are limited scripting-privacy benefits, not transaction anonymity. The Bitcoin Core output descriptor documentation reflects these different script families with descriptors such as pkh(), wpkh(), sh(), wsh(), and tr().

For a normal user, the important question is simpler: does the receiving wallet generate Taproot addresses, and does the sending service allow withdrawals to them? If either side does not support Taproot, native SegWit is often the easier choice.

Which Bitcoin address format should you use?

Use the address generated by the wallet that will receive the funds. Do not manually convert one address type into another.

A practical decision process is:

1. Confirm the destination is Bitcoin mainnet, not Bitcoin Cash, Lightning, Liquid, or another network.
2. Open the receiving wallet and generate a fresh receive address.
3. If the wallet offers multiple Bitcoin address types, prefer native SegWit for broad modern compatibility unless you specifically need Taproot or legacy compatibility.
4. Check the withdrawal platform’s supported formats.
5. Compare the beginning and end of the address, then verify the full address on the trusted device before sending.
6. For a large transfer, consider a small test transaction first when operational risk justifies the extra fee.

The goal is not to chase the newest prefix. The goal is to create an output that the receiving wallet can actually spend.

Worked example: choosing between 1, 3, bc1q, and bc1p

Suppose a hardware wallet offers four account types:

• Legacy: 1...
• Nested SegWit: 3...
• Native SegWit: bc1q...
• Taproot: bc1p...

You want to withdraw BTC from an exchange.

If the exchange accepts bc1q, native SegWit is usually a sensible default. It avoids the extra wrapper used by nested SegWit and is broadly supported.

If the exchange accepts Taproot withdrawals and your hardware wallet clearly shows a bc1p receive address on the trusted device, Taproot is also valid. There is no rule that every ordinary payment must use Taproot, however.

If the exchange rejects bc1q or bc1p, a 3 nested-SegWit address may provide compatibility while still allowing SegWit spending later. Legacy 1 addresses remain a last-resort compatibility option when necessary.

Never paste an address into a third-party converter just to satisfy a withdrawal form. A different script type needs a wallet-controlled address for that script type.

Why address format can affect fees

Bitcoin fees depend on transaction weight, not simply on the number of BTC being sent. The input types being spent usually matter more than the receive-address prefix alone.

SegWit moved signatures into witness data, which is counted at a lower weight. Native SegWit also avoids the P2SH wrapper needed by nested SegWit. As a result, spending P2WPKH inputs is generally more weight-efficient than spending comparable P2PKH inputs.

Taproot key-path spends can also be compact, but transaction cost depends on the exact input and output composition. It is misleading to promise a fixed percentage fee saving from one address format because the actual fee also depends on the number and types of inputs, outputs, the fee rate, and whether complex scripts are involved.

For a deeper view of why input selection changes fees, see BTC-Pulse’s guide to Bitcoin coin selection, fees, and privacy.

Address format does not remove privacy risk

A new address format is not a privacy shield.

Reusing the same receive address makes it easier for outside observers to associate multiple payments with the same destination. Change outputs and coin-selection behavior can create additional clustering signals. BTC-Pulse explains this in Bitcoin change outputs.

Taproot can make a simple key-path spend look like a cooperative key-path spend involving several parties, but it does not make key-path and script-path spends indistinguishable. Privacy still depends on wallet behavior, UTXO management, transaction graph analysis, exchange identification, and off-chain information.

The practical rule is to generate a fresh receive address for new payments when your wallet supports it and to avoid publishing a single permanent Bitcoin address unless the use case requires it.

Common Bitcoin address mistakes

Confusing Bitcoin with Bitcoin Cash

Some wallets and exchanges support both assets. An address that looks plausible is not enough. Verify the asset and network explicitly.

Assuming every 3 address is nested SegWit

P2SH is a general script-hash construction. Nested SegWit is one use of it, not the only one.

Treating bc1q and bc1p as interchangeable

They represent different witness versions and use different checksum rules. Use the exact address generated by the receiving wallet.

Copying only the first and last characters

Checking the edges is useful, but clipboard malware can preserve those characters. For meaningful transfers, verify the full address on a trusted hardware-wallet screen or another trusted channel.

Reusing an old address forever

Old addresses usually remain spendable if the wallet still controls the keys, but reuse harms privacy and can create operational confusion. Generate a new receive address when practical.

Sending before checking withdrawal support

A valid Bitcoin address may still be rejected by an exchange that has not enabled that address type. Check before initiating the transfer.

Are Bitcoin addresses case-sensitive?

Base58Check legacy and P2SH addresses are case-sensitive because uppercase and lowercase characters have different values.

Bech32 and Bech32m are designed to be used in one consistent case. BIP 173 permits an all-uppercase or all-lowercase encoded string at the specification level, but mixed-case Bech32 strings are invalid. In practice, Bitcoin wallets display bc1... addresses in lowercase.

Do not change letter case manually. Copy the address exactly as the receiving wallet provides it.

Can you tell whether an address is valid from the prefix?

No. The prefix is only an early clue.

A valid address must also have the correct encoding, length or witness program, network parameters, and checksum. The general Bech32/Bech32m string limit is 90 characters, but Bitcoin mainnet witness addresses are only 14–74 characters. Witness versions range from 0 to 16 and programs from 2 to 40 bytes, with the stricter version-0 and Taproot lengths described above. Decoders must also reject incorrect conversion padding and a checksum variant that does not match the witness version. Wallet software should validate these rules before creating a transaction.

Even a technically valid address can still be the wrong recipient. Format validation protects against some typing errors; it does not authenticate the person or service you intended to pay.

Are old address formats being deprecated?

Legacy, P2SH, native SegWit, and Taproot outputs are all part of Bitcoin’s existing consensus and wallet ecosystem. Newer wallet defaults do not automatically invalidate older UTXOs.

What changes over time is software support and preferred wallet behavior. A modern wallet may default to bc1q or bc1p, while an older service may still recognize only Base58 formats.

For that reason, “newest” and “best for this transfer” are not always the same answer. Compatibility, fee efficiency, script requirements, and the receiving wallet’s control matter more than the prefix by itself.

Final checklist before sending Bitcoin

Before confirming a Bitcoin transfer:

• verify Bitcoin is the selected asset and network;
• generate the receive address in the destination wallet;
• confirm the sender supports that format;
• check the full address on a trusted screen;
• do not convert addresses through random websites;
• use a test transfer when the value and operational risk justify it;
• wait for the appropriate confirmations before treating the payment as final.

The format tells Bitcoin how the output can eventually be spent. It does not tell you whether the destination is trustworthy. The safest workflow combines correct script format with independent recipient verification and good UTXO hygiene.

Sources

• Bitcoin Developer Reference — Transactions — primary.
• BIP 13 — Address Format for pay-to-script-hash — primary.
• BIP 141 — Segregated Witness — primary.
• BIP 173 — Base32 address format for native v0-16 witness outputs — primary.
• BIP 350 — Bech32m format for v1+ witness addresses — primary.
• BIP 341 — Taproot — primary.
• Bitcoin Core — Output Descriptors — primary.