This guide explains BIP 350 Bech32m format for v1+ witness addresses in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 350 defines Bech32m, the checksum variant used for native SegWit witness versions 1 through 16. Witness version 0 addresses remain Bech32.
- Why it matters: BIP 350’s central rule is simple but unforgiving: witness version 0 uses Bech32, while versions 1 through 16 use Bech32m. Decoders must verify that relationship after checksum validation.
- Current position: The BIP is Deployed, Applications and Specification and replaces BIP 173 for version 1 and later witness addresses.
What this means in simple English
A BIP is a document that proposes or explains a Bitcoin idea, standard or rule. A BIP number does not mean the idea is active. Some BIPs are widely used, while others are drafts or historical proposals.
You do not need to read code to understand the main point. Start with the status, the problem being addressed and the practical effect on ordinary users, wallets, miners or node operators.
Simple example
Think of the transaction as a form passed between several authorised signers. Each person or device checks the same payment details before adding approval. Passing the form around does not make the payment safe unless every signer checks what it contains.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Status and replacement
The BIP is Deployed, Applications and Specification and replaces BIP 173 for version 1 and later witness addresses. It does not replace Bech32 for version 0 outputs.
Checksum change
Bech32m keeps the Bech32 character set and human-readable part but changes the final polymod constant from 1 to 0x2bc830a3 to address an insertion weakness.
Version binding
After decoding, require Bech32 for witness version 0 and Bech32m for versions 1 through 16. Reject a checksum that is valid but belongs to the wrong version family.
Program constraints
Witness versions must be 0 to 16 and programs 2 to 40 bytes; version 0 is further restricted to 20 or 32 bytes. Reject mixed case, bad padding and wrong network HRP.
Recipient boundary
A checksum detects classes of transcription error; it does not authenticate the payee, network intent or wallet ownership. Confirm material addresses through a second trusted channel.
Compatibility
The deliberate forward-compatibility break stopped older faulty senders from treating version 1 addresses as ordinary Bech32. Software must upgrade before offering v1 payment support.
How specialists test it
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
Frequently asked questions
What is BIP 350 Bech32m?
BIP 350 defines Bech32m, the checksum variant used for native SegWit witness versions 1 through 16. Witness version 0 addresses remain Bech32.
Is BIP 350 Bech32m active or supported today?
The BIP is Deployed, Applications and Specification and replaces BIP 173 for version 1 and later witness addresses.
Why does BIP 350 Bech32m matter?
BIP 350’s central rule is simple but unforgiving: witness version 0 uses Bech32, while versions 1 through 16 use Bech32m. Decoders must verify that relationship after checksum validation.
Do beginners need to use the technical details?
No. Most readers only need to understand the idea and its current status. Developers and node operators can use the primary sources when they need the exact technical rules.
Conclusion
BIP 350’s central rule is simple but unforgiving: witness version 0 uses Bech32, while versions 1 through 16 use Bech32m. Decoders must verify that relationship after checksum validation.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
