Bech32 vs Bech32m (BIP 173 vs BIP 350)
Bech32 (BIP 173) and Bech32m (BIP 350) are the same address format with one difference: the constant mixed into the checksum, 1 for Bech32 and 0x2bc830a3 for Bech32m. Bech32 is used for SegWit version 0 addresses (bc1q...), and Bech32m for version 1 and later, including Taproot (bc1p...).
Updated · 3 min read
At a glance
| BIP 173 | BIP 350 | |
|---|---|---|
| Title | Base32 address format for native v0-16 witness outputs | Bech32m format for v1+ witness addresses |
| Status | Deployed | Deployed |
| Type | Informational | Specification |
| Assigned | 2017-03-20 | 2020-12-16 |
| Authors | Pieter Wuille, Greg Maxwell | Pieter Wuille |
| In plain English | Introduces Bech32, an address format for native SegWit outputs, recognizable by addresses starting with "bc1". It uses only lowercase letters and numbers and a strong checksum that catches typing mistakes, making addresses easier to read, type, and scan as QR codes. | Introduces Bech32m, a corrected version of the Bech32 address format used for SegWit addresses (those starting with 'bc1'). A subtle flaw in Bech32 could let certain typos go undetected, so Bech32m is used for Taproot and later address types to keep address error-checking reliable. |
What BIP 173 introduced
BIP 173, by Pieter Wuille and Greg Maxwell, defined Bech32, a checksummed base32 format, and used it for native SegWit addresses. A Bech32 string has three parts: a human-readable part (bc on mainnet, tb on testnet), the separator 1, and a data part drawn from 32 characters that leave out 1, b, i and o. The last six characters are a BCH checksum that guarantees detection of any error affecting at most 4 characters, with less than a 1 in 10^9 chance of missing larger errors. The first data character is the witness version, which is why version 0 addresses start with bc1q (q encodes 0).
Compared with Base58Check, Bech32 avoids mixed case, is more compact in QR codes when written in uppercase, and has error-detection guarantees rather than a truncated hash.
The flaw that Bech32m fixes
Bech32 turned out to have an unexpected weakness: whenever the final character is p, inserting or deleting any number of q characters immediately before it does not invalidate the checksum. Version 0 addresses were protected, because BIP 141 only allows 20-byte or 32-byte version 0 programs, so their addresses are always 42 or 62 characters. Later witness versions are not limited to those two lengths.
BIP 350, by Pieter Wuille, defines Bech32m: the same algorithm with the constant XORed into the checksum changed from 1 to 0x2bc830a3. That single change removes the insertion weakness while keeping Bech32's guarantees for substitution errors. BIP 350's appendix explains how the new constant was chosen.
Bech32 vs Bech32m compared
| Bech32 (BIP 173) | Bech32m (BIP 350) | |
|---|---|---|
| Checksum constant | 1 |
0x2bc830a3 |
| Used for | Witness version 0 | Witness versions 1 to 16 |
| Address types | P2WPKH, P2WSH | P2TR (version 1) and future versions |
| Mainnet address starts with | bc1q |
bc1p for Taproot |
| Character set, prefixes, separator | 32 characters, bc/tb, 1 |
Unchanged |
| Maximum string length | 90 characters | 90 characters |
| Common address lengths | 42 (P2WPKH) or 62 (P2WSH) | 62 (P2TR) |
q-insertion weakness |
Present (harmless at version 0 lengths) | Fixed |
No string can be valid under both checksums, so a decoder always knows which one it is reading.
How BIP 350 relates to BIP 173
BIP 350 amends BIP 173 rather than retiring it, which is why it is recorded as replacing BIP 173: the rules for version 1 and later addresses changed, while version 0 addresses still use Bech32 exactly as before. A compliant decoder checks both constants and then confirms the result matches the witness version, Bech32 for version 0 and Bech32m for everything else. A version 0 address with a Bech32m checksum, or a bc1p address with a Bech32 checksum, is invalid.
The switch was deliberately not forward-compatible. Old BIP 173 software rejects Bech32m addresses instead of sending to them. BIP 350 explains why that is a feature: experiments had found wallets that would have burned funds when sending to version 1 addresses, and with Bech32m such software refuses instead.
Which one applies to you?
- Address starts with
bc1q: Bech32, SegWit version 0. - Address starts with
bc1p: Bech32m, Taproot. - Your wallet calls a
bc1paddress invalid: it implements BIP 173 but not BIP 350. Update it or use another wallet. - Writing software: implement both, and follow BIP 350's advice to accept all versions from 1 to 16 as valid destinations, so future soft forks don't require wallet upgrades just to send.
The address checker shows which encoding an address uses, and the address types guide covers every format. For the protocol change behind bc1p, see SegWit vs Taproot.
Frequently asked questions
What is the difference between Bech32 and Bech32m?
Only the checksum constant. Bech32 (BIP 173) XORs the constant 1 into its checksum; Bech32m (BIP 350) uses 0x2bc830a3. The character set, the bc and tb prefixes, the separator and the maximum length are unchanged. Bech32 encodes SegWit version 0 addresses, and Bech32m encodes version 1 and later, such as Taproot.
Why do Taproot addresses use Bech32m instead of Bech32?
Bech32 has an insertion weakness: if a string ends in p, adding or removing q characters right before it leaves the checksum valid. Version 0 addresses are safe because they come in only two lengths, but version 1 and later aren't limited that way. BIP 350 changed the constant so Taproot (bc1p) addresses keep full error detection.
Is a bc1p address Bech32 or Bech32m?
Bech32m. The p after bc1 is the character for witness version 1, and BIP 350 requires all version 1 to 16 addresses to use Bech32m. Addresses starting with bc1q are version 0 and use Bech32. A bc1p string with a Bech32 checksum is invalid, and correct decoders reject it.
Why can't my wallet send to a bc1p address?
It probably supports BIP 173 Bech32 but not BIP 350 Bech32m, so the Taproot address fails its checksum check. That is by design: BIP 350 made the break deliberate so outdated software refuses to send rather than risk sending to an output it doesn't understand. Update the wallet, or ask the recipient for a bc1q address.
Can a string be valid in both Bech32 and Bech32m?
No. BIP 350 notes that no string can be valid Bech32 and Bech32m at the same time, so each format's valid test vectors double as invalid examples for the other. A decoder can check against both constants, know unambiguously which encoding was used, and then confirm it matches the witness version.