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

[Aneesh Karve <aneesh.karve@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 11418 bytes --]

Regarding my comment on 'hrp' I do see you have a table for that, which is 
clear enough. It's intended as an enum, although I don't see "cl" in 
BIP-93, the same way I see "ms"?

Is there anything we can do to simplify or clarify the derivation paths? 
They are not "wrong" per se but these will be the longest derivation paths 
in the BIP-85 spec and I'm wondering if there's room for "less is more" in 
the derivation path.

> Pseudocode: character_value = int.from_bytes(drng.read(1), "big") >> 3

This is sensible with respect to deriving a single bech32 character but 
here and in the description above the number of characters we are drawing 
could be clarified consistent with the "Bytes Length Table" and there also 
it should be clarified if this is bytes drawn or bytes retained or 
something else. It could further be clarified that all draws are from the 
same DRNG instance. For example, elsewhere in BIP-85 we pass the .read 
*method* (not an invocation) since in RSA key gen the number of draws is 
unknown ahead of time. In your case the number of draws is known but again 
the pseudocode should clarify how many draws or iterations to obtain a 
complete share or secret as a function of the derivation path segments.

Drawing and truncating a single byte per character is certainly clear to 
understand but I keep wondering if implementers shouldn't draw ((chars * 5) 
// 8) bytes in one shot? These bytes aren't expensive or anything but it's 
less iterations, less total reads, etc. If my suggestion becomes hard to 
read or write then feel free to keep as is.

On Thursday, September 4, 2025 at 9:50:57 AM UTC-7 Ben Westgate wrote:

> 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
>
> On Tuesday, September 2, 2025 at 4:37:20 AM UTC-5 Javier Mateos wrote:
>
> 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
>
> El lunes, 1 de septiembre de 2025 a las 20:15:11 UTC-3, Ben Westgate 
> escribió:
>
> 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
>
>
> On Monday, September 1, 2025 at 6:34:39 AM UTC-5 Javier Mateos wrote:
>
> 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
>
> El domingo, 31 de agosto de 2025 a las 19:29:46 UTC-3, Ben Westgate 
> escribió:
>
> 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)* 
> <https://github.com/bitcoin/bips/blob/master/bip-0093.mediawiki> as an 
> application of
> *BIP-0085 (Deterministic Entropy from BIP32 Keychains) 
> <https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki>*, 
> 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 
>    <https://github.com/bitcoin/bitcoin/pull/32652?utm_source=chatgpt.com> 
>    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 
> <https://github.com/bitcoin/bips/compare/master...BenWestgate:bips:codex32?utm_source=chatgpt.com>
>
> Feedback is welcome.
> Best regards,
> Ben Westgate
>
>
>
> On Tuesday, September 2, 2025 at 4:37:20 AM UTC-5 Javier Mateos wrote:
>
>> 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
>>
>> El lunes, 1 de septiembre de 2025 a las 20:15:11 UTC-3, Ben Westgate 
>> escribió:
>>
>>> 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
>>>
>>>
>>> On Monday, September 1, 2025 at 6:34:39 AM UTC-5 Javier Mateos wrote:
>>>
>>>> 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
>>>>
>>>> El domingo, 31 de agosto de 2025 a las 19:29:46 UTC-3, Ben Westgate 
>>>> escribió:
>>>>
>>>>> 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)* 
>>>>> <https://github.com/bitcoin/bips/blob/master/bip-0093.mediawiki> as 
>>>>> an application of
>>>>> *BIP-0085 (Deterministic Entropy from BIP32 Keychains) 
>>>>> <https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki>*, 
>>>>> 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 
>>>>>    <https://github.com/bitcoin/bitcoin/pull/32652?utm_source=chatgpt.com> 
>>>>>    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 
>>>>> <https://github.com/bitcoin/bips/compare/master...BenWestgate:bips:codex32?utm_source=chatgpt.com>
>>>>>
>>>>> Feedback is welcome.
>>>>> Best regards,
>>>>> Ben Westgate
>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/70561361-7237-43e8-bfb0-071c6fd60d54n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 17676 bytes --]