How does the mechanism work?

Base58Check uses an alphabet chosen to avoid some easily confused characters. For a main-network public-key-hash address, the payload includes a version byte and a 20-byte public-key hash. Four checksum bytes come from double SHA-256 of the versioned payload. Leading zero bytes have a defined representation; they cannot simply be dropped during conversion.

Bech32 separates a human-readable network prefix from the encoded data with the separator character 1. A main-network witness address uses bc as the prefix. The data encodes a witness version and program, followed by six checksum characters. Witness data conversion groups bits differently from raw hexadecimal display, so displayed character count is not the same as byte length.

Bech32m keeps the overall structure but changes the checksum constant. Version-0 witness destinations use Bech32. Versions 1 through 16 use Bech32m under the updated specification. A decoder must enforce this association along with program-length rules. It is not enough to find that either checksum variant accepts the string.

Case handling is another distinction between a readable address and a correctly decoded one. A Bech32-family string may use the permitted all-uppercase or all-lowercase representation, but mixed case fails its rules. Display software should preserve and validate the entire string rather than assume every unusual character is a cosmetic difference. Padding also has defined constraints when converting between bit group sizes. Accepting extra nonzero padding can produce an invalid interpretation even if a casual character-count check looks correct. Use the valid and invalid vectors in the specifications to test those boundaries, including version, program length and checksum matching together.

How do Bitcoin address encodings differ?Base58Check encodes versioned payloads with a checksum. Bech32 and Bech32m encode witness destinations using a human-readable prefix, witness version, program and checksum. The correct checksum variant depends on the witness version.Decode prefix and payloadCheck checksum variantInterpret version and program
A destination needs both a valid encoding and valid payload rules. Neither proves who controls it.

How do the protocol numbers work in an example?

Compare concrete program lengths without publishing a payment destination. A version-0 public-key-hash program is 20 bytes, or 160 bits. Converting that program into 5-bit groups produces 32 groups. Add the witness-version character and six checksum characters, then the two-character bc prefix and separator. The corresponding main-network address length is 42 characters.

A Taproot program uses version 1 and 32 bytes. Its 256 bits require 52 groups after zero padding in the final group. Adding the same version, checksum, prefix and separator components gives 62 characters. Its checksum must be Bech32m. These are format calculations, not a test that a particular person owns an address of that length.

Imagine a string with a version-1 program whose checksum was calculated using old Bech32. Even if the alphabet and length look plausible, a modern compliant decoder rejects the version-and-checksum mismatch. Replacing its prefix or one character does not repair the encoding because the checksum covers the relevant components. Build a destination through correct encoding rather than hand editing.

Witness version selects a checksum variantAfter decoding a witness address, version 0 requires Bech32. Versions 1 through 16 require Bech32m. The program must also satisfy the rules for its version.Decode witness versionVersion 0Versions1–16Bech32Bech32m
The diagram follows the worked example. Sample heights and amounts illustrate the sourced rules.

Common misunderstandings

A checksum can detect encoding errors but cannot recognise an intended recipient. A maliciously substituted address can be entirely valid. A format check and an identity check answer different questions.

A long destination does not imply a larger transfer or a stronger security claim. Output value is encoded separately in the transaction. Future spending weight depends on the construction and chosen path, not just how many address characters you copied.

Bech32m is not a generic replacement to apply indiscriminately to all existing witness addresses. Version-0 programs still require Bech32. Network prefixes also need validation: an address for a test environment should not be silently treated as a main-network destination merely because its program resembles one.

Check yourself

Should a version-0 witness program with a Bech32m checksum be accepted?

Reveal the answer

No. Version 0 requires Bech32, while versions 1 through 16 require Bech32m under the updated witness-address rules. The variant must match the decoded version.

What does this diagram leave out?

This lesson explains decoding stages, not a production address parser. Full validation also enforces case, character, padding and program rules. Bech32-family strings must not mix upper and lower case. Use the specification’s valid and invalid test vectors when implementing a decoder.

Which primary sources define the rules?

Sources: Base58Check implementation; Bech32 format and vectors; Bech32m matching and vectors.