A bech32 address encodes a script, not an account number

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

What an address format has to survive

An address is not an account; it is an encoded instruction for spending, plus a checksum to catch a copying mistake. The BIP173 specification, assigned 20 March 2017, sets out why the existing Base58Check format strained under segregated witness addresses: it needs a lot of space in QR codes, its mixed case is inconvenient to reliably write down, type on mobile keyboards, or read out loud, and its checksum offers no real error-detection guarantee because Base58's 58-character alphabet is not the kind of size established error-detection research covers. Bech32 instead uses a human-readable prefix, such as `bc` for mainnet, a separator, and a base32 data part whose final six characters are a purpose-built checksum.

A second fix three years later

Bech32 was not quite finished. The BIP350 specification, assigned 16 December 2020, identifies an unexpected weakness: whenever the final character is a 'p', inserting or deleting any number of 'q' characters immediately preceding it does not invalidate the checksum. That flaw was tolerable for the fixed-length version-0 witness programs BIP173 covers, but future witness versions with variable-length programs could be manipulated by exactly that insertion. BIP350 keeps Bech32 for existing version-0 addresses and defines a new checksum constant, replacing 1 with 0x2bc830a3, for witness versions one through sixteen, calling the result Bech32m.

Why the distinction is not cosmetic

What a wallet's address book accepts, and generates, says something concrete about what it supports. An address beginning `bc1q` is a version-0 witness program checked with the original Bech32 checksum; one beginning `bc1p` is a later witness version checked with Bech32m. The transactions guide's account of earlier formats, pay-to-pubkey-hash and the 2012 pay-to-script-hash standard, is a reminder that Bitcoin has changed its address encoding more than once for reasons of capability, not branding; a wallet that cannot generate or validate a given prefix is disclosing a real limitation on what it can spend from or send to, not merely an aesthetic gap.

Questions to carry forward

• Does a service quoting support for any address specify which witness versions and checksum variants it actually validates?
• Is an address failing validation being rejected for a genuine typo, or for a prefix the software simply predates?
• Has a claimed fix for the Bech32 insertion weakness been checked against BIP350's replacement constant, rather than assumed?

Two specification decisions, three years apart, both concerned with the same narrow question: whether a copying error gets caught before funds are sent to a script nobody can spend from.