Bitcoin Address Types: 1, 3, bc1q, bc1p
Bitcoin has four main address formats, and you can tell them apart by how they start: 1 is legacy (P2PKH), 3 is script hash (P2SH, often wrapped SegWit), bc1q is native SegWit, and bc1p is Taproot. All four can send to and receive from each other. For an ordinary single-signature wallet in 2026, native SegWit or Taproot is the sensible default, because a legacy input takes more than twice the block space of a SegWit one, and block space is what you pay for.
Address choice sounds like a technical footnote, but it decides three practical things: how much each future payment costs, whether older software can send to you, and how your wallet must be restored from backup. This guide covers each format, the fee arithmetic behind the choice with sizes we calculated from the protocol rules, the compatibility traps, and a short decision table. The specifications quoted are the Bitcoin Improvement Proposals (BIPs) themselves, checked on October 21, 2026.
Recognizing an Address at a Glance
| Starts with | Format | Defined in | Typical length | Encoding |
|---|---|---|---|---|
| 1 | Legacy pay-to-public-key-hash (P2PKH) | Original protocol | 26 to 34 characters | Base58Check, version byte 0 |
| 3 | Pay-to-script-hash (P2SH), including nested SegWit | BIP 13 and BIP 16 | 34 characters | Base58Check, version byte 5 |
| bc1q | Native SegWit version 0 (P2WPKH or P2WSH) | BIP 141, BIP 173 | 42 characters (P2WPKH) or 62 (P2WSH) | Bech32 |
| bc1p | Taproot, SegWit version 1 (P2TR) | BIP 341, BIP 350 | 62 characters | Bech32m |
Sources: BIP 13, BIP 173, BIP 341 and BIP 350 on GitHub; Bitcoin Wiki list of address prefixes. Checked October 21, 2026.
Testnet addresses look different on purpose: BIP 13 gives testnet P2SH addresses a different version byte (196), and BIP 173 reserves the tb prefix for testnet SegWit addresses, which start with tb1. If a wallet shows tb1 on what you believe is a real wallet, stop and check the network setting before sending anything.
What Each Format Actually Is
An address is not an account. It is a compact, checksummed way to write a locking condition, the script that a future spender must satisfy. The format tells you which kind of condition it is.
Legacy (starts with 1)
The coins are locked to the hash of a public key. To spend them, you reveal the public key and a signature, and all of that goes in the non-witness part of the transaction, which counts at full weight. That is why legacy inputs are the most expensive to spend. Legacy addresses use Base58Check, which avoids look-alike characters and has a checksum, and they are case-sensitive.
Script hash (starts with 3)
The coins are locked to the hash of a script, which the spender reveals at spending time. BIP 13 fixed the address form: version byte 5 on mainnet, which produces the leading 3. P2SH is used for multisignature setups and, from 2017 onward, for "nested" or "wrapped" SegWit, where a SegWit script sits inside a P2SH wrapper so that older wallets that could only pay to 1 and 3 addresses could still pay to a SegWit wallet. A 3 address does not tell you which script is inside it.
Native SegWit (starts with bc1q)
SegWit version 0 moves the signature data into the witness area, which BIP 141 counts at one quarter weight. Native SegWit addresses are written in Bech32 (BIP 173), with the human-readable part "bc" on mainnet. BIP 173 specifies an all-lowercase or all-uppercase form, never mixed; a character set that excludes 1, b, i and o from the data part; and a checksum that is guaranteed to detect any error affecting up to four characters. The 42-character form is a single-key wallet (P2WPKH). The 62-character form is a script, often multisig (P2WSH).
Taproot (starts with bc1p)
Taproot is SegWit version 1, defined in BIP 341, and active on mainnet from block 709,632, the minimum activation height in the Bitcoin Core 0.21.1 release notes. That block carries a timestamp of November 14, 2021 (mempool.space, checked October 22, 2026). The output commits to a single 32-byte key. It can be spent two ways: the key path, with one 64-byte Schnorr signature (BIP 340), or the script path, which reveals one of several alternative scripts committed to in advance. BIP 341 points out the privacy benefit: on a key-path spend, nobody learns that other spending conditions existed.
Taproot addresses use Bech32m, defined in BIP 350, because the original Bech32 had an unexpected weakness: if the last character is p, inserting or deleting q characters just before it can leave the checksum valid. BIP 350 changes one constant in the checksum to fix that and requires Bech32m for witness versions 1 through 16, keeping Bech32 for version 0.
Why the Lengths Differ
The length of an address is mostly the length of what it commits to, plus the prefix and checksum.
That last point is a design trade-off. Earlier formats hid the public key behind a hash until the coins were spent. Taproot puts the key itself in the output, which saves space at spending time and enables the key-path privacy features above. Some researchers discuss what exposed public keys would mean if large-scale quantum computers ever become practical. That concern applies to any address whose public key has already appeared on-chain, including reused legacy and SegWit addresses, and is an active research topic rather than a present-day risk.
You do not need any of this to use a wallet. It is useful for one practical reason: if someone shows you a "Bitcoin address" with an unusual length or prefix, it is either a format you have not met, a different network, or a mistake, and all three are reasons to stop and check.
The Fee Arithmetic
Fees are charged per virtual byte. The size of each part of a transaction depends on its script type. These sizes are our calculation from the standard serialization, using a 72-byte ECDSA signature with sighash byte and a 64-byte Schnorr signature; real transactions vary by about a byte.
| Format | Input (to spend one coin) | Output (to create one coin) | Typical 1-input, 2-output payment | 3-input, 2-output payment |
|---|---|---|---|---|
| Legacy P2PKH | about 148 vB | 34 vB | about 226 vB | about 522 vB |
| Nested SegWit (P2SH-P2WPKH) | about 91 vB | 32 vB | about 166 vB | about 348 vB |
| Native SegWit P2WPKH | about 68 vB | 31 vB | about 141 vB | about 277 vB |
| Taproot P2TR, key path | about 57.5 vB | 43 vB | about 154 vB | about 269 vB |
Calculated by CryptosEyes from BIP 141 weight rules. Checked October 21, 2026.
What that costs at real fee rates
| Format | 1-in, 2-out at 5 sat/vB | 1-in, 2-out at 50 sat/vB |
|---|---|---|
| Legacy | 1,130 sats | 11,300 sats |
| Nested SegWit | 830 sats | 8,300 sats |
| Native SegWit | 705 sats | 7,050 sats |
| Taproot | 770 sats | 7,700 sats |
Three readings:
Worked example: a year of payments
An illustration with stated inputs. A small business sends 100 payments a year, each one input and two outputs, at an average of 10 sat/vB. From a legacy wallet that is 226,000 satoshis in fees. From a native SegWit wallet it is 141,000 satoshis. The difference, 85,000 satoshis, was about 71 dollars at the 84,101 dollar bitcoin price in the CryptosEyes dataset pull of October 21, 2026. In a busy fee market, at 50 sat/vB, the same difference is five times larger. The fee level changes; the 60 percent penalty does not.
Our transaction fees and mempool guide explains how the fee rate itself is set, and what the mempool looked like on the same date.
Worked example: retiring a legacy wallet
Another illustration with stated inputs. A wallet holds eight legacy coins. Spending all eight later, as part of a payment during a busy period at 50 sat/vB, would cost about 59,200 satoshis for those inputs alone (eight inputs at 148 vB each, times 50). Consolidating them now into one native SegWit output on a quiet day at 2 sat/vB costs about 1,225 vB times 2, or 2,450 satoshis (10 vB overhead, eight legacy inputs, one 31 vB output). Spending that single SegWit coin later at 50 sat/vB costs about 3,400 satoshis for its input.
| Path | Fee now | Fee for the inputs at a later 50 sat/vB spend | Total |
|---|---|---|---|
| Leave eight legacy coins as they are | 0 | about 59,200 sats | about 59,200 sats |
| Consolidate at 2 sat/vB, then spend one SegWit coin | about 2,450 sats | about 3,400 sats | about 5,850 sats |
The saving comes from two effects at once: fewer inputs, and cheaper inputs. The cost is privacy, because the consolidation transaction shows that all eight coins belonged to the same owner. If those coins came from sources you would rather not link, weigh that before merging them.
Multisignature: where the witness discount is largest
Multisig spends carry several signatures and the full script, so moving that data into the witness saves the most. For a 2-of-3 multisig with compressed keys, our calculation gives:
| Format | Approximate input size | Relative cost |
|---|---|---|
| Legacy P2SH 2-of-3 | about 297 vB | 100% |
| Native SegWit P2WSH 2-of-3 | about 104.5 vB | about 35% |
Calculated by CryptosEyes: two 73-byte signature pushes plus a 105-byte redeem script, in the scriptSig for P2SH and in the witness for P2WSH.
Taproot can do better still in some setups, because a group that cooperates can spend through the key path with one signature, which looks on-chain like any single-key spend. Whether that is available depends on your wallet and signing software supporting it. If you run multisig, ask your coordinator software which Taproot features it supports before migrating.
Privacy Differences Between the Formats
Address format leaks information. Anyone looking at the chain can see which format each output uses, and that narrows down which wallet software created it. A few points worth knowing:
None of these replace basic habits like using a fresh address for every receipt, but they are a reason to prefer the format most wallets around you use.
Compatibility: Who Can Pay Whom
Any address type can pay any other address type. The protocol does not care. What can fail is software.
Mistakes That Lose Money
The checksums in every format catch most typing errors, so the costly mistakes are usually something else.
Restoring a Wallet: Why the Type Matters
Most wallets generate addresses from one seed using a standard derivation path, and the path depends on the address type. BIP 86, for example, defines the Taproot single-key path with purpose 86', following the account structure in BIPs 44, 49 and 84 (which cover legacy, nested SegWit and native SegWit respectively). A wallet that knows the seed but looks under the wrong purpose number finds an empty wallet.
In practice:
Which Type Should You Use?
| Situation | Reasonable choice | Why |
|---|---|---|
| New single-signature wallet | Native SegWit or Taproot | Lowest fees; both widely supported in 2026 |
| Receiving from a service that rejects bc1p | Native SegWit | Bech32 support is near universal |
| Many small coins you will later consolidate | Taproot | Smaller inputs matter more when there are many of them |
| Multisignature | Native SegWit (P2WSH) or a Taproot-based setup your software fully supports | Witness discount on the signatures; check coordinator support |
| An old legacy wallet with funds | Move funds to a modern type on a low-fee day | Each future spend is cheaper; one consolidation now |
| Hardware wallet | Whatever types its current firmware supports for both sending and signing | Test with a small amount first |
These are general considerations, not personal advice. If you rely on a particular custodian or exchange, its supported types take priority.
Frequently Asked Questions
What does an address starting with bc1q mean?
It is a native SegWit (witness version 0) address written in Bech32. The 42-character form locks coins to a single key (P2WPKH); the 62-character form locks them to a script, often multisig (P2WSH). It is cheaper to spend from than a legacy address.
Is a bc1p Taproot address safe to use?
Taproot has been active on mainnet since block 709,632, mined on November 14, 2021. The main practical risk is compatibility: some older services cannot send to bc1p addresses. Sending will fail rather than lose funds, but test with a small amount when using a new service.
Can I send bitcoin from a legacy address to a SegWit address?
Yes. Every address type can pay every other type. Moving coins from a legacy address to a native SegWit or Taproot address is the usual way to upgrade, and later spends from the new address will be cheaper.
Why does my wallet show a different address every time?
To protect privacy. Wallets derive a fresh address from the same seed for each payment you receive. All of them belong to your wallet. Reusing one address works, but it lets anyone link your payments together.
Which Bitcoin address type has the lowest fees?
For a single-signature payment with one input, native SegWit is about 141 vB and Taproot about 154 vB, so native SegWit is slightly cheaper. With three or more inputs, Taproot's smaller inputs make it slightly cheaper. Both are far cheaper than legacy, which is about 226 vB for the same simple payment.
What happens if I mistype a Bitcoin address?
Almost always, the wallet rejects it. Base58Check and Bech32 both include checksums, and BIP 173 guarantees that Bech32 detects any error affecting up to four characters. The dangerous cases are a valid address you did not intend, such as one swapped in by malware, or an address on a different network.
Where to Go From Here
Moving coins from an exchange to one of these addresses for the first time? Our withdrawal walkthrough adds the steps around the address itself: picking the right network, confirming the address on the device screen, and sending a small test before the full amount.
If you are setting up or upgrading a wallet, the next step is understanding how its backup works for the address type you picked. The wallet basics guide explains keys, seeds and addresses from the ground up, and the wallet recovery checklist shows how to test a restore before you rely on it. For the block-level background, see how a blockchain works, and for why each new halving makes fee efficiency matter more to the network, see our halving history. More explainers are in the CryptosEyes research library.
CryptosEyes publishes educational research, not financial or security advice. Wallet and service support for address types changes with software updates; confirm with your provider and test with a small amount before moving significant funds.
Source & Review Basis
This article is reviewed against the source types below. Source links are provided to help readers verify primary documents, market context, and methodology independently.
Mainnet P2SH version byte 5, producing a leading 3. Checked October 21, 2026.
Weight and virtual size definitions used for the size tables. Checked October 21, 2026.
bc and tb prefixes, no mixed case, character set, error-detection guarantee, example addresses. Checked October 21, 2026.
Bech32 weakness and the Bech32m fix; Bech32m for witness versions 1 to 16. Checked October 21, 2026.
SegWit version 1, 32-byte output key, key path and script path spending, privacy rationale. Checked October 21, 2026.
Purpose 86' and the account structure from BIPs 44, 49 and 84. Checked October 21, 2026.