BIP 173 Bech32 for Native SegWit v0 Addresses

This guide explains BIP 173 Bech32 in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

Address structure

A Bech32 string contains a human-readable part, separator, data characters and six-character checksum. The human-readable part distinguishes networks, while data carries witness version and converted programme bytes. Address text is a payment instruction, not the script itself, and must decode deterministically.

Character set and case

The alphabet avoids visually ambiguous characters and supports efficient QR encoding. Encoders use one case and decoders reject mixed case, though uniformly upper or lower representations may decode. Applications should preserve a canonical lowercase display and never silently repair a mixed or damaged address.

Witness version zero

For v0, valid programme lengths are constrained to the deployed P2WPKH and P2WSH forms. A checksum-valid string with an invalid witness length is still not a valid Bitcoin destination. Decoders must enforce both generic Bech32 rules and version-specific witness semantics.

Network prefixes

Mainnet commonly uses bc while test networks use different human-readable parts. A valid checksum does not mean the address belongs to the intended chain. Payment systems must assert network and script, and hardware devices should display the full destination context before signing.

Checksum limits and Bech32m

Research found Bech32’s original constant had undesirable error behaviour for longer future-version programmes. BIP 350 retains Bech32 for v0 and requires Bech32m for v1-v16. A robust decoder validates version and checksum family together and rejects the wrong pairing.

Operational validation

Use official positive and negative vectors, including mixed case, invalid separator position, bad padding, excessive length, wrong network and wrong checksum family. Round-trip tests alone are weak because the same defective library can encode and decode its own invalid output.

Migration and recovery

Moving funds from nested SegWit to native v0 requires an on-chain spend, not text conversion. Record descriptors or derivation paths, network and account discovery for recovery. Preserve old wallet support until balances and change are reconciled, and verify destinations on an independent device.

Conclusion

BIP 173 remains the deployed Bech32 foundation for native SegWit v0. Correct modern handling couples witness version, network, programme length and checksum family, using BIP 350 for later versions.