Bech32m

Bech32m is the address encoding specified in BIP350 and used for every Segregated Witness output of version 1 or higher, which in practice means every Pay-to-Taproot address you have ever seen beginning with bc1p. It is a deliberate, minimal revision of the original Bech32 format: the character set, the human-readable prefix, and the overall structure are identical, and the only change lives in the checksum. That one-constant change closed a real malleability weakness before Taproot adoption could expose it at scale.

The flaw Bech32m fixes

The original Bech32 checksum, defined in BIP173, had an unexpected property discovered after deployment: if the final data character of an address was p, an attacker or a copy-paste accident could insert or delete any number of q characters immediately before it and the checksum would still validate. A mangled address could therefore pass a wallet's validity check while pointing at a different, likely unspendable output. For SegWit v0 the practical exposure was limited because those programs have fixed lengths, but future witness versions were meant to allow variable-length programs, and shipping Taproot on a checksum with a known insertion bug was not acceptable to protocol engineers.

Bech32m's entire fix is to change the constant XORed into the checksum at the final step: Bech32 uses 1, Bech32m uses 0x2bc830a3. That single substitution eliminates the insertion/deletion weakness while preserving the format's strong guarantees against character substitution errors — the property that makes a fat-fingered address overwhelmingly likely to be rejected rather than paid.

Which encoding applies where

The rule wallets follow is clean and mechanical. Witness version 0 outputs — P2WPKH and P2WSH, the bc1q addresses — continue to use original Bech32 exactly as before. Witness versions 1 through 16 use Bech32m, so Taproot outputs encode as bc1p, and any future SegWit version will inherit Bech32m automatically. An address encoded with the wrong checksum variant for its witness version is invalid, full stop: a v1 program under a plain Bech32 checksum must be rejected, and a v0 program under Bech32m likewise. Sending software therefore has to implement both checksums and select by witness version; there is no user-facing choice involved.

Why it matters when funds are at stake

Address checksums are the last line of defense between a transcription error and irreversible loss. Bitcoin transactions cannot be recalled, so the encoding layer is engineered to make every plausible human error — a misread character, a truncated paste, a QR scan glitch — produce an invalid string instead of a valid-looking address that silently burns coins. Bech32m guarantees detection of any single substitution error and catches other error patterns with overwhelming probability, and unlike the mixed-case Base58 legacy format it is case-insensitive, more compact in QR codes, and easier to read aloud or compare visually.

For a sovereign Bitcoiner the operational takeaways are simple. First, bc1q and bc1p are different animals: the former is SegWit v0 under Bech32, the latter is Taproot under Bech32m, and a wallet or exchange that supports one does not necessarily support the other — Bech32m send support lagged for years after activation in November 2021. Second, if a service rejects your bc1p address, the failure is in their software, not your address. Third, when you verify a receive address on a hardware wallet screen, the checksum has already done the heavy lifting; your job is confirming the address belongs to your device, a habit that matters for anyone stacking mining payouts into cold storage. The encoding protects you from mistakes — verification protects you from malware.

One last practical detail: Bech32m is an encoding, not a script type. The address is just a transport format for a witness version and a program; nothing about Bech32m itself changes fees, privacy, or spending rules — those come from the Taproot output it typically carries. But the encoding layer is where user error is caught or missed, which is why BIP350's authors treated a one-constant checksum fix as worth an entire specification. In a system with no chargebacks and no customer service desk, the humble checksum is consumer protection implemented in mathematics — exactly the kind of protection that scales without asking anyone's permission.