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 @ 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 6be71368 is four focused commits and is mergeable against reviewability-v1. The full GitHub Python-package matrix is green, and all inline review threads are resolved.

Disclosure: AI tools were used while developing and reviewing this change, per docs/developer/AI_POLICY.md.

[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.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[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.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[BenWestgate]

Current-head recheck after the rollback: e49d23f is green again (Python package run 298 completed successfully). Functional HRP-limit/vector coverage is review-ready. The only remaining review item is the provenance-comment nit; leave it unresolved until it can be changed as a true one-line edit without touching the adjacent 1008-symbol vector.

[BenWestgate]

Release-gate follow-up: the last provenance-comment nit is resolved at 07024bd. The corresponding review thread is resolved, the diff from the behavioral head changes only that attribution comment, and fresh Python package run 36327172589 completed successfully. There are no remaining functional or review-thread blockers on #33; it is ready for human review/merge.

[BenWestgate]

Release-gate concept recheck: the 83-character HRP limit is the intended generalized-BIP93 contract, not a stale pre-generalization limit. BenWestgate/bips PR #2 currently specifies the HRP “as specified in BIP-0173,” and the review discussion explicitly notes “now that HRP is limited to 83 characters.” All #33 review threads are resolved at 07024bd, including the vector-provenance nit, and the branch is merge-clean/green. I withdraw the earlier concern about moving this to a 1024-character HRP; the 1023 bound applies to the expanded checksum codeword, not the HRP grammar. Concept ACK 07024bd.

[BenWestgate]

Release-gate semantic recheck: the 83-character HRP limit is still the correct generalized-BIP93 contract, not a conflict with the long-checksum 1023-symbol period. BenWestgate/bips PR #2 says the human-readable part is “as specified in BIP-0173,” while the 93/96–1023 limits apply to the expanded codeword (HRP expansion + data), not to HRP length itself. The PR’s 83/84 boundary vectors and bech32_decode/CorrectionContext checks therefore match the current generalized-HRP draft. All inline threads are resolved and the current head 07024bd preserves the reviewed behavior; I no longer consider the HRP contract a blocker to human review.

[BenWestgate]

Sequencing note: current head 6be71368 is green/mergeable, but final human review should follow #7. A fresh integration preflight from current reviewability-v1 shows #7 + #51 compose cleanly and then #33 has exactly one mechanical conflict in the tests/test_generic_hrp.py import block; keep both #33’s InvalidChecksum/InvalidLength imports and #7’s STUB_FINGERPRINT. No implementation file conflicts. Refresh once after #7 lands, then review.

[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.