[BIP Proposal] Add BIP-0093 (Codex32) as application to BIP-0085

[Ben Westgate]

Hello bitcoin-dev,

I’m Ben Westgate, a contributor interested in deterministic wallet backups and seed management.

Per BIP-0002, I propose listing BIP-0093 (codex32) as an application of
BIP-0085 (Deterministic Entropy from BIP32 Keychains), similar to the existing BIP39 application. This allows wallets to derive codex32 backups from BIP-0032 master keys.

Summary

• Application number: 93'

• Derivation path: m/83696968'/93'/{hrp}'/{threshold}'/{n}'/{byte_length}'/{id0}'/{id1}'/{id2}'/{id3}'/{index}'
  

Codex32, defined in BIP-93, is a human-readable encoding with checksumming and share indexing designed for SSS backups of BIP-0032 seeds. This PR proposes a deterministic way to generate codex32 strings using BIP-85.

Rationale

• Mirrors the existing BIP-85 application for BIP-39.

• Codex32 offers error correction, hand verification, identifiers, and secret sharing features compared to BIP-39.

• Adds a standardized way for wallets to generate codex32 backups from BIP-85-derived entropy
  

• Test vectors and reference implementation are linked to in the PR.
  

Risks and alternatives

• Wallet adoption of codex32 is still limited, though a draft PR #32652 for importing codex32 strings to Bitcoin Core has support.

• Codex32 implementers could use the BIP-85 dice application, but defining a direct application improves interoperability.

PR: https://github.com/bitcoin/bips/compare/master...BenWestgate:bips:codex32

Feedback is welcome.

Best regards,
Ben Westgate

[Javier Mateos]

Hi Ben,

Thank you for your proposal to integrate BIP-0093 (codex32) as an application within BIP-0085

Reviewing the specification,  I believe I see two areas where we could improve clarity for implementers:

1) The DRNG→5-bit extraction process could benefit from explicit pseudocode to avoid implementation variations
2) The rule 'threshold == 0 implies n == 1' currently appears as a note but could be clearer as a normative requirement"

Best Regards,
Javier Mateos

[Ben Westgate]

Hi Javier,

Thank you for your feedback.

I added pseudocode for the character value selection. I added a column and row to the n table to clarify the t==0 constraint on n, removed the notes and in the unshared secret section made the normative statement: 'When threshold == "0", n MUST be 1 and the output is a codex32 secret.'

I’ve updated the PR with these changes and would appreciate your review.

Commit: https://github.com/BenWestgate/bips/commit/fa6e9788bf04d271792ed4ea89a112d12284ef02

Best regards, Ben Westgate

[Javier Mateos]

Hi Ben,

Thank you for implementing those changes so promptly. I reviewed the commit and the updates address both concerns effectively.

These changes should ensure consistent implementations across different codex32 tooling that uses BIP-85 derivation.

The proposal looks technically sound, follows BIP-85's established pattern for applications, and is supported by comprehensive test vectors and a reference implementation.

Looking forward to hearing feedback from other reviewers as well.

Best regards,
Javier Mateos

[Ben Westgate]

Thanks Javier for confirming my updates address your concerns,

Andrew Poelstra and Russell O'Connor gave feedback on the bip85 codex32 application, they:

- support it for recoverable "uncle-Jim"-style child codex32 strings for forgetful relatives.

- prefer wallets generate t fresh initial strings by directly encoding RNG entropy to maintain information-theoretic security.

- see value in it to stretch entropy when users won’t provide enough for direct encoding but don't trust their hRNG.

- consider codex32 backups for a bip85 root keys a very good idea.

I welcome further feedback on the proposed before I submit it as a PR: https://github.com/bitcoin/bips/compare/master...BenWestgate:bips:codex32

Best regards, Ben Westgate