AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 52 Bitcoin

address: reject v2-v16 segwit addresses encoded with bech32

Public commit record

What the developer wrote

Authored by Lrifton92

83/100 · Strong
address: reject v2-v16 segwit addresses encoded with bech32

BIP-350 requires that segregated witness outputs of version 1 through 16
use the bech32m checksum, while only version 0 uses bech32. decodeSegWitAddress
only special-cased versions 0 and 1, so a witness program with version 2-16
encoded using the legacy bech32 checksum decoded successfully, in violation of
the spec and contrary to the BIP-350 reference decoder (which rejects any
non-zero witness version that is not bech32m).

Generalize the version 1 check to cover all versions >= 1, matching the
reference decode() function. Add the relevant BIP-350 INVALID_ADDRESS vectors
(v2 and v16 encoded with bech32) as a regression test; they decoded
successfully before this change and are now rejected.

Signed-off-by: Lrifton92 <Lrifton92@users.noreply.github.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a bug in how btcd decodes certain Bitcoin SegWit addresses. Under the BIP-350 standard, newer witness versions (versions 2 through 16) must use a newer checksum called bech32m, but btcd was only enforcing that rule for version 1. As a result, it wrongly accepted v2-v16 addresses encoded with the older bech32 format. The patch now rejects those invalid addresses and adds test cases to prevent the bug from returning. This is a standards-compliance fix; it does not by itself steal funds, but accepting non-standard addresses could lead to wallet or payment-processing mistakes.

Recommended action

Treat as a low-to-moderate correctness and standards-compliance fix. Merge the patch and run the new regression tests. Review any downstream code that may have relied on the previous permissive decoding behavior, especially wallets or APIs that accepted v2-v16 bech32 addresses, and consider whether previously accepted invalid addresses need to be re-validated or rejected.

Security signals we found

01

BIP-350 standards non-compliance in SegWit address decoding

02

Acceptance of bech32-encoded v2-v16 witness programs that should require bech32m

03

Reference test vectors added as regression tests

04

Defensive hardening of address parsing

Risk score

Why this scored 52/100

Our methodology →
Potential impact 12/30
Exploitability 10/25
Stealth signal 8/15
Affected reach 10/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.