BIP 0173 + 0350

How does an address notice a typing mistake?

The last six characters of a bc1 address carry no information at all. They exist to catch mistakes, and the rules around them decide what a wallet must refuse.

Copy an address by hand and sooner or later you will get a character wrong. Older Bitcoin addresses made that easy. They mix upper- and lowercase letters, which are awkward to write down, type on a phone or read aloud, and their checksum gave no guarantee about which mistakes it would catch.¹

Addresses that begin with bc1 were designed the other way round. BIP 173, assigned in 2017, defined their format, Bech32. BIP 350, assigned in 2020, amended it with a variant called Bech32m. Together they say what every character means and what a decoder must do when one of them is wrong.²

Source revision: bitcoin/bips @ 3a10b5b
Source checked: 1 October 2026
Review state: Draft — independent technical review applied; awaiting human sign-off

Source details

This chapter is an independent explanation, not the proposals themselves. Preamble fields are shown as recorded in the pinned files, with author e-mail addresses omitted. Status is the proposal’s own field, not an endorsement or a sign of consensus.

BIP 173: Base32 address format for native v0-16 witness outputs

BIP: 173
Layer: Applications
Title: Base32 address format for native v0-16 witness outputs
Authors: Pieter Wuille
Greg Maxwell
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0173
Status: Deployed
Type: Informational
Assigned: 2017-03-20
License: BSD-2-Clause
Replaces: 142
Proposed-Replacement: 350

Pinned source · Reader view on bips.dev
SHA-256 b19eab06b264bbd15ad7f7d640fa34de8f4a8809fba8a6ecc3e165545b27a543
Git blob 5bcc4a5255bc85c78f3a4abaa7f4782f8acf6477

BIP 350: Bech32m format for v1+ witness addresses

BIP: 350
Layer: Applications
Title: Bech32m format for v1+ witness addresses
Authors: Pieter Wuille
Status: Deployed
Type: Specification
Assigned: 2020-12-16
License: BSD-2-Clause
Replaces: 173

Pinned source · Reader view on bips.dev
SHA-256 63634b06aa8bae88b31929674736e74964c4598684269ac2b0b140c43a7a0dec
Git blob 8acc839867639c780621dc11aa401b0b181d69cb

FIG. A04.1 Anatomy of a SegWit address

bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

Prefixnetwork: mainnet: bc
Separatoralways “1”: 1
Versionwitness version 0: q
Program20 bytes, 32 characters: w508d6qejxtdg4y5r3zarvary0c5xw7k
ChecksumBech32, no information: v8f3t4

Forty-two characters, five jobs. Only the version and the program describe the destination; the prefix names the network, the 1 marks where data begins, and the last six characters exist only to be checked.^3,4,5,6,7

Four parts and an alphabet

Read the example from BIP 173 left to right. First comes a human-readable prefix, bc, which names the network: mainnet. Testnet uses tb. Then comes a separator, which is always the digit 1. Everything after it is the data part. If a prefix ever contained a 1 of its own, the last 1 in the string would be the separator.^3,4,7

The data part is written in an alphabet of exactly 32 characters: lowercase letters and digits, minus 1, b, i and o. BIP 173 chose the set, and even the order of its characters, using data about which characters people confuse with one another.⁸

Because the alphabet has no case distinctions, an address can be written entirely in capitals. BIP 173 recommends exactly that inside QR codes, whose alphanumeric mode is considerably more compact. What a decoder must refuse is a string that mixes the two cases. The checksum is always computed on the lowercase form.⁹

Six characters that say nothing

The last six characters of the data part are the checksum. They carry no information of their own: remove them and nothing about the destination is lost. Their job is to make almost every string invalid, so that a wrong one is noticed before anyone acts on it.⁶

To check them, a decoder turns each data character into a number from 0 to 31, puts a few numbers derived from the prefix in front, and runs the whole sequence through a short function that BIP 173 calls polymod. For a correctly copied Bech32 string, the function returns exactly 1. Any other result means the string is not one an encoder produced.¹⁰

Details: what polymod does

The function implements a BCH code. It keeps a 30-bit state, six characters of five bits each, and folds in one fixed generator value for every bit that overflows the top as each new character arrives. The prefix is fed in twice: first the high bits of each of its characters, then a zero, then the low bits, so that a typo in the prefix is caught too. When encoding, the six checksum values are chosen so that the final state equals the agreed constant.¹⁰

What this buys is a guarantee, not just good odds. BIP 173 states that the code detects any error affecting at most four characters and has less than a one-in-a-billion chance of missing larger ones. BIP 350's later analysis states the firm part more narrowly: within one checksum family, up to four substituted characters are always detected. A decoder that accepts both families does not inherit that guarantee for edits that also change the witness version; that case needs separate analysis.^11,12,13

The figure below runs the checks a decoder runs, in the order it runs them. Choose one of the public samples, then change any character after the separator and watch where the string is stopped.^14,15

FIG. A04.2 Checksum lab Interactive

Static view of the first sample, Valid v0. With JavaScript you can switch samples and change characters; the table after this figure lists every sample’s result either way.

01CharacterspassedPrintable ASCII, 8–90 long, not mixed case?42 printable characters, single case.
02StructurepassedPrefix, separator “1”, and a data part from the 32-character alphabet?Prefix “bc”, separator at position 3, 39-character data part.
03ChecksumpassedDoes the residue equal the Bech32 or the Bech32m constant?Residue equals the Bech32 constant.
04NetworkpassedIs the prefix the expected one (bc or tb)?Prefix “bc” matches.
05ProgrampassedVersion 0–16, clean padding, 2–40 bytes (20 or 32 for v0)?Version 0, 20-byte program.
06FamilypassedBech32 for v0, Bech32m for v1–v16?Version 0 with Bech32, as required.

Compare checksum families

polymod result0x00000001

Family	Requires	Match
Bech32	`0x00000001`	✓ yes
Bech32m	`0x2bc830a3`	✕ no

Decoder result: scriptPubKey

00OP_014push 20 bytes751e76e8 199196d4 54941c45 d1b3a323 f1433bd6witness program, Bech32 checked

Checks encoding only: not ownership, balance, or whether sending is safe.

✓ Accepted Accepted: witness version 0, a 20-byte program, protected by Bech32 as that version requires.

Sample source: BIP 173, line 64 (Examples). Public test material; never send funds to it.

Any single change you make to a valid sample is stopped at the checksum stage. The decoder learns that the string is wrong, not where: the marked cell is your edit, which the decoder never sees.^{12,14,16,17,18}

Every sample on this page, and where it stops

All results are computed at build time by the same tested decoder the lab uses. Every string is a public test vector copied from the pinned BIP text.
Sample	String	Outcome	Reason or result	Source
Valid v0	`bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4`	✓ Accepted	v0, `0014…` (20-byte program)	BIP 173 L64
Valid v1	`bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqzk5jj0`	✓ Accepted	v1, `5120…` (32-byte program)	BIP 350 L193
Wrong checksum family	`bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqh2y7hd`	✕ Stopped at Family	Version 1 requires Bech32m, but the checksum is Bech32.	BIP 350 L198
One wrong character	`bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5`	✕ Stopped at Checksum	Checksum mismatch: the residue matches neither constant.	BIP 173 L316
v0 with a Bech32m checksum	`bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kemeawh`	✕ Stopped at Family	Version 0 requires Bech32, but the checksum is Bech32m.	BIP 350 L201
BIP 173's own v1 example	`bc1pw508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7k7grplx`	✕ Stopped at Family	Version 1 requires Bech32m, but the checksum is Bech32.	BIP 173 L308
Mixed case	`tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vq47Zagq`	✕ Stopped at Characters	Mixes uppercase and lowercase letters.	BIP 350 L208
Letter outside the alphabet	`bc1p38j9r5y49hruaue7wxjce0updqjuyyx0kh56v8s25huc6995vvpql3jow4`	✕ Stopped at Structure	“o” is not in the Bech32 alphabet.	BIP 350 L203
Unknown prefix “tc”	`tc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vq5zuyut`	✕ Stopped at Network	Prefix “tc” is not the expected “tb”.	BIP 350 L197
v0 program of the wrong length	`BC1QR508D6QEJXTDG4Y5R3ZARVARYV98GJ9P`	✕ Stopped at Program	A version 0 program must be 20 or 32 bytes, not 16.	BIP 350 L207
Too much padding	`bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7v07qwwzcrf`	✕ Stopped at Program	More than 4 bits of padding.	BIP 350 L209
Witness version above 16	`BC130XLXVLHEMJA6C4DQV22UAPCTQUPFHLXM9H8Z3K2E72Q4K9HCZ7VQ7ZWS8R`	✕ Stopped at Program	Witness version 17 is above 16.	BIP 350 L204

It notices; it does not repair

Look at what the checksum stage reports when you change a character: only that the result matches neither constant. Codes of this family can, in principle, locate a few errors and even correct them. BIP 173 advises implementations against the second part.^10,16

The reason is money, not mathematics. Correction turns an invalid string into a valid one. If more mistakes were made than the code can account for, the valid string it produces is the wrong one, and an incorrect but valid address can lose funds irrecoverably. So implementations should at most point to where an error might be, and should leave correction to the user, who can check the original.¹⁶

Why there are two checksums

The firm guarantee covers substituted characters. A different kind of mistake turned out to slip through. When a Bech32 string ends in p, inserting or deleting any number of q characters just before that final p leaves the checksum valid.^12,21

BIP 350 notes that existing version 0 addresses were not affected, because they are restricted to two lengths, 42 or 62 characters. It also warns that the weakness may affect future uses of the format.^22,23

The fix is deliberately small. Bech32m is Bech32 with one change: the constant a valid string must produce. Instead of 1, it is 0x2bc830a3. The alphabet, the separator, the prefixes and the polymod function all stay the same.²⁴

One computation, two accepted results. The witness version decides which one is required.^14,24
Witness version	Checksum	Required result
0	Bech32	`0x00000001`
1 to 16	Bech32m	`0x2bc830a3`

A decoder therefore checks the result against both constants, then checks that the one it found is the one the version requires. That last step is not a formality. In the lab, choose Wrong checksum family. The string passes the checksum stage, because it is a perfectly valid Bech32 string, and is rejected only at the end, because its version is 1.^14,18

No string can be valid under both constants. Even so, BIP 350 explains that a decoder accepting either one for version 0 would weaken its error detection to the equivalent of a 29-bit checksum. The version and the checksum have to agree.^25,26

The change also broke something on purpose. Software that only knows Bech32 rejects every Bech32m address. BIP 350 argues that this clean break protects older senders from the insertion weakness, and from implementations that experiments had shown would burn funds sent to version 1 addresses. When it was written, the BIP noted that no wallets were creating version 1 addresses yet.^27,28

Details: BIP 173's own examples, revisited

BIP 173 listed Bech32 addresses for versions 1, 2 and 16 among its valid test vectors. Under BIP 350 those exact strings are invalid, and BIP 350 lists the same programs with Bech32m checksums. The tests behind this page check both lists against the pinned text, and the table above shows where one of BIP 173's examples now stops.^14,20

What the characters carry

Between the separator and the checksum sit the actual contents. The first data character is the witness version, a number from 0 to 16 held in a single five-bit character. After it comes the witness program, between 2 and 40 bytes long.^5,15,29

Bytes have eight bits and characters carry five, so the program is regrouped. Write out its bits, cut them into groups of five and look each group up in the alphabet. A 20-byte program is 160 bits, exactly 32 characters. A 32-byte program is 256 bits, which takes 52 characters, the last one ending in four bits of zero padding. A decoder reverses the process and must reject padding that is longer than four bits or not all zeroes.^15,29

FIG. A04.3 Eight-bit bytes, five-bit characters

Start of a 20-byte program · Valid v0

Characters 5–12 of bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

End of a 32-byte program · Valid v1

Characters 53–56 of bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqzk5jj0

Exact programs, in full

Valid v0 · 20 bytes: 751e76e8 199196d4 54941c45 d1b3a323 f1433bd6
Valid v1 · 32 bytes: 79be667e f9dcbbac 55a06295 ce870b07 029bfcdb 2dce28d9 59f2815b 16f81798

The same bits, cut two ways. Byte boundaries and character boundaries line up only every 40 bits, so half the characters in each complete 40-bit block straddle two bytes, and a 32-byte program needs padding to fill its final character.^7,15,19,29

Finally, the address becomes the script that a transaction output actually contains. The version becomes an opcode, OP_0 for version 0 and OP_1 to OP_16 for the rest, written as the byte 0x00 or the bytes 0x51 to 0x60. Then come the program's length and the program itself. BIP 173 warns that getting this mapping wrong is likely to produce an output that is unspendable or insecure. The lab shows the resulting script for each valid sample.^7,19,30

What a valid address does not tell you

Passing every stage in the lab means one thing: the string is a well-formed SegWit address. It does not say who controls it, whether it has ever been used, or whether sending to it is wise.³¹

Version numbers make this concrete. The format accepts every version from 0 to 16, and BIP 350 asks senders to recognise all of them as valid recipients, so that future upgrades work with existing wallets. The same paragraph says versions not defined on the network should never be created or handed to a sender.³²

What a program means comes from other BIPs. BIP 141 gives version 0 programs of 20 and 32 bytes their meaning, and BIP 341 defines a Taproot output as version 1 with a 32-byte program. A version 1 address with a program of any other length can be valid as an address and still not be a Taproot output.^33,34

The six characters, again

Go back to the six characters at the end of the address. They hold no part of the destination. They let software reject a mistyped string, with certainty for up to four substitutions within one checksum family and with overwhelming odds otherwise. The rules around them say what happens next: refuse, point at most to where an error might be, and leave the correction to the user.^{6,11,12,13,16}

Bech32m changed a single constant to close a gap that the original guarantee never covered, and it tied each witness version to the checksum that must protect it.^14,21,24

Evidence

Each numbered marker in the text points here. Quotes are verbatim from the BIP files at commit 3a10b5b, including their wiki markup; links open the exact lines; the quoted text sits under each entry. Labels say what kind of statement each is: a rule, the author’s rationale, history, a test vector, or our own inference.

Author’s rationale BIP173 motivates a new format partly because base58's mixed case is hard to write down, type, or read aloud, and its double-SHA256 checksum has no error-detection guarantees.

BIP 173 L37 BIP 173 L38

Quoted source text (2)

The mixed case in base58 makes it inconvenient to reliably write down, type on mobile keyboards, or read out loud.

BIP 173, line 37

The double SHA256 checksum is slow and has no error-detection guarantees.

BIP 173, line 38
History BIP173 was assigned in 2017 and BIP350, which lists itself as replacing BIP173, in 2020. Both preambles record the status Deployed.

BIP 173 L11 BIP 350 L8 BIP 350 L11 BIP 350 L6

Quoted source text (4)

Assigned: 2017-03-20

BIP 173, line 11

Assigned: 2020-12-16

BIP 350, line 8

Replaces: 173

BIP 350, line 11

Status: Deployed

BIP 350, line 6
Rule A Bech32 string is at most 90 characters: a human-readable part, the separator "1" (the last 1 in the string), and a data part of at least 6 characters.

BIP 173 L79 BIP 173 L81 BIP 173 L89

Quoted source text (3)

string is at most 90 characters long and consists of:

BIP 173, line 79

the last one in the string is the separator

BIP 173, line 81

The '''data part''', which is at least 6 characters long

BIP 173, line 89
Rule A SegWit address uses the human-readable part bc for mainnet and tb for testnet, and decoders must check it.

BIP 173 L221

Quoted source text (1)

MUST verify that the human-readable part is "bc" for mainnet and "tb" for testnet.

BIP 173, line 221
Rule The first data character holds the witness version as 5 bits, and decoders must check that it is between 0 and 16.

BIP 173 L212 BIP 173 L222

Quoted source text (2)

1 character (representing 5 bits of data): the witness version

BIP 173, line 212

MUST verify that the first decoded data value (the witness version) is between 0 and 16, inclusive.

BIP 173, line 222
Rule The last six characters of the data part are the checksum and carry no information of their own.

BIP 173 L127–128

Quoted source text (1)

The last six characters of the data part form a checksum and contain no information.

BIP 173, lines 127–128
Test vector Public example: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 is the mainnet P2WPKH example; its uppercase form decodes to scriptPubKey 0014751e76e8199196d454941c45d1b3a323f1433bd6.

BIP 173 L64 BIP 350 L186

Quoted source text (2)

Mainnet P2WPKH: <tt>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4</tt>

BIP 173, line 64

<tt>BC1QW508D6QEJXTDG4Y5R3ZARVARY0C5XW7KV8F3T4</tt>: <tt>0014751e76e8199196d454941c45d1b3a323f1433bd6</tt>

BIP 350, line 186
Rule The data part uses 32 alphanumeric characters, excluding 1, b, i and o; the set and its order were chosen using visual-similarity data.

BIP 173 L89 BIP 173 L90–91

Quoted source text (2)

only consists of alphanumeric characters excluding "1", "b", "i", and "o"

BIP 173, line 89

The character set is chosen to minimize ambiguity according to

BIP 173, lines 90–91
Rule Checksums are computed on the lowercase form; decoders must reject mixed case; uppercase is recommended inside QR codes.

BIP 173 L186 BIP 173 L192 BIP 173 L194 BIP 173 L195

Quoted source text (4)

The lowercase form is used when determining a character's value for checksum purposes.

BIP 173, line 186

Decoders MUST NOT accept strings where some characters are uppercase and some are lowercase

BIP 173, line 192

inside QR codes uppercase SHOULD be used

BIP 173, line 194

which is 45% more compact than the normal

BIP 173, line 195
Rule Verification expands the human-readable part (high bits, a zero, low bits), appends the data values, runs the polymod function, and compares the result with a constant: 1 for Bech32. The encoder picks the six checksum values so the result lands on that constant; the code is a BCH code.

BIP 173 L146 BIP 173 L149 BIP 173 L152 BIP 173 L168

Quoted source text (4)

return [ord(x) >> 5 for x in s] + [0] + [ord(x) & 31 for x in s]

BIP 173, line 146

return bech32_polymod(bech32_hrp_expand(hrp) + data) == 1

BIP 173, line 149

This implements a [https://en.wikipedia.org/wiki/BCH_code BCH code] that

BIP 173, line 152

polymod = bech32_polymod(values + [0,0,0,0,0,0]) ^ 1

BIP 173, line 168
Author’s rationale BIP173 states that its BCH code guarantees detection of any error affecting at most four characters, with under a 1 in 10^9 chance of missing larger errors.

BIP 173 L153 BIP 173 L154–155

Quoted source text (2)

guarantees detection of '''any error affecting at most 4 characters'''

BIP 173, line 153

has less than a 1 in 10<sup>9</sup> chance of failing to detect more errors.

BIP 173, lines 154–155
Author’s rationale BIP350's analysis restates the firm guarantee as substitutions: Bech32 always detects up to four substituted characters, and Bech32m keeps that property.

BIP 350 L224 BIP 350 L218

Quoted source text (2)

Bech32 has a probability of 0 to incorrectly accept error patterns consisting of up to 4 substitutions—they are always detected.

BIP 350, line 224

For Bech32m, we aim to retain Bech32's guarantees for substitution errors

BIP 350, line 218
Editorial inference BIP350 reports detection properties separately for each code and verifier pair, and calls errors that change a witness version across checksum families unlikely but hard to analyze. Its four-substitution guarantee therefore applies within one checksum family, not to a decoder that accepts both.

BIP 350 L236 BIP 350 L236 BIP 350 L95

Quoted source text (3)

Whether this line is about Bech32 or Bech32m encoded strings, and whether those are evaluated regarding their probability of being accepted by either a Bech32 or a Bech32m verifier.

BIP 350, line 236

This situation may in theory occur for segregated witness addresses when errors occur that change the version number in a v1+ address to v0. Due to the specificity of this type of error, plus the additional constraints that apply for v0 addresses, this is both unlikely and hard to analyze.

BIP 350, line 236

a valid Bech32 and Bech32m string will always differ by at least 3 characters if they are the same length.

BIP 350, line 95
Rule Witness version 0 is encoded with Bech32; versions 1 and higher with Bech32m; the decoder must check that the encoding matches the decoded version.

BIP 350 L92–93 BIP 350 L95

Quoted source text (2)

If its witness version is 0, encode it using Bech32. * If its witness version is 1 or higher, encode it using Bech32m.

BIP 350, lines 92–93

the address decoder has to verify that the encoding matches what is expected for the decoded witness version

BIP 350, line 95
Rule When decoding, an incomplete final group must be at most 4 bits and all zeroes, and there must be 2 to 40 bytes.

BIP 173 L225 BIP 173 L226

Quoted source text (2)

Any incomplete group at the end MUST be 4 bits or less, MUST be all zeroes, and is discarded.

BIP 173, line 225

There MUST be between 2 and 40 groups, which are interpreted as the bytes of the witness program.

BIP 173, line 226
Rule Error correction erodes error detection; implementations should not correct beyond suggesting where an error might be, because an incorrect but valid input can lose funds irrecoverably.

BIP 173 L178–179 BIP 173 L179–182 BIP 350 L123

Quoted source text (3)

Use of an incorrect but valid input can cause funds to be lost irrecoverably.

BIP 173, lines 178–179

implementations SHOULD NOT implement correction beyond potentially suggesting to the user where in the string an error might be found, without suggesting the correction to make.

BIP 173, lines 179–182

implementations should refrain from using this for more than indicating where an error may be present.

BIP 350, line 123
Test vector Public test vector: the v0 example with its last character changed is an invalid checksum.

BIP 173 L316

Quoted source text (1)

<tt>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5</tt>: Invalid checksum

BIP 173, line 316
Test vector Public test vectors: the same v1 program with a Bech32 checksum, and the v0 example with a Bech32m checksum, are both invalid.

BIP 350 L198 BIP 350 L201

Quoted source text (2)

<tt>bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqh2y7hd</tt>: Invalid checksum (Bech32 instead of Bech32m)

BIP 350, line 198

<tt>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kemeawh</tt>: Invalid checksum (Bech32m instead of Bech32)

BIP 350, line 201
Test vector Public test vector: a v1 Bech32m address that decodes to a 32-byte program.

BIP 350 L193

Quoted source text (1)

<tt>bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqzk5jj0</tt>: <tt>512079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798</tt>

BIP 350, line 193
History BIP173 listed Bech32 v1, v2 and v16 addresses as valid; BIP350 lists the same programs with Bech32m checksums instead.

BIP 173 L308 BIP 350 L188

Quoted source text (2)

<tt>bc1pw508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7k7grplx</tt>

BIP 173, line 308

<tt>bc1pw508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7kt5nd6y</tt>

BIP 350, line 188
Rule Bech32 has an insertion weakness: when the final character is p, inserting or deleting q characters just before it leaves the checksum valid.

BIP 350 L28

Quoted source text (1)

whenever the final character is a 'p', inserting or deleting any number of 'q' characters immediately preceding it does not invalidate the checksum.

BIP 350, line 28
Author’s rationale BIP350 states the weakness does not affect version 0 addresses, because they are restricted to two lengths. It may affect future uses.

BIP 350 L28 BIP 350 L28

Quoted source text (2)

This does not affect existing uses of witness version 0 BIP173 addresses due to their restriction to two specific lengths

BIP 350, line 28

but may affect future uses and/or other applications using the Bech32 encoding.

BIP 350, line 28
Rule BIP141 makes a version 0 program of any length other than 20 or 32 bytes fail; BIP173 asks decoders to enforce such known-length rules, so v0 addresses are always 42 or 62 characters.

BIP 173 L229–230 BIP 173 L233

Quoted source text (2)

If the version byte is 0, but the witness program is neither 20 nor 32 bytes, the script must fail.

BIP 173, lines 229–230

Version 0 witness addresses are always 42 or 62 characters

BIP 173, line 233
Rule Bech32m changes only the final constant xored into the checksum, from 1 to 0x2bc830a3; all other aspects of Bech32 are unchanged.

BIP 350 L38 BIP 350 L65

Quoted source text (2)

replacing the constant ''1'' that is xored into the checksum at the end with ''0x2bc830a3''

BIP 350, line 38

All other aspects of Bech32 remain unchanged, including its human-readable parts (HRPs).

BIP 350, line 65
Rule No string is valid as both Bech32 and Bech32m; two valid strings of the same length, one of each kind, differ in at least three characters.

BIP 350 L95 BIP 350 L164

Quoted source text (2)

a valid Bech32 and Bech32m string will always differ by at least 3 characters if they are the same length.

BIP 350, line 95

No string can be simultaneously valid Bech32 and Bech32m

BIP 350, line 164
Author’s rationale Accepting both encodings for version 0 would weaken detection to the equivalent of a 29-bit checksum.

BIP 350 L88

Quoted source text (1)

Permitting both encodings reduces the error detection capabilities (it makes it equivalent to only have 29 bits of checksum).

BIP 350, line 88
Author’s rationale BIP350 intentionally breaks forward compatibility: old Bech32-only senders reject Bech32m addresses, which the author argues protects them from the mutation issue and from burning funds.

BIP 350 L135 BIP 350 L135 BIP 350 L135

Quoted source text (3)

the Bech32m proposal breaks forward-compatibility for sending to v1 and higher version segregated witness addresses

BIP 350, line 135

the chosen approach will prevent such software from destroying funds when attempting to send to a Bech32m address.

BIP 350, line 135

those experiments identified cases in which segregated witness implementations would have caused wallets to burn funds when sending to version 1 addresses.

BIP 350, line 135
History When BIP350 was written, it noted that no wallets were creating v1 addresses yet, because the output type was not usable on mainnet.

BIP 350 L133

Quoted source text (1)

no wallets are creating v1 segregated witness addresses yet, as the output type is not usable on mainnet.

BIP 350, line 133
Rule The 2-to-40-byte witness program is written as bits, regrouped into 5-bit groups padded with zeroes, and each group becomes one character.

BIP 173 L213 BIP 173 L215

Quoted source text (2)

A conversion of the 2-to-40-byte witness program

BIP 173, line 213

Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.

BIP 173, line 215
Rule Converting to a scriptPubKey stores version n as OP_n: 0x00 for version 0 and 0x51–0x60 for versions 1–16; getting this wrong can make an output unspendable or insecure.

BIP 173 L236–238 BIP 173 L238–239

Quoted source text (2)

OP_0 is encoded as 0x00, but OP_1 through OP_16 are encoded as 0x51 though 0x60

BIP 173, lines 236–238

If a bech32 address is converted to an incorrect scriptPubKey the result will likely be either unspendable or insecure.

BIP 173, lines 238–239
Editorial inference Passing the address checks establishes encoding validity only; it does not establish ownership, use, or whether sending is wise.

BIP 173 L178–179 BIP 350 L151

Quoted source text (2)

Use of an incorrect but valid input can cause funds to be lost irrecoverably.

BIP 173, lines 178–179

no recipient should ever provide them to a sender

BIP 350, line 151
Rule BIP350 asks senders to treat all higher witness versions as valid recipients, while saying versions not defined on the network should never be created or handed to a sender.

BIP 350 L151 BIP 350 L151 BIP 350 L151

Quoted source text (3)

All higher versions of native segregated witness outputs should be recognized as valid recipients.

BIP 350, line 151

As higher versions are not defined on the network, no wallet should ever create them and no recipient should ever provide them to a sender.

BIP 350, line 151

future soft forks introducing higher versions of native segwit outputs will be forward-compatible to all wallets correctly implementing the Bech32m specification.

BIP 350, line 151
Rule In BIP141, a 20-byte version 0 program must match the HASH160 of a public key, and a 32-byte one must match the SHA256 of a witness script.

BIP 141 L97 BIP 141 L103

Quoted source text (2)

The HASH160 of the public key must match the 20-byte witness program.

BIP 141, line 97

SHA256 of the <code>witnessScript</code> must match the 32-byte witness program.

BIP 141, line 103
Rule BIP341 defines a Taproot output as a native SegWit output with version 1 and a 32-byte witness program; the address format itself does not define that meaning.

BIP 341 L58

Quoted source text (1)

A Taproot output is a native SegWit output (see [[bip-0141.mediawiki|BIP141]]) with version number 1, and a 32-byte witness program.

BIP 341, line 58