Skip to content
buybitcoinsmart

Glossary / Addresses & keys

Bech32m

Definition
Bech32m fixes a flaw in bech32 by changing one constant in the checksum, and every Taproot address starting bc1p uses it instead of the original encoding.

Specified in BIP-350.

The flaw is narrow but real. Whenever a bech32 string ends in the character "p", inserting or deleting any number of "q" characters immediately before that final letter leaves the checksum valid, so a mangled address can pass the check. BIP-350 closes the hole by combining 0x2bc830a3 into the checksum where bech32 combined the value 1.

How it works

Bech32m is bech32 with one number changed. The encoder expands the human readable prefix, appends the data, runs the same BCH polynomial over the result, and then differs only at the last step, where the output is combined with 0x2bc830a3 rather than with 1. Everything a reader can see stays the same: the same 32-character alphabet, the same "1" separator, the same six checksum characters, the same 90-character ceiling.

Changing the constant is not a side effect. It is the mechanism. Because the two schemes disagree, a bech32m string fails a bech32 checksum test and a bech32 string fails a bech32m one, so old software rejects new addresses outright instead of half-understanding them. BIP-350 describes this as a deliberate compatibility break, chosen over silently patching bech32 in place.

The dividing line is the witness version. Witness version 0, meaning the bc1q addresses for single keys and scripts, keeps bech32. Witness versions 1 through 16 use bech32m. Only version 1 is defined today, as Taproot, so in practice bech32m means bc1p. The rule was written to cover versions that do not exist yet, which is why a correct wallet checks the version number rather than the address prefix.

Where you see it

A bc1p receive address is bech32m, 62 characters long, encoding a 32-byte key. On test networks the same outputs appear as tb1p. Taproot outputs became spendable at block 709,632 on November 14, 2021, which is the point from which bech32m addresses started carrying real value on mainnet.

Bitcoin Core implemented BIP-350 in version 22.0, and from that release every remote procedure call that takes an address requires bech32m for witness version 1 and above. Version 23.0 went further: newly created descriptor wallets get a tr() descriptor automatically, so they hand out bc1p addresses without being asked.

Practical friction shows up at the withdrawal screen. Some platforms still refuse bc1p destinations because their address validator understands bech32 but not the newer constant. Nothing is wrong with your wallet in that case, and a bc1q address from the same seed lands the coins in the same wallet.

Bech32m vs P2TR

Bech32m is an encoding and P2TR is an output type, and they line up today only because of a coincidence of timing. Bech32m says how to write down any witness program of version 1 or higher as text. P2TR says what a version 1 program means: a 32-byte tweaked public key spendable by a Schnorr signature or by revealing a script. Every bech32m address in circulation encodes a P2TR output, but that stops being true the moment witness version 2 is assigned to anything, since those addresses would also be bech32m and would not be Taproot.

Not to be confused with

Frequently asked questions

Do I need to do anything about bech32m?

No. Your wallet handles the encoding. The only place it becomes visible is a service that rejects bc1p destinations, and the answer there is to withdraw to a bc1q address from the same wallet.

Why create a second format instead of fixing bech32?

Because a silent fix would leave old and new software disagreeing about which addresses are valid. Changing the checksum constant makes the two encodings mutually invalid, so outdated wallets refuse a bech32m address outright rather than misreading it.

Read next

Related terms

More in Addresses & keys