Does your bitcoin address validator pass BIP-350?

Why it matters more than a normal parsing bug

A validator that wrongly rejects a good address is an annoyance. A validator that wrongly accepts a bad one can cost the user their money, and there are two distinct ways that happens:

• Witness version 1+ with a program that isn't 32 bytes. BIP-341 is explicit that such outputs "remain unencumbered" — once funded, anyone can spend them. If your validator green-lights bc1pw5dgrnzv, it is green-lighting an address that is not a taproot output at all.
• Witness version 0 with a program that isn't 20 or 32 bytes. The script simply fails, so the coins are unspendable by anybody, including the intended recipient.

Both are addresses a user can paste in and a validator can wave through. Neither is caught by checksum verification, because the checksum is perfectly valid in both cases.

The two mistakes I keep finding

1. Choosing the checksum constant from the string prefix

BIP-350 says version 0 uses bech32 and versions 1–16 use bech32m. A very natural-looking way to implement that is:

if (address.startsWith('bc1p')) { /* bech32m */ } else { /* bech32 */ }

The character after bc1 is the witness version, but the bech32 charset is qpzry9x8gf2tvdw0s3jn54khce6mua7l — so v1 is p, v2 is z, v16 is s. Testing only for p catches taproot and misses the other fifteen versions, which then come out inverted in both directions: correctly-encoded ones rejected, wrongly-encoded ones accepted. The witness version lives in the decoded data part, so it cannot be known before you decode. Decode with both constants, see which verifies, then require that it is the one the version mandates.

2. Never checking the program length

BIP-141: every witness program is 2–40 bytes, and at version 0 it is exactly 20 or 32. That's three lines, and it is the check that separates "valid checksum" from "safe to pay".

One thing to not over-tighten, which I got wrong myself first time: a version 1 program that isn't 32 bytes is still a validly encoded address. BIP-350 lists a 40-byte v1 address among its VALID vectors. Address encoding and spending rules are separate questions — so return the witness version to the caller and let them apply policy, rather than silently answering a question they didn't ask.

Run it

This runs entirely in your browser with new Function. Nothing is sent anywhere — there is no server side to this page, and you can read the source. If you'd rather not paste code into a web page at all, take the standalone test files further down instead.

Take the vectors with you

The point isn't this page, it's having the vectors in your test suite so a future refactor can't quietly undo the fix. Both files are dependency-free and exit non-zero on failure, so they drop straight into CI.

bip350-vectors.js  ·  bip350_vectors.py  ·  bip350-vectors.json

Vectors are transcribed from BIP-350's own test section, including its wording for why each invalid one is invalid. If you find a transcription error, tell me and I'll fix it and say so.