BIP93: Restrict master seed lengths and Revise codex32 string length specifications #2077

1. 
   BenWestgate commented at 9:30 pm on January 8, 2026: contributor

   codex32 string length limited to always cover HRP characters, master seed bit lengths limited to multiples of 32-bits, updated master seed encoding/decoding processes.

   PR helper for #2040: prepares text for general HRP lengths by defining limits based on string length not data part length and deprecating master seed lengths that violate a general codex32 string length > checksum type rule.

   Why Restricting seeds to 32-bit multiples makes valid secret seed lengths differ by at least 6-7 characters reducing ambiguity to two valid lengths for insert/delete-correcting error correcting wallets.

   Key changes c286c2c5a7385113d33b3dd8cbda806bd371523f

   • Overall string max length for regular codex32 now limited to 94 chars. Payload changed from “up to 74” → up to 72 bech32 characters.
   • Long codex32: new length window (97–1024 characters) and payload allowance relaxed (up to 1001 bech32 chars).
   • Explain the checksum covers low HRP+data per BIP-0173.

   Other changes:

   • Remove “decode” from Unshared Secret as this process should be application specific once HRP is generalized.
   • Master seed format changes:
     • Add “decode” section.
     • Restrict seed lengths to 32-bit multiples (128-512) to avoid an “ms” exception for switching between regular and long format.
     • Recommend how to derive unspecified identifiers for fresh and reshared secret seeds.
     • Recommend deterministic implementations derive padding using a defined CRC code.
   • Defined a “shared string” as a non-“0” threshold parameter codex32 string.
     • Defined how to “decode” these as implementers have been surprised naked share payload bytes are insufficient to recover the secret.
   • Defined a “master share set” as a k shared strings valid set generated with exactly k-1 fresh shares in accordance with that section. (needed for deriving reshare identifiers.)
   • Added a couple <ref> notes for the less obvious changes.
   • Fixed missing /ref so Footnotes now appear at the end of Rationale (they’re invisible in master)
   • Bolded all section references.

   Test Vectors I have a reference implementation with test vectors according to this spec update, as well as #2040, so I will add these if reviewers agree about the text changes.

2. Revise codex32 string specifications and payload limits

   Clarified codex32 string specifications, including character limits and decoding processes. Updated references to BIP-0173 and adjusted payload character limits.

   c286c2c5a7
3. BenWestgate marked this as a draft on Jan 26, 2026
4. 
   BenWestgate commented at 8:11 pm on January 26, 2026: contributor

   This is ready for review if you prefer the regular/long checksum switch being a property of the codex32 format rather than application specific. A new #2040 approach avoids “ms” length restrictions by leaving checksum selection up to each application. This still improves insert/delete error correction, but we have not studied how much, so is less urgent.
5. murchandamus added the label Proposed BIP modification on Feb 27, 2026
6. murchandamus added the label Pending acceptance on Feb 27, 2026
7. 
   murchandamus commented at 10:42 pm on February 27, 2026: member

   Hi @BenWestgate, I haven’t followed in detail which of your proposals is at what stage, but if this should be ready to move forward, could you please notify the authors that their review will be required for this to proceed?
8. 
   BenWestgate commented at 11:10 pm on February 27, 2026: contributor

   This helper PR was requested by @roconnor-blockstream #2040 (comment)

   I no longer think BIP93 should define which checksum non-“ms” applications must use. If he or another author agrees we can close this.

9. 
   murchandamus commented at 1:19 am on February 28, 2026: member

   @BenWestgate: Thanks for the update. Let’s close this in a couple weeks on or after 2026-03-13, if we don’t hear anything else from the BIP owners.

Contributors
BenWestgate murchandamus

Labels
Proposed BIP modification Pending acceptance