The Complete Guide to Bitcoin Address Types: From Genesis to Taproot

If you’ve been in Bitcoin for any length of time, you’ve probably noticed that addresses come in different flavors. Some start with “1”, others with “3”, and the newer ones begin with “bc1q” or “bc1p”. These aren’t arbitrary differences—each represents a distinct era in Bitcoin’s evolution, with different security properties, fee structures, and capabilities.

This guide breaks down every Bitcoin address type, from the original format Satoshi used to the latest Taproot addresses. We’ll cover the history, the technical details, and the practical implications for your wallet and transactions.

Want to validate an address? Try our Bitcoin Address Validator & Analyzer tool—it runs entirely in your browser and breaks down exactly what type of address you’re looking at.

The Original: Pay-to-Public-Key (P2PK)

Before there were Bitcoin “addresses” as we know them, there was P2PK. The genesis block and Satoshi’s first transaction to Hal Finney on January 12, 2009 both used this format. Payments went directly to a raw public key—no hashing, no encoding, just the key itself embedded in the transaction.

P2PK transactions are still valid today, but nobody uses them anymore. The problem is twofold: the public key is exposed immediately on the blockchain (65 bytes uncompressed), and there’s no checksum to catch errors. If quantum computers ever become a threat to elliptic curve cryptography, those early P2PK outputs will be the first targets since the public key is already known.

The genesis block’s 50 BTC reward remains unspendable due to a quirk in Bitcoin Core’s code—it’s not included in the transaction database. People still send tributes to that address (over 70 BTC received to date), but those coins are locked forever alongside the original coinbase.

P2PKH: The Legacy Standard (Addresses Starting with “1”)

Pay-to-Public-Key-Hash became the dominant format by 2011 and remained so for years. These are the classic Bitcoin addresses starting with “1” that most people first encountered.

The key innovation was hashing the public key before embedding it in the transaction. Instead of exposing the full public key, the blockchain only contains RIPEMD160(SHA256(pubkey))—a 20-byte hash. The actual public key only gets revealed when you spend from the address, not when you receive.

Base58Check: Satoshi’s Design Decision

P2PKH addresses use Base58Check encoding, which Satoshi designed specifically for Bitcoin. From the original source code comments:

“Why base-58 instead of standard base-64 encoding?”

• Don’t want 0OIl characters that look the same in some fonts
• A string with non-alphanumeric characters is not as easily accepted as an account number
• E-mail usually won’t line-break if there’s no punctuation to break at
• Double-clicking selects the whole number as one word

The excluded characters—zero, uppercase O, uppercase I, and lowercase L—are precisely the ones that cause transcription errors when humans copy addresses by hand or read them aloud. The 4-byte checksum at the end catches typos before you send funds into the void.

Version Bytes

The first byte of a P2PKH address indicates the network:

• 0x00 → Mainnet (addresses start with “1”)
• 0x6f → Testnet (addresses start with “m” or “n”)

P2PKH remains universally supported. Every Bitcoin wallet, exchange, and service can send to and receive from these addresses. The tradeoff is higher transaction fees compared to SegWit formats.

P2SH: Script Hash Addresses (Starting with “3”)

Pay-to-Script-Hash, activated on April 1, 2012 via BIP16, enabled a fundamental shift in how Bitcoin transactions could work. Instead of paying to a public key hash, you pay to the hash of a script—arbitrary spending conditions that only get revealed when the funds are spent.

The Battle for P2SH

P2SH’s activation wasn’t smooth. It sparked Bitcoin’s first major developer conflict, with competing proposals:

• BIP12 (OP_EVAL): More powerful but raised security concerns
• BIP16 (P2SH): Gavin Andresen’s proposal, ultimately adopted
• BIP17 (OP_CHECKHASHVERIFY): Luke Dashjr’s alternative

The resolution came through miner voting. Miners signaled support by including “/P2SH/” in their coinbase transactions. When enough blocks contained this signal, P2SH activated. The first P2SH transaction appeared in block 170,052 on March 7, 2012.

What P2SH Enabled

The primary use case was multi-signature wallets. A 2-of-3 multisig address, for example, requires any two of three designated keys to spend. The sender doesn’t need to know about this complexity—they just send to a “3” address like any other payment.

P2SH also shifted the fee burden. The complex redeem script is only revealed (and paid for) when spending, not when receiving. This made it practical to create sophisticated spending conditions without penalizing the sender.

Version Bytes

• 0x05 → Mainnet (addresses start with “3”)
• 0xc4 → Testnet (addresses start with “2”)

SegWit: The Blocksize War and Its Resolution

By 2015, Bitcoin faced a scaling crisis. Blocks were filling up, fees were spiking, and the community fractured into opposing camps. One side wanted larger blocks; the other wanted off-chain scaling solutions like Lightning Network.

Segregated Witness (SegWit), proposed by Pieter Wuille in BIP141, offered a path forward. By separating signature data from transaction data, SegWit fixed transaction malleability (required for Lightning), increased effective block capacity, and reduced fees for adopters.

The UASF Showdown

Miners blocked SegWit activation for over a year. The required 95% signaling threshold seemed unreachable. Then came BIP148—the User Activated Soft Fork.

Proposed by the pseudonymous developer “Shaolinfry,” BIP148 set a deadline: August 1, 2017. After that date, nodes running BIP148 would reject any block that didn’t signal for SegWit, regardless of proof-of-work validity. Users, not miners, would enforce consensus.

The threat worked. Miners capitulated via BIP91, which activated on July 23, 2017. SegWit locked in on August 9 and activated on August 24 at block 481,824. August 1st is now commemorated as “Bitcoin Independence Day”—the moment users demonstrated that miners don’t control Bitcoin’s rules.

Bitmain’s response was the “User Activated Hard Fork” (UAHF), which became Bitcoin Cash on August 1, 2017.

P2WPKH: Native SegWit (Addresses Starting with “bc1q”)

Native SegWit addresses, defined in BIP173, use Bech32 encoding—a completely new format designed by Pieter Wuille and Greg Maxwell.

Bech32: Better by Design

Bech32 addresses are:

• Case insensitive: No more confusion between similar uppercase and lowercase letters
• QR code optimized: Uses alphanumeric mode for more compact QR codes
• Error detecting: BCH codes can detect up to 4 errors and locate their positions
• Human-readable prefix: “bc” for mainnet, “tb” for testnet, clearly separated by “1”

The character set—qpzry9x8gf2tvdw0s3jn54khce6mua7l—was chosen to minimize visual ambiguity and optimize error detection properties. The “1” character only appears as the separator between the human-readable part and the data.

Fee Savings

SegWit introduced “weight” instead of raw bytes for fee calculation:

• Non-witness data: 4 weight units per byte
• Witness data (signatures): 1 weight unit per byte

Since signatures are the largest component of most transactions, P2WPKH typically saves around 38% on fees compared to P2PKH.

P2WSH: SegWit Script Hash

P2WSH is the SegWit equivalent of P2SH—it enables complex scripts with SegWit’s fee benefits. Addresses also start with “bc1q” but are longer (using a 32-byte SHA256 hash instead of 20-byte RIPEMD160).

Nested SegWit: The Transition Format (Addresses Starting with “3”)

When SegWit launched, many wallets and exchanges couldn’t send to bc1 addresses. Wrapped (or nested) SegWit provided a migration path: a P2WPKH script wrapped inside a P2SH address.

The result looks like a regular “3” address to legacy software but still provides SegWit benefits for the spender. The tradeoff is slightly higher fees than native SegWit due to the P2SH wrapper overhead.

Nested SegWit served its purpose during the transition period. With bc1 support now widespread, native SegWit is preferred.

The Bech32 Bug and Bech32m

After SegWit deployed, researchers discovered an unexpected weakness in Bech32:

Whenever the final character is a ‘p’, inserting or deleting any number of ‘q’ characters immediately preceding it does not invalidate the checksum.

For witness version 0 (P2WPKH and P2WSH), this didn’t matter—those formats require exactly 20 or 32 bytes, so any length change from q-insertion would fail validation anyway.

But Taproot would use witness version 1, and future versions might allow variable-length programs. BIP350 introduced Bech32m with a modified checksum constant to eliminate this weakness.

The rule:

• Witness v0 (bc1q): Bech32
• Witness v1+ (bc1p): Bech32m

P2TR: Taproot (Addresses Starting with “bc1p”)

Taproot, activated on November 14, 2021, represents the most significant Bitcoin upgrade since SegWit. Defined across BIP340 (Schnorr signatures), BIP341 (Taproot), and BIP342 (Tapscript), it fundamentally changes what’s possible on Bitcoin.

Schnorr Signatures

Taproot replaces ECDSA with Schnorr signatures, which offer:

• Key aggregation: Multiple signers can produce a single signature indistinguishable from a single-signer transaction
• Batch verification: Verify many signatures faster than individually
• Smaller signatures: 64 bytes vs ~72 for ECDSA
• Provable security: Formal security proofs (ECDSA lacks these)

MAST: Merkelized Alternative Script Trees

Complex spending conditions can be organized as a Merkle tree. When spending, only the executed branch is revealed—unused conditions remain private forever.

Consider a 3-of-5 multisig with a timelock escape clause allowing a single key to spend after one year. Under P2SH, the entire script is revealed regardless of which condition is used. Under Taproot, if the 3-of-5 condition is met, the transaction looks identical to a single-signature spend. The timelock escape clause is never revealed.

Privacy Implications

This is the real win. All Taproot key-path spends look identical on chain—a single 64-byte signature. You can’t distinguish:

• Single-sig from multi-sig
• Hot wallet from cold storage
• Simple payment from complex contract

When the most common spending path is used cooperatively, blockchain analysis becomes significantly harder. This improves fungibility—the property that all bitcoins should be equally acceptable regardless of their history.

Activation: Speedy Trial

Unlike the contentious SegWit activation, Taproot used “Speedy Trial”—a 3-month signaling window with a 90% miner threshold. If miners signaled, activation would lock in for November. They did, overwhelmingly.

Fee Comparison

For a typical single-input, two-output transaction:

Taproot’s fee advantage comes from Schnorr’s smaller signatures and the elimination of the public key from the witness.

Compatibility Matrix

Not all wallets and services support all address types:

If you’re having trouble sending to a bc1 address, the sender’s wallet is outdated. Native SegWit support has been standard since 2019.

Which Should You Use?

For most users: Native SegWit (bc1q) offers the best balance of fee savings and compatibility.

For privacy-conscious users: Taproot (bc1p) provides superior privacy when counterparties support it.

For maximum compatibility: P2SH or P2PKH if you absolutely must interact with legacy systems, though this is increasingly rare.

For multisig: P2WSH or P2TR depending on your privacy requirements and wallet support.

Security Notes

Address Reuse

Don’t reuse addresses. Every time you spend from an address, you reveal the public key. Before spending, the address only contains a hash—the public key remains private. After spending, attackers have more information to work with if elliptic curve cryptography is ever broken.

Studies show 30-40% of Bitcoin addresses have been reused despite this advice. Don’t be part of that statistic.

Quantum Computing

P2PK outputs (old Satoshi-era coins) are most vulnerable since the public key is already exposed. P2PKH, P2WPKH, and P2TR are protected until first spend. Current estimates suggest practical quantum attacks are 10-20+ years away, but migration planning should start well before then.

Conclusion

Bitcoin’s address formats tell the story of the protocol’s evolution—from Satoshi’s simple P2PK transactions to the privacy-preserving Taproot outputs we have today. Each generation solved specific problems: P2PKH added checksums and hashing, P2SH enabled complex scripts, SegWit fixed malleability and reduced fees, and Taproot brought Schnorr signatures with unprecedented privacy.

Understanding these formats isn’t just technical trivia. It affects your fees, your privacy, and your security. Choose your address format deliberately.

Related Tools & Resources

Bitcoin Address Validator & Analyzer — Validate any Bitcoin address and see its type, network, and decoded data. Runs entirely in your browser.

Crypto Tools Directory — More Bitcoin and cryptocurrency tools including unit converters, protocol references, and more.