Bitcoin Address Types Explained: Legacy, SegWit and Taproot
Four prefixes, and every one of them still works. An address starting with 1 is legacy pay-to-public-key-hash. One starting with 3 is pay-to-script-hash. bc1q is native SegWit version 0, and bc1p is Taproot. They differ in how the coins are locked, how much block space it takes to spend them later, and which wallets can parse the string. Nothing else.
The part that costs people money is the second item on that list. The address format you receive to today determines the fee you pay whenever you eventually spend, and the gap between the cheapest and the most expensive is not small. Here is what each format is, what it costs, and how to tell which one you are actually using.
What do the different address prefixes actually mean?
Bitcoin has no accounts. Coins sit in unspent outputs, and each output carries a small script saying what has to be presented to move it. An address is a compact, typo-resistant encoding of that locking script. Change the script and you change the prefix.
Legacy, prefix 1. Pay-to-public-key-hash. The output commits to a hash of your public key; to spend, you supply the key and a signature. It is the format Bitcoin launched with and the only one that worked until 2012. Every wallet on earth can send to it, which is the sole remaining argument for using one.
P2SH, prefix 3. Pay-to-script-hash, from BIP-13 and BIP-16. The output commits to the hash of a script rather than a key, so the complexity moves to the spender. This is where multisig lived before SegWit, and it is also where "wrapped" SegWit hides: a P2WPKH tucked inside a P2SH wrapper so that ancient sending software sees a familiar 3 address. A 3 address tells you nothing about what is inside it, which is worth remembering.
Native SegWit, prefix bc1q. Witness version 0, encoded with bech32 as specified in BIP-173. Signature data moves out of the transaction body into a separate witness field that is weighted at one quarter. The addresses are all lowercase, 42 characters for a single-key output and 62 for a script hash.
Taproot, prefix bc1p. Witness version 1, activated at block 709632 in November 2021. Taproot uses Schnorr signatures from BIP-340 and merges the old pay-to-pubkey and pay-to-scripthash policies into one output type. A cooperative spend reveals a single signature and looks identical to any other Taproot spend, whether the underlying arrangement was one person or a 5-of-7 committee.
| Type | Prefix | Spec | Encoding | Length | Input vB | Output vB |
|---|---|---|---|---|---|---|
| P2PKH legacy | 1 | Bitcoin 0.1 | Base58Check | 26 to 35 | 148 | 34 |
| P2SH script or wrapped SegWit | 3 | BIP-13, BIP-16 | Base58Check | 34 | varies | 32 |
| P2WPKH native SegWit | bc1q | BIP-141, BIP-173 | bech32 | 42 | 68 | 31 |
| P2WSH SegWit script | bc1q | BIP-141, BIP-173 | bech32 | 62 | varies | 43 |
| P2TR Taproot | bc1p | BIP-341, BIP-350 | bech32m | 62 | 57.5 | 43 |
Why does spending from a legacy address cost more?
Because you are not billed per byte. You are billed per virtual byte, and SegWit changed which bytes count how much. Witness data, meaning signatures and public keys, is weighted at one quarter of a normal byte. A signature is the bulk of what an input carries, so moving it into the witness field cuts the billed size of that input by more than half.
The numbers are not close. Bitcoin Optech publishes 148 vbytes to spend a single-signature legacy P2PKH input, 68 vbytes for a native SegWit P2WPKH input, and 57.5 vbytes for a Taproot key-path spend. Run that at a fee rate of 20 sat/vB and one legacy input costs 2,960 satoshis to move while the SegWit equivalent costs 1,360. If you are sitting on twenty small legacy outputs, that arithmetic is the difference between consolidating cheaply and not bothering.
Is Taproot always cheaper than SegWit v0?
No, and anyone who tells you otherwise has only looked at the input column. A Taproot output is 43 vbytes against 31 for P2WPKH, because the output commits to a full 32-byte key rather than a 20-byte hash. For an ordinary two-input, two-output payment those two effects very nearly cancel, then tip the wrong way: Optech puts the all-SegWit-v0 version at 208.5 vbytes and the all-Taproot version at 211.5.
Three vbytes. At 20 sat/vB that is 60 satoshis, which is not a reason to do anything. But it is a useful correction to the marketing, and it points at where Taproot genuinely wins:
- Multisig. This is the real prize. A key-path Taproot spend of an aggregated multisig looks like any other single-key spend, at 57.5 vbytes, instead of the much larger witness a P2WSH multisig input carries.
- Input-heavy spends. If a transaction has many inputs and few outputs, the input discount dominates and Taproot pulls ahead.
- Privacy. Cooperative spends of complex arrangements are indistinguishable from ordinary payments, and only the branch you actually used is ever published.
If you care about the fee side of this in practice rather than in theory, the mechanics of fee estimation and mempool behaviour are covered in our guide to Bitcoin fees and the mempool.
Why does my wallet hand me a new address every time?
Because it is hierarchical and deterministic, and because reusing an address is a privacy leak with no upside. Every address your wallet shows comes from a single seed, walked down a derivation path. The path's first level, called the purpose, encodes which address type the branch produces, and this is why importing a seed into the wrong wallet sometimes shows a balance of zero even though nothing is lost.
| Standard | Account path | Produces | Extended public key |
|---|---|---|---|
| BIP-44 | m/44'/0'/0' | legacy, 1 | xpub |
| BIP-49 | m/49'/0'/0' | wrapped SegWit, 3 | ypub |
| BIP-84 | m/84'/0'/0' | native SegWit, bc1q | zpub |
| BIP-86 | m/86'/0'/0' | Taproot, bc1p | xpub |
Any decent wallet scans several purposes on restore. Some do not. Before concluding that a backup has failed, check the derivation path setting, and check whether a passphrase is expected. A block explorer will confirm in seconds whether the address the wallet is showing has ever seen a transaction.
Why does the dust limit depend on which address type you use?
Here is a consequence almost nobody mentions. Bitcoin Core refuses to relay an output so small that spending it would cost more in fees than it is worth, and because the cost of spending depends on the address type, the threshold does too.
The policy code spells out the arithmetic. A legacy output is 34 bytes and needs an input of at least 148 bytes to spend, so 182 bytes total; at the default relay rate of 3000 sat/kvB that puts the floor at 546 satoshis. A P2WPKH output is 31 bytes and needs at least 67, so 98 bytes total, and the floor drops to 294 satoshis. Same node, same settings, nearly half the threshold, purely because of the witness discount.
Two practical consequences. If you are splitting a balance into small pieces, or running anything that produces micro-outputs, native SegWit lets you go meaningfully lower before the network stops relaying. And if you have ever wondered why 546 is the number that shows up everywhere in Bitcoin tooling, that is where it comes from: it is not a constant somebody chose, it is 182 multiplied by the relay fee rate.
The same threshold is what makes dust attacks cheap for whoever is running them, which we cover in the section on dust and address poisoning.
What is bech32m and why did the format change again?
Because the first version had a bug, and the developers found it before it cost anybody anything.
BIP-173's bech32 checksum has a specific weakness: when the last character of an address is a p, inserting or deleting any number of q characters immediately before it leaves the checksum valid. Version 0 addresses dodged this because their lengths are fixed at 42 and 62 characters, so a length-changing edit fails on length alone. Future witness versions with variable-length programs had no such protection.
BIP-350 fixes it by changing one number. The checksum constant becomes 0x2bc830a3, everything else stays identical, and the rule is now simply: witness version 0 uses bech32, versions 1 through 16 use bech32m. The two are deliberately incompatible so that old software fails closed rather than accepting an address it does not understand.
Can I send from a legacy address to a Taproot one?
Yes. The format of the address you are spending from has no bearing on the format you can pay to. A transaction takes inputs of any type and creates outputs of any type, and miners do not care.
What does break is old software on the sending side. A wallet or exchange written before BIP-173 will not encode a bc1q destination, and one written before BIP-350 may reject bc1p. That is a limitation of that program, not of the network, and it is now rare enough to be a genuine signal about the operator. If an exchange in 2026 cannot pay a Taproot address, it is telling you how much attention its engineering gets.
Two related points worth knowing. First, bech32 addresses are case-insensitive by specification, but must be all one case; wallets display lowercase, and a mixed-case string is invalid rather than merely ugly. Second, the digit 1 does double duty as the separator and is excluded from the data charset, along with b, i and o, precisely so that the characters most often confused when read aloud or transcribed cannot appear in the payload.
What the common error messages actually mean
"Invalid address" from a sending wallet almost always means one of four things, and they are easy to tell apart. If the string starts with tb1 you have a testnet address and you were about to make an expensive mistake. If it starts with bc1p and the wallet is old, it does not know bech32m. If it looks right but fails, check for a copy-paste artefact: a trailing space, a line break, or a smart-quote character picked up from a chat app. And if you retyped it by hand, the checksum did its job, which is the entire reason bech32 has one.
What never happens is coins going to a valid-but-wrong address type. There is no such state. An address either encodes a locking script or it fails the checksum, and the failure happens on your machine before anything is broadcast.
So which one should you actually use?
Receive to bc1q or bc1p. Stop receiving to 1 and 3. Those two exist for compatibility with software that should have been updated years ago, and every coin you park in one is a fee bill you have deferred rather than avoided.
Between the two modern options, the honest answer is that it barely matters for ordinary single-key use, and the tiebreakers are these. Choose Taproot if you use multisig, if you accumulate many small inputs you will consolidate later, or if you want the privacy properties. Choose SegWit v0 if you deal with counterparties whose software is behind, or if you want the widest possible compatibility with no thinking involved. Both are fine. Neither is legacy.
| Your situation | Receive to | Why |
|---|---|---|
| Ordinary single-key savings | bc1p or bc1q | Either is right. Pick one and stop thinking about it. |
| Multisig of any flavour | bc1p | Key-path spends cost 57.5 vB and look like any other payment. |
| Many small deposits you will consolidate | bc1p | The input discount compounds across every input you sweep. |
| Counterparty on old software | bc1q | Broadest modern support. Falls back further only if forced. |
| An exchange that only offers 1 or 3 | 3, then move it | Take the coins, then send them onward to a modern address once. |
| Anything at all in 2026 | not 1 | A legacy input is 148 vB forever. That bill comes due on spend. |
One thing that is not optional: check the address on the hardware wallet's own screen before you confirm, every time. Your computer can lie about what is on it, and the whole point of a hardware wallet is that its display cannot. That habit is also the single defence against the address-substitution tricks covered in our piece on common Bitcoin scams.
A last piece of trivia that says something about how far this has come. The very first Bitcoin output, the coinbase of the genesis block, has no address at all. It is a bare pay-to-public-key script, a format that predates addresses entirely. Explorers display 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa next to it as a convenience, and people have been sending small tributes to that derived address ever since: it had received 57.32 BTC across 64,296 transactions when we checked on 29 July 2026. None of it is spendable by anyone. It is the most expensive shrine in computing.
Related on BTCLinks
Sources
- BIP-173: Base32 address format for native v0-16 witness outputs. Source of the bech32 spec, the charset rules and the mainnet P2WPKH and P2WSH test vectors. Verified 2026-07-29.
- BIP-350: Bech32m format for v1+ witness addresses. Source of the checksum flaw description, the 0x2bc830a3 constant, and the bech32m test vector shown above. Verified 2026-07-29.
- BIP-341: Taproot, SegWit version 1 spending rules. Source of the witness version 1 output format, the Schnorr requirement and the block 709632 activation. Verified 2026-07-29.
- BIP-86: Key derivation for single key P2TR outputs. Source of the m/86' path and the address in the hero diagram. Verified 2026-07-29.
- BIP-84 and BIP-49. Sources of the zpub and ypub extended key version bytes. Verified 2026-07-29.
- Bitcoin Optech: Preparing for Taproot. Source of every vbyte figure quoted, including the 2-in 2-out totals of 374, 208.5 and 211.5. Verified 2026-07-29.
- Bitcoin Core, src/policy/policy.cpp. The GetDustThreshold comment is the source of the 182-byte and 98-byte figures and the resulting 546 and 294 satoshi thresholds at the default 3000 sat/kvB relay rate. Verified 2026-07-29.
- Genesis block coinbase transaction. Confirms the output is a bare pay-to-public-key script with no address. Address totals for the derived 1A1zP1eP address read from the same explorer's API on 2026-07-29.
Some links are affiliate links. As an Amazon Associate we earn from qualifying purchases. Not financial advice.