Bitcoin address types: why some start with 1, some with 3, and some with bc1

An address is a checksummed destination, not an account

A Bitcoin address is a short string of letters and numbers that tells a wallet where to send coins. The Bitcoin Wiki describes the classic form as “an identifier of 26-35 alphanumeric characters” and is careful about what it is not: addresses “are not wallets nor accounts, and do not carry balances. They only receive funds.” A transaction has no “from” address in the protocol; it spends specific earlier outputs, which our article on UTXOs explains.

Under the hood, every address encodes a spending condition (a hash of a public key, or a hash of a script) plus a checksum, a few extra characters computed from the rest so that a typo is rejected rather than sending coins into the void. The formats differ in how they encode that, and the first character or two tells you which format you are looking at. That prefix is the whole subject of this article.

This page shows prefixes only, never a full address. The site keeps real, checksum-verified examples of every format in the wallet library, each attached to a documented history, and that is the place to look at one.

Addresses starting with 1: the original pay-to-public-key-hash format

The oldest format, called P2PKH for pay-to-public-key-hash, uses an encoding called Base58Check. The wiki notes that it uses “random digits and uppercase and lowercase letters, with the exception that the uppercase letter ‘O’, uppercase letter ‘I’, lowercase letter ‘l’, and the number ‘0’ are never used,” to avoid look-alike characters. Most such addresses are 34 characters; some are shorter. On the main network the encoded result always begins with the digit 1.

These addresses are case-sensitive. The wiki warns that if a character is not transcribed exactly, “including capitalization,” the address will be rejected. That is a feature (the checksum catches the mistake) and an annoyance (reading one aloud is painful), and the annoyance is what later formats set out to fix. Addresses from Bitcoin’s first years, including the ones tied to the earliest entries in the wallet library, are written this way, and they still work.

Addresses starting with 3: pay to a script, not a person

In October 2011 Gavin Andresen proposed BIP13, a new address type that would represent “the encoded hash of a script, rather than the encoded hash of an ECDSA public key.” The main network uses version byte 5 for these, which after encoding produces addresses beginning with the character 3. The companion proposal, BIP16 (pay to script hash), dated 3 January 2012, set the rule that the person redeeming the coins, not the person sending them, supplies the script, so that a sender can fund “any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code.” The new rules applied to blocks timestamped from 1 April 2012.

The original motivation was escrow and multi-signature: an address where two of three keys must sign, say, without the sender needing to know or care. Later the format got a second life. When Segregated Witness arrived, BIP141 allowed the new witness scripts to be wrapped inside a P2SH address so that older wallets, which could not parse the new format, could still pay SegWit users. Bitcoin Core made that wrapped form its default address type in version 0.16.0, released 26 February 2018.

So an address starting with 3 tells you only that a script is behind it. It might be a multi-signature vault, a wrapped SegWit key, or something else. The prefix does not say which; the script is revealed only when the coins are spent.

Addresses starting with bc1q: native SegWit and the bech32 format

Segregated Witness, BIP141, was proposed in December 2015 by Eric Lombrozo, Johnson Lau and Pieter Wuille. It moved signature data into a separate structure called the witness, which fixed a long-standing problem called transaction malleability and changed how block space is counted. It also defined two new output types: pay-to-witness-public-key-hash, with a 20-byte program, and pay-to-witness-script-hash, with a 32-byte one. Those needed an address format of their own.

BIP173, by Pieter Wuille and Greg Maxwell and dated 20 March 2017, supplied it, and its motivation reads like a list of complaints about Base58: “the mixed case in base58 makes it inconvenient to reliably write down, type on mobile keyboards, or read out loud,” it “needs a lot of space in QR codes,” and its checksum “has no error-detection guarantees.” The replacement, bech32, has three parts: a human-readable prefix, bc for the main network and tb for the test network; a separator, which is always the digit 1; and the data. The data alphabet drops 1, b, i and o to avoid confusion, and encoders must output lowercase only.

The checksum is the real upgrade. BIP173 guarantees “detection of any error affecting at most 4 characters,” with less than a one in a billion chance of missing a larger error. The first data character encodes the witness version, and in the bech32 alphabet the value 0 is written q, which is why every native SegWit address begins bc1q. Version 0 addresses are always 42 or 62 characters long. Bitcoin Core added “full support for native segwit addresses (BIP173 / Bech32)” in version 0.16.0, in February 2018.

Addresses starting with bc1p: Taproot and the bech32m fix

Bech32 turned out to have a flaw. BIP350, by Pieter Wuille and dated 16 December 2020, describes it: “whenever the final character is a ‘p’, inserting or deleting any number of ‘q’ characters immediately preceding it does not invalidate the checksum.” Version 0 addresses were safe because their lengths are fixed, but future versions would not be. The fix, bech32m, changes one constant in the checksum calculation. The rule became: “If its witness version is 0, encode it using Bech32. If its witness version is 1 or higher, encode it using Bech32m.”

Witness version 1 is Taproot, defined in BIP341 by Pieter Wuille, Jonas Nick and Anthony Towns. A Taproot output is a 32-byte program that is itself a public key, spendable either directly with a Schnorr signature (the key path) or by revealing one of several scripts committed to in a Merkle tree (the script path). On the main network the rules activated at block 709,632, after a signaling period that began on 24 April 2021 with a 90% miner threshold. Our Taproot explainer covers what it changed.

In the bech32 alphabet the value 1 is written p, so a Taproot address begins bc1p. Otherwise it looks like its bc1q sibling: same prefix, same separator, lowercase, and a checksum that catches typos. Software that only understands bech32 will reject a bech32m address rather than mis-send to it, which is the point.

All four formats are valid, and coins move freely between them

An address format describes the receiver’s lock, not the sender’s. A wallet holding coins at a legacy address can pay a bc1p address and vice versa; the only requirement is that the sending software knows how to encode the destination. The site’s wallet pages carry examples of every era, from the reward of the genesis block onward.

Two habits follow from the formats. First, copy addresses rather than retyping them; bech32 addresses were designed to be read aloud and are case-insensitive, which the wiki notes, while old-style addresses are not. Second, use a fresh address for each payment. The wiki recommends that “a unique invoice should be used for each transaction,” and modern wallets, built on the seed-phrase standards described in our keys article, generate new ones at no cost.