bip93: reject HRPs longer than 83 characters

[BenWestgate]

Fixes #32.

BIP-93 specifies a generalized human-readable part using the BIP-173 grammar, including the 1–83 character HRP limit. Enforce that limit in bech32_decode, where Bech32-like strings cross the decoding boundary, and reject overlong public correction-context HRPs as well.

The regression coverage uses the generalized-HRP draft vectors from BenWestgate/bips PR #2 at 01374bf: the valid 83-character HRP, invalid 84-character HRP, generalized-HRP share/recovery vectors, expanded-codeword 94/95 gap cases, and lowercase-HRP checksum rule. The obsolete >83-character frozen vectors were removed rather than repurposed as checksum-layer tests.

Current head b1b1b27 is the same four focused, human-authored commits mechanically replayed onto refreshed #13. All four stable patch-ids are unchanged./ No HRP behavior or vector content changed during the restack; the PR now targets #13 so GitHub shows only the four HRP commits. /

Validation on the resolved tree:

• tests/test_generic_hrp.py + tests/test_correction_bch.py: 105 passed;
• strict mypy: clean across all 21 source files;
• git diff --check: clean;
• the resolved pre-rebase merge tree and final rebased tree have the same tree hash (521f07bf);
• exact-head GitHub push and pull-request matrices are fully green across Python 3.10–3.15 compatibility and the 3.12/3.13 Linux/macOS/Windows test matrix;
• no unresolved review threads remain.

Keep the generalized BIP93/BIP173 vectors as the source of truth; do not resurrect removed >83-character frozen vectors as checksum-layer tests.

Disclosure: AI tools were used for the authorized mechanical branch restack and verification. The four patch commits retain Ben Westgate as their author.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 605131826a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[BenWestgate]

aNACK

Add the check in _decode_codex32 rather than bech32_decode: the
latter is exercised directly by the generic BIP-0173 checksum-period
test vectors, which use HRPs far longer than 83 characters to test
the long checksum's own 1023-symbol period independent of any one
application's rules.

This really belongs in bech32_decode actually as it applies to all bech32-like encodings due to limits on needing to decode the HRP to know codex32 is being used and memory issues.

Also why was this closed?

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4d1e43e759

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[BenWestgate]

#33 is open. #35 was the superseded duplicate and was closed after its useful changes were retained here.

[BenWestgate]

@claude review this PR

[BenWestgate]

Addressed the aNACK at the current head (e49d23f): the 83-character HRP boundary is enforced in bech32_decode, not only in codex32 parsing, and the old >83 generic long-HRP vectors were removed from the accepted set. The focused boundary tests now use the generalized-HRP BIP93 vectors copied from the bip93-generalize-hrp work rather than inventing replacement vectors. Focused verification: 13 relevant generalized-HRP/context tests pass; the PR is merge-clean and CI is green.

[BenWestgate]

AI-generated review (Claude), posted at the maintainer's request.

ACK e49d23f, one nit.

• The 83-char limit sits at the separator in bech32_decode, so every parse path gets it. CorrectionContext is covered too.
• Draft vectors match 01374bf; the only later commit on that branch (87d096b) is a changelog entry.

[BenWestgate]

• The 83-char limit sits at the separator in bech32_decode, so every parse path gets it. CorrectionContext is covered too.

That is the correct behavior. Bech32-like parsing requires 83 character maximum for the HRP.

[BenWestgate]

AI-generated review, posted at the maintainer's request.

ACK 6be7136.

[BenWestgate]

Agent release-gate review at current head 6be7136: reviewed the current 4-commit diff against reviewability-v1. The 83-character check is applied at the Bech32 decode boundary and to public correction contexts; the replacement tests use the generalized-HRP draft vectors rather than preserving now-invalid oversized legacy vectors. git diff --check is clean and exact-head Python-package run 36361372717 succeeded. No remaining code-review blocker found.

[BenWestgate]

AI-assisted release-gate recheck of refreshed head 29bd052.

ACK. This is the reviewed four-commit HRP/vector change mechanically rebased onto current reviewability-v1. The only conflict was the tests/test_generic_hrp.py import block; the resolution preserves both the generalized-HRP imports from this PR and the base STUB_FINGERPRINT import. The resolved merge tree tested before rebase and the final rebased tree have the same tree hash (521f07bf). Focused generalized-HRP/correction tests pass 105/105, strict mypy is clean across 21 source files, git diff --check is clean, both exact-head GitHub matrices are fully green, and there are no unresolved review threads.

No remaining code blocker found. The four patch commits remain authored by Ben Westgate; AI assistance was limited to the authorized mechanical restack and verification.

[BenWestgate]

Codex current-head re-review: ACK b1b1b27.

The 83-character BIP173 HRP limit is enforced both by parsing and by correction-context validation before search. The current tests cover the 83/84 boundary and generalized-HRP vectors while removing the inappropriate oversized legacy fixture; prior provenance and context findings are resolved. Exact-head Python-package runs 638 and 639 both succeeded.

No code blocker found; ready for human integration review after #13.

[BenWestgate]

Codex current-head review at b1b1b27: no findings. The 83-character HRP bound is enforced consistently in decoding and correction contexts and covered by the generalized-HRP boundary vectors.

[BenWestgate]

@codex review

Please review current head b1b1b27d14 only. This is the final current-head audit check before human review; focus on correctness, security, and release-blocking regressions.

[BenWestgate]

AI-assisted current-head review: ACK b1b1b27. I rechecked the earlier HRP-boundary concern against the generalized-HRP BIP work: both the referenced staging vector commit and the current BenWestgate/bips PR #2 still specify an 83-character maximum HRP; 1023 is the expanded-codeword checksum bound, not an HRP-length allowance. This PR enforces 83 at decode and public correction-context boundaries, uses the generalized-HRP vectors directly, and removes the obsolete >83 frozen vectors rather than keeping them as checksum tests. Exact-head Python-package runs are green and there are no unresolved review threads. No correctness or release blocker found.