Addresses and encodings: Base58Check, Bech32, Bech32m

Wonder

1. Why does a single character change in an address almost always break it, yet some typos slip through?
2. How can a string of letters and numbers act as a map to a specific locking script without storing that script on the chain?
3. What can Bech32 guarantee about typos that Base58Check can only make unlikely?

Explore

1. An address is not an object stored in the UTXO set; it is a human-friendly encoding of an output script. The chain stores only bytes, but software translates them into strings for humans to read and type. This translation layer must prevent transcription errors, because a mistyped address that still looks valid can send funds to the wrong place. Satoshi’s original design, Base58Check, addressed this by using an alphabet of 58 characters that omits the visually ambiguous ‘0’, ‘O’, ‘I’, and ‘l’.
2. Base58Check encodes a version byte, the payload (such as a 20-byte hash), and a four-byte checksum. The checksum is derived from the first four bytes of the double SHA-256 hash of the preceding data. Legacy Pay-to-Public-Key-Hash (P2PKH) addresses use version byte 0x00, resulting in strings starting with ‘1’. Pay-to-Script-Hash (P2SH) uses version byte 0x05, yielding strings starting with ‘3’. This structure allows wallets to verify integrity before accepting an address.
3. Segregated Witness (SegWit), activated in August 2017 at block 481,824, introduced native witness outputs that required a new encoding. Base58Check was ill-suited for the longer data structures and specific error patterns of SegWit. Pieter Wuille and Greg Maxwell proposed Bech32 in BIP-173 (2017). It uses a restricted character set of 32 characters—digits and lowercase letters excluding ‘1’, ‘b’, ‘i’ and ‘o’, with ‘1’ reserved as a separator. A single case avoids ambiguity and suits QR codes.
4. Bech32 addresses begin with the human-readable part ‘bc’ and the separator ‘1’, followed by data and a six-character checksum. This checksum is based on Bose-Chaudhuri-Hocquenghem (BCH) codes, which are significantly stronger than Base58Check’s SHA-256-derived checksum. The BCH code guarantees detection of any error affecting up to four characters and can often locate the position of typos. Native SegWit v0 addresses (P2WPKH and P2WSH) use this format, starting with ‘bc1q’.
5. Developers later identified a weakness in the original Bech32 polynomial: inserting or deleting specific character sequences could result in a valid but different address. To fix this without breaking existing v0 addresses, BIP-350 (2020) introduced Bech32m. It changes one constant in the checksum calculation so that insertions and deletions of this kind are detected. Taproot addresses (SegWit version 1), activated in November 2021, use Bech32m and start with ‘bc1p’.
6. Testnet addresses use the prefix ‘tb1’ instead of ‘bc1’. The data portion encodes the witness program: a hash of a public key or script for SegWit version 0, or a 32-byte tweaked public key for Taproot. When software scans a QR code or accepts manual input, it runs the BCH polymod function to verify integrity. Open a block explorer and locate one address of each type: a legacy P2PKH starting with ‘1’, a SegWit v0 starting with ‘bc1q’, and a Taproot address starting with ‘bc1p’. Note their lengths and prefixes.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• P. Wuille, G. Maxwell, 'SegWit address format' (BIP-173, 2017)
• P. Wuille, 'Bech32m format for v1+ witness addresses' (BIP-350, 2020)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 4
• Bitcoin Wiki, 'Technical background of version 1 Bitcoin addresses'