BIP85: Add Codex32 as application 93'

[BenWestgate]

This allows wallets to derive codex32 secrets and codex32 shares from BIP-0032 master keys.

Summary of changes

• Add codex32 application
• Add BIP-0093 to references
• Bump version number to 1.4.0
• Add 1.4.0 reference implementation

Rationale

• Mirrors the existing BIP-85 application for BIP-39.
• Codex32 offers error correction, hand verification, identifiers, and secret sharing improvements vs BIP-39.
• Deterministic generation produces auditable backups by avoiding reliance on local RNG, helping users who distrust device entropy.

Specification

• Adds Application 93' to BIP-0085 using derivation path:

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

• Uses the BIP-85 DRNG
• Unspecified identifiers default to BIP-32 master seed fingerprint

Tests
Reference tests and new vectors are included in the reference implementation:
ethankosakovsky/bip85@master...BenWestgate:bip85:master

Mailing List
Discussion: https://groups.google.com/g/bitcoindev/c/--lHTAtq0Qc

Status
Ready for editorial review. This change is additive and does not modify existing BIP-85 behaviour.

[akarve]

Documenting recent discussions:
@BenWestgate Please see my mailing list comments to your thread with suggestions and simplifications (path, byte extraction, idx, etc.). Regarding 1.4.0 the main thing is we want to warrant full compatibility (all features) up to the prior version and (just saw you reopened 68) a PR to the 1.3.0 client is probably the easiest way to achieve that. Lmk if anything is unclear.

[BenWestgate]

Documenting recent discussions: @BenWestgate Please see my mailing list comments to your thread with suggestions and simplifications (path, byte extraction, idx, etc.). Regarding 1.4.0 the main thing is we want to warrant full compatibility (all features) up to the prior version and (just saw you reopened 68) a PR to the 1.3.0 client is probably the easiest way to achieve that. Lmk if anything is unclear.

1.3.0 client seems to deeply expect not more than two path parameters before the bip85 index.

To make our akarve/bipsea PR as simple as possible, we need to consolidate hrp, threshold, n, byte_length and identifier paths into two. There's plenty of space.

There's a few ways to do this, if you have a favorite or one that immediately stands out as obvious let me know, otherwise I'll try a few until I like how it looks.

I think `m/83696968'/93'/{hrp}'/{cat({n} {threshold} {byte_length}}'/{index}'

hrp is alone as it's unknown how many future human-readable prefixes there may be.

n will always be ''1'' through ''31'', t ''0'', or ''2'' through ''9'', byte_length ''16'' through ''64''. So we can decimal concatenate them with the max value being: 31 9 64 -> 31964'

I'm thinking the identifier could be the bech32 encoding of the index, as the purpose of incrementing the index is to get new seeds, and BIP93 says "...the identifier SHOULD be distinct for all master seeds the user may need to disambiguate."

index = 0 -> identifier = qqqq, index = 1 -> identifier qqqp, and so on. A particular identifier can be selected by converting it to an integer {index} once index reaches 32^4, it can fall back to the default BIP-0032 fingerprint.

[jonatack]

Pinging @scgbckbone (who has been active on BIP85 review) for feedback.