Standard Scripts & Address Types (P2PK → P2TR)

People say “send Bitcoin to this address,” but Bitcoin has no concept of an address at the protocol level — only outputs with locking scripts. An address is a user-facing shorthand: a compact, error-checked encoding that tells a sender’s wallet which kind of lock to build and what to put in it. This page traces the standard lock shapes from the original P2PK to modern Taproot, and shows what each address string actually commits to.

An address is a commitment to a locking script

When you hand someone an address, you are really saying: “build an output whose scriptPubKey is of type X, committing to my key/script Y.” The wallet decodes the address, recognizes the type from its prefix and encoding, and constructs the matching lock. The address never travels onto the chain — only the scriptPubKey it described does.

   address (you give this out)
        │  decode + error-check
        ▼
   "type + committed key/script hash"
        │  wallet builds
        ▼
   scriptPubKey (this is what's stored on-chain)

Two encodings dominate. Base58Check (legacy, leading 1 or 3) and Bech32 / Bech32m (SegWit and Taproot, bc1...). The encoding details — checksums, character sets, why typos are caught — live in addresses & encoding.

The evolution of standard scripts

Each new type was introduced to fix a shortcoming of the last: smaller, safer, more private, or more flexible.

P2PK — Pay to Public Key

The original. The lock is simply <pubKey> OP_CHECKSIG — “sign for this exact public key.” It has no short address form (the raw key is large) and exposes the public key on-chain immediately. Used in the earliest blocks; essentially obsolete today.

P2PKH — Pay to Public-Key-Hash

The classic 1... address. The lock commits to the hash of the public key: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. Smaller than P2PK and the raw key stays hidden until spending. This is the script we stepped through.

P2SH — Pay to Script-Hash

The 3... address. Instead of committing to a key, the lock commits to the hash of an entire redeem script: OP_HASH160 <scriptHash> OP_EQUAL. The spender later reveals the full script and satisfies it. This is what made complex locks (multisig, escrow) usable as ordinary-looking addresses — the sender doesn’t need to know or pay for the complicated script; the recipient reveals it only when spending.

P2WPKH — Pay to Witness-Public-Key-Hash (SegWit v0)

The bc1q... address. Functionally P2PKH, but the unlocking data (signature + key) moves into the witness rather than scriptSig. This fixed transaction malleability and made the signature cheaper, because witness bytes are discounted when computing transaction weight. (Its sibling P2WSH is the SegWit version of P2SH for arbitrary scripts.)

P2TR — Pay to Taproot

The bc1p... address. Taproot commits to either a single (Schnorr) public key or a hidden tree of alternative spending scripts — and lets the common “just one key” case look identical to any other Taproot spend on-chain, revealing the extra scripts only if they’re used. The result is better privacy and cheaper, more flexible contracts. The cryptography (Schnorr signatures, key aggregation) is covered in Taproot, Schnorr & MuSig.

Comparison table

Type	Address prefix	Encoding	Commits to	Introduced for
P2PK	(no address)	—	a raw public key	the original coinbase payouts
P2PKH	1...	Base58Check	hash of a public key	smaller addresses, hide key until spend
P2SH	3...	Base58Check	hash of a redeem script	arbitrary locks as simple addresses
P2WPKH	bc1q...	Bech32	hash of a public key (in witness)	malleability fix, cheaper signatures
P2WSH	bc1q... (longer)	Bech32	hash of a witness script	SegWit version of P2SH
P2TR	bc1p...	Bech32m	a Schnorr key or script tree	privacy, flexibility, cheaper contracts

The prefix is a real consensus distinction, not cosmetic

A 1..., 3..., bc1q... and bc1p... address build genuinely different scriptPubKeys with different validation rules. Sending to the wrong type, or to a chain that doesn’t recognize a newer type, can result in unspendable coins. The Bech32/Bech32m checksums exist precisely so a mistyped character is rejected before funds are sent.

Why so many types? Soft forks.

Each newer type (P2SH, SegWit, Taproot) was rolled out as a soft fork, designed so that old nodes still see the spends as valid (often as “anyone-can-spend” outputs they choose not to enforce), while upgraded nodes enforce the real, stricter rules. That backward-compatible upgrade path is how Bitcoin evolves without splitting the ledger — see soft forks & anyone-can-spend.

The thread

How do address types help untrusting strangers agree on one ledger? An address compresses “here is exactly the lock to put on my coins, with a checksum so you can’t get it wrong” into a string a stranger can paste. The sender doesn’t need to trust the recipient about how the funds will be guarded — the address itself, once decoded, fully and verifiably specifies the on-chain scriptPubKey that every node will independently enforce. And because each new type is a backward-compatible soft fork, the network can adopt better locks over time while every node — old or new — still agrees on one history. The address is the handshake; the script is the contract; consensus is the enforcement.

Check your understanding

1. Why does Bitcoin have “no addresses” at the protocol level, and what does an address actually encode?
2. What does P2SH commit to that P2PKH does not, and why was that useful?
3. What changed between P2PKH and P2WPKH, and which two problems did the change address?
4. Match each prefix — 1..., 3..., bc1q..., bc1p... — to its script type.
5. How do soft forks let Bitcoin introduce new address types without splitting the ledger?