Bech32 and Bech32m

The layout

A Bech32 string has a human-readable part (bc for Bitcoin, tb for testnet, ltc for Litecoin, cosmos, addr …), the separator 1, the data, and 6 checksum characters. The data uses 32 characters: qpzry9x8gf2tvdw0s3jn54khce6mua7l — no 1, b, i or o.

For a SegWit address the first data character is the witness version: q is version 0, p is version 1 (Taproot).

A checksum that finds the error

The checksum is a BCH code. BIP-173 states that it detects any error affecting up to 4 characters, and the chance that a random longer error passes is under 1 in a billion. Because it is a code rather than a hash, a single wrong character can be located: the checker tries each position and reports the one where a change makes the checksum match.

Why Bech32m exists

BIP-350 found a weakness: if a Bech32 string ends in p, inserting or deleting q characters right before it can leave the checksum valid. For version 0 the fixed lengths (20 or 32 bytes) catch this. For later versions they would not, so BIP-350 changed one constant in the checksum (0x2bc830a3 instead of 1). Version 0 keeps Bech32, version 1 and later must use Bech32m.

Practical effect: a bc1p… address with a Bech32 (old) checksum is invalid, and software that only knows Bech32 rejects every Taproot address. That is the common “bc1p not supported” error.

One case only

Bech32 may be all lower case or all upper case (upper case is used in QR codes because it encodes more compactly), never mixed.