From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 07 Sep 2025 18:09:38 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uvQO1-0006oo-F5 for bitcoindev@gnusha.org; Sun, 07 Sep 2025 18:09:38 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-3199dccf133sf6083950fac.2 for ; Sun, 07 Sep 2025 18:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1757293771; x=1757898571; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=qVv7CivSyck4ds6Dfws9u5+aurV/WE219GFCXFLwgs8=; b=oFNcMehqX1sEj8vy+EMg/mdkB66CJllCcAusitYX9EpED6dSSb/YytvbUjvkpweMMF dXe2Vq0T28svVVGoXAAAHtddvWbkOKhUhM2phT9pxWSzAfVrMyEoWYbDVZc3RjTtl3f9 sqpudmA1i6N8RX2uKmDU+NyUwtq/cxIYNjbALQf2HkE/Y1GXaAmft0YCOZ3Hbte9/I68 qVnEP9MfTx3KHCLUqNvGXROT6iSUGOBAOHYoEWix+hPH7Qo9N7/a/waIqBiYLn4rBUH1 fiEw5KEIeA/ImFRNksr0cpgipFEnyh7Ny2ri/CfHUtgjazVWWXW9bsfLViL2KqpNfHK9 JS4Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757293771; x=1757898571; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=qVv7CivSyck4ds6Dfws9u5+aurV/WE219GFCXFLwgs8=; b=Fmg8RX2NTNi8koR7oxD+8zgPp7SykdKoyo84vwkkqQ9tQRXIBbTeLvCNEJROZKNGyg VGF/RnCtwkNKnAJwxaPS4fVuunmsfeGq7PI4CLObRyhnUoC8LOFLTsNaL0ld2k7SwkfP S2HyeL+4dARy7SjgTnOCm6SS8XnFMEwdRESHLV+qSmaLFSAr8arrrIrx2RwWyDUTIEe6 ZWVlS1Flf5JlMI5yMpMiW+R5Byp9g1ZablwiD1YWXBfCtbMWBWKAyI7/Z82guSnlY1Fy cCOSui4p6TD7vzHRoPOjnpfmCFBITduzt6aMZCs+BQm1HLn690c5Qkr4fWG7Sv2aAAtd iIlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757293771; x=1757898571; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=qVv7CivSyck4ds6Dfws9u5+aurV/WE219GFCXFLwgs8=; b=prQZGbFxBB164jUBnucjL76fTUQ2AqyFqRZGoDwV4fkdoXyrOZLNuRW2Ah2JPZEHsN DDqHJgyTmjK2XqWYqE1ixaX7XvPcz7nuCjjHm8RlMSLjnjvi0IxD7u5+/v7ZZyxuWjfI uvuFLSf44+Tk1UbcGuvto2ru69nzaUxvHC5Z2RKLHhQTdIbJ26K4Eo/3c2Am7GQFijTq LFJ2JYiQbFAW7AhTOJ30ZmmzS7agZVait5AiMl+tbtcdjAf5pjAhbm+tl65iRBIGoywE Bi/TF7fTkowIQ55RUzKcEGEypTBVxeZEjd7X0l4ttpgvh0Hj/7zK6f5jlLF2rXsBiHFl fL9g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWh1o6YToFk9VKEfLP4pFDVZ7ojLV2seFYxJ/WHCLKiSZWXw516A0d9zrIJe5H7ff1+dUhX3QKcj3Cd@gnusha.org X-Gm-Message-State: AOJu0YyrBN1sYbwkO3Nt5KIvGtl8R2rrz6BtpXDSbH313qomjhhMFj/t Ajc/A9eQUw6RKcEKym3F1PJ/hI760qCu0rufBO1f5t0UCMx+g3T9AyV5 X-Google-Smtp-Source: AGHT+IHDHpSNl3utQk9mXjeZexyssH51SWzHei7c64SFH84JVlS8BlMMtFbIAS6qp9t5xsQcrDOlmA== X-Received: by 2002:a05:6870:6b0a:b0:315:2ed1:6fc9 with SMTP id 586e51a60fabf-322631a883cmr3447218fac.17.1757293771076; Sun, 07 Sep 2025 18:09:31 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARHlJd5jD+/v4x1Ug2rL4bKMY90gE4FvQZj2YiBeuOuRqjHBJQ== Received: by 2002:a05:6871:e28d:b0:31b:197d:1f2a with SMTP id 586e51a60fabf-3212712316els1531393fac.1.-pod-prod-09-us; Sun, 07 Sep 2025 18:09:27 -0700 (PDT) X-Received: by 2002:a05:6808:7007:b0:439:b9f5:b0a5 with SMTP id 5614622812f47-43b29a22ebbmr2793321b6e.19.1757293767183; Sun, 07 Sep 2025 18:09:27 -0700 (PDT) Received: by 2002:a05:690c:a1cc:b0:725:2535:e36 with SMTP id 00721157ae682-725dac7b388ms7b3; Sun, 7 Sep 2025 16:13:19 -0700 (PDT) X-Received: by 2002:a05:690c:64c7:b0:721:1fda:e316 with SMTP id 00721157ae682-727f4e61148mr50180367b3.29.1757286798216; Sun, 07 Sep 2025 16:13:18 -0700 (PDT) Date: Sun, 7 Sep 2025 16:13:17 -0700 (PDT) From: Aneesh Karve To: Bitcoin Development Mailing List Message-Id: <70561361-7237-43e8-bfb0-071c6fd60d54n@googlegroups.com> In-Reply-To: <4064eb1b-f430-4ccd-958e-aa03c653439dn@googlegroups.com> References: <774faeb9-6c6b-4545-8071-56ec03e78cd0n@googlegroups.com> <8a0d48f9-bc15-492f-8b81-14dac4729a5cn@googlegroups.com> <9513ab67-511b-4f24-bcfe-e77e8d9112cdn@googlegroups.com> <4064eb1b-f430-4ccd-958e-aa03c653439dn@googlegroups.com> Subject: [bitcoindev] Re: [BIP Proposal] Add BIP-0093 (Codex32) as application to BIP-0085 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_341894_1966059391.1757286797719" X-Original-Sender: aneesh.karve@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_341894_1966059391.1757286797719 Content-Type: multipart/alternative; boundary="----=_Part_341895_353841037.1757286797719" ------=_Part_341895_353841037.1757286797719 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Regarding my comment on 'hrp' I do see you have a table for that, which is= =20 clear enough. It's intended as an enum, although I don't see "cl" in=20 BIP-93, the same way I see "ms"? Is there anything we can do to simplify or clarify the derivation paths?=20 They are not "wrong" per se but these will be the longest derivation paths= =20 in the BIP-85 spec and I'm wondering if there's room for "less is more" in= =20 the derivation path. > Pseudocode: character_value =3D int.from_bytes(drng.read(1), "big") >> 3 This is sensible with respect to deriving a single bech32 character but=20 here and in the description above the number of characters we are drawing= =20 could be clarified consistent with the "Bytes Length Table" and there also= =20 it should be clarified if this is bytes drawn or bytes retained or=20 something else. It could further be clarified that all draws are from the= =20 same DRNG instance. For example, elsewhere in BIP-85 we pass the .read=20 *method* (not an invocation) since in RSA key gen the number of draws is=20 unknown ahead of time. In your case the number of draws is known but again= =20 the pseudocode should clarify how many draws or iterations to obtain a=20 complete share or secret as a function of the derivation path segments. Drawing and truncating a single byte per character is certainly clear to=20 understand but I keep wondering if implementers shouldn't draw ((chars * 5)= =20 // 8) bytes in one shot? These bytes aren't expensive or anything but it's= =20 less iterations, less total reads, etc. If my suggestion becomes hard to=20 read or write then feel free to keep as is. On Thursday, September 4, 2025 at 9:50:57=E2=80=AFAM UTC-7 Ben Westgate wro= te: > Thanks Javier for confirming my updates address your concerns, > Andrew Poelstra and Russell O'Connor gave feedback on the bip85 codex32= =20 > application, they: > - support it for recoverable "uncle-Jim"-style child codex32 strings for= =20 > forgetful relatives. > - prefer wallets generate t fresh initial strings by directly encoding=20 > RNG entropy to maintain information-theoretic security. > - see value in it to stretch entropy when users won=E2=80=99t provide eno= ugh for=20 > 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:=20 > https://github.com/bitcoin/bips/compare/master...BenWestgate:bips:codex32 > > Best regards, Ben Westgate > > On Tuesday, September 2, 2025 at 4:37:20=E2=80=AFAM UTC-5 Javier Mateos w= rote: > > Hi Ben, > > Thank you for implementing those changes so promptly. I reviewed the=20 > commit and the updates address both concerns effectively. > > These changes should ensure consistent implementations across different= =20 > codex32 tooling that uses BIP-85 derivation. > > The proposal looks technically sound, follows BIP-85's established patter= n=20 > for applications, and is supported by comprehensive test vectors and a=20 > reference implementation.=20 > > 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=20 > escribi=C3=B3: > > Hi Javier, > > Thank you for your feedback.=20 > > I added pseudocode for the character value selection. I added a column an= d=20 > row to the n table to clarify the t=3D=3D0 constraint on n, removed the n= otes=20 > and in the unshared secret section made the normative statement: 'When th= reshold=20 > =3D=3D "0", n MUST be *1* and the output is a codex32 secret.' > > I=E2=80=99ve updated the PR with these changes and would appreciate your = review. > > Commit:=20 > https://github.com/BenWestgate/bips/commit/fa6e9788bf04d271792ed4ea89a112= d12284ef02 > > Best regards, Ben Westgate > > > On Monday, September 1, 2025 at 6:34:39=E2=80=AFAM UTC-5 Javier Mateos wr= ote: > > Hi Ben, > > Thank you for your proposal to integrate BIP-0093 (codex32) as an=20 > application within BIP-0085 > > Reviewing the specification, I believe I see two areas where we could=20 > improve clarity for implementers: > > 1) The DRNG=E2=86=925-bit extraction process could benefit from explicit= =20 > pseudocode to avoid implementation variations > 2) The rule 'threshold =3D=3D 0 implies n =3D=3D 1' currently appears as = a note=20 > 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=20 > escribi=C3=B3: > > Hello bitcoin-dev, > > I=E2=80=99m Ben Westgate, a contributor interested in deterministic walle= t backups=20 > and seed management. > > Per BIP-0002, I propose listing *BIP-0093 (codex32)*=20 > as an=20 > application of > *BIP-0085 (Deterministic Entropy from BIP32 Keychains)=20 > *,=20 > similar to the existing BIP39 application. This allows wallets to derive= =20 > codex32 backups from BIP-0032 master keys. > > *Summary*=20 > > -=20 > =20 > Application number: 93' > - Derivation path:=20 > m/83696968'/93'/{hrp}'/{threshold}'/{n}'/{byte_length}'/{id0}'/{id1}'/= {id2}'/{id3}'/{index}'=20 > =20 > Codex32, defined in BIP-93, is a human-readable encoding with checksummin= g=20 > and share indexing designed for SSS backups of BIP-0032 seeds. This PR=20 > proposes a deterministic way to generate codex32 strings using BIP-85. > > *Rationale*=20 > > -=20 > =20 > Mirrors the existing BIP-85 application for BIP-39. > -=20 > =20 > Codex32 offers error correction, hand verification, identifiers, and= =20 > secret sharing features compared to BIP-39. > -=20 > =20 > Adds a standardized way for wallets to generate codex32 backups from= =20 > BIP-85-derived entropy > -=20 > =20 > Test vectors and reference implementation are linked to in the PR. > =20 > *Risks and alternatives*=20 > > -=20 > =20 > Wallet adoption of codex32 is still limited, though a draft PR #32652= =20 > =20 > for importing codex32 strings to Bitcoin Core has support. > - Codex32 implementers could use the BIP-85 dice application, but=20 > defining a direct application improves interoperability. > > PR:=20 > https://github.com/bitcoin/bips/compare/master...BenWestgate:bips:codex32= =20 > > > Feedback is welcome. > Best regards, > Ben Westgate > > > > On Tuesday, September 2, 2025 at 4:37:20=E2=80=AFAM UTC-5 Javier Mateos w= rote: > >> Hi Ben, >> >> Thank you for implementing those changes so promptly. I reviewed the=20 >> commit and the updates address both concerns effectively. >> >> These changes should ensure consistent implementations across different= =20 >> codex32 tooling that uses BIP-85 derivation. >> >> The proposal looks technically sound, follows BIP-85's established=20 >> pattern for applications, and is supported by comprehensive test vectors= =20 >> and a reference implementation.=20 >> >> 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=20 >> escribi=C3=B3: >> >>> Hi Javier, >>> >>> Thank you for your feedback.=20 >>> >>> I added pseudocode for the character value selection. I added a column= =20 >>> and row to the n table to clarify the t=3D=3D0 constraint on n, removed= the=20 >>> notes and in the unshared secret section made the normative statement:= =20 >>> 'When threshold =3D=3D "0", n MUST be *1* and the output is a codex32= =20 >>> secret.' >>> >>> I=E2=80=99ve updated the PR with these changes and would appreciate you= r review. >>> >>> Commit:=20 >>> https://github.com/BenWestgate/bips/commit/fa6e9788bf04d271792ed4ea89a1= 12d12284ef02 >>> >>> Best regards, Ben Westgate >>> >>> >>> On Monday, September 1, 2025 at 6:34:39=E2=80=AFAM UTC-5 Javier Mateos = wrote: >>> >>>> Hi Ben, >>>> >>>> Thank you for your proposal to integrate BIP-0093 (codex32) as an=20 >>>> application within BIP-0085 >>>> >>>> Reviewing the specification, I believe I see two areas where we could= =20 >>>> improve clarity for implementers: >>>> >>>> 1) The DRNG=E2=86=925-bit extraction process could benefit from explic= it=20 >>>> pseudocode to avoid implementation variations >>>> 2) The rule 'threshold =3D=3D 0 implies n =3D=3D 1' currently appears = as a note=20 >>>> 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=20 >>>> escribi=C3=B3: >>>> >>>>> Hello bitcoin-dev, >>>>> >>>>> I=E2=80=99m Ben Westgate, a contributor interested in deterministic w= allet=20 >>>>> backups and seed management. >>>>> >>>>> Per BIP-0002, I propose listing *BIP-0093 (codex32)*=20 >>>>> as= =20 >>>>> an application of >>>>> *BIP-0085 (Deterministic Entropy from BIP32 Keychains)=20 >>>>> *,=20 >>>>> similar to the existing BIP39 application. This allows wallets to der= ive=20 >>>>> codex32 backups from BIP-0032 master keys. >>>>> >>>>> *Summary*=20 >>>>> >>>>> -=20 >>>>> =20 >>>>> Application number: 93' >>>>> - Derivation path:=20 >>>>> m/83696968'/93'/{hrp}'/{threshold}'/{n}'/{byte_length}'/{id0}'/{id= 1}'/{id2}'/{id3}'/{index}'=20 >>>>> =20 >>>>> Codex32, defined in BIP-93, is a human-readable encoding with=20 >>>>> checksumming and share indexing designed for SSS backups of BIP-0032 = seeds.=20 >>>>> This PR proposes a deterministic way to generate codex32 strings usin= g=20 >>>>> BIP-85. >>>>> >>>>> *Rationale*=20 >>>>> >>>>> -=20 >>>>> =20 >>>>> Mirrors the existing BIP-85 application for BIP-39. >>>>> -=20 >>>>> =20 >>>>> Codex32 offers error correction, hand verification, identifiers,= =20 >>>>> and secret sharing features compared to BIP-39. >>>>> -=20 >>>>> =20 >>>>> Adds a standardized way for wallets to generate codex32 backups=20 >>>>> from BIP-85-derived entropy >>>>> -=20 >>>>> =20 >>>>> Test vectors and reference implementation are linked to in the PR. >>>>> =20 >>>>> *Risks and alternatives*=20 >>>>> >>>>> -=20 >>>>> =20 >>>>> Wallet adoption of codex32 is still limited, though a draft PR=20 >>>>> #32652=20 >>>>> =20 >>>>> for importing codex32 strings to Bitcoin Core has support. >>>>> - Codex32 implementers could use the BIP-85 dice application, but= =20 >>>>> defining a direct application improves interoperability. >>>>> >>>>> PR:=20 >>>>> https://github.com/bitcoin/bips/compare/master...BenWestgate:bips:cod= ex32=20 >>>>> >>>>> >>>>> Feedback is welcome. >>>>> Best regards, >>>>> Ben Westgate >>>> >>>> --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 70561361-7237-43e8-bfb0-071c6fd60d54n%40googlegroups.com. ------=_Part_341895_353841037.1757286797719 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 c= an 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 =3D int.from_bytes= (drng.read(1), "big") >> 3

This is sensible with resp= ect to deriving a single bech32 character but here and in the description a= bove 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 cl= arified that all draws are from the same DRNG instance. For example, elsewh= ere 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 d= raws or iterations to obtain a complete share or secret as a function of th= e derivation path segments.

Drawing and truncati= ng 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 sh= ot? 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=E2=80=AFAM UTC-7 Ben Westgate wrote:

Thanks Javier for confirming my updates address your concerns,

A= ndrew Poelstra and Russell O'Connor gave feedb= ack on the bip85 codex32 application, they:
<= span>- support it for recoverable "uncle-Jim"-style child codex32= strings for forgetful relatives.
- prefer wallets generate t fresh initial strings by d= irectly encoding RNG entropy to maintain information-theoretic secur= ity.
<= span>- see value = in it to stretch entropy= when users won=E2=80=99t provide enough for direct encoding but don't trust their hRNG.
- consider codex32 backups for a bip85 ro= ot keys a very good idea.

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

Best regards, Ben Westgate


<= div dir=3D"auto">On Tuesday, September 2, 2025 at 4:37:20=E2=80=AFAM UTC-5 = Javier Mateos wrote:

Hi Ben,

Thank you for implementing those changes so promptly. I reviewed the com= mit 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=20 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 20= 25 a las 20:15:11 UTC-3, Ben Westgate escribi=C3=B3:

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 c= larify the t=3D=3D0 constraint on n, removed the notes and in the unshared = secret section made the normative statement: 'When threshold =3D= =3D "0", n MUST be 1 and the output is= a codex32 secret.'

I= =E2=80=99ve updated the PR with these changes and would appreciate your rev= iew.

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

Best regards, Ben Westgate



On Monday, September 1, 2025= at 6:34:39=E2=80=AFAM UTC-5 Javier Mateos wrote:
Hi Ben,

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

Reviewing the specific= ation, =C2=A0I believe I see two areas where we could improve clarity for i= mplementers:

1) The DRNG=E2=86=925-bit extraction process could bene= fit from explicit pseudocode to avoid implementation variations
2) The r= ule 'threshold =3D=3D 0 implies n =3D=3D 1' currently appears as a = note but could be clearer as a normative requirement"

Best Rega= rds,
Javier Mateos

El domingo, 31 de agost= o de 2025 a las 19:29:46 UTC-3, Ben Westgate escribi=C3=B3:

Hello bitcoin-dev,

I=E2=80=99m Ben Westgate, a contributor interested in deterministic wall= et backups and seed management.

Per BIP-0002, I propose listing BIP-0093 (c= odex32) as an application of
BIP-0085 (Deterministic Entropy from BIP32 Key= chains), 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}'/{in= dex}'

Codex32, defined in BIP-93, is a human-readable encoding with checksumming and=20 share indexing designed for SSS backups of BIP-0032 seeds. This PR=20 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 sec= ret 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 improve= s interoperability.

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

<= p>Feedback is welcome.

Best regards,
Ben Westgate
<= /blockquote>


On Tuesday, Septemb= er 2, 2025 at 4:37:20=E2=80=AFAM UTC-5 Javier Mateos wrote:

Hi Ben,

Thank you for implementing those changes so promptly. I reviewed the com= mit 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 patt= ern 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 Wes= tgate escribi=C3=B3:
<= p dir=3D"auto" style=3D"white-space:pre-wrap">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 c= larify the t=3D=3D0 constraint on n, removed the notes and in the unshared = secret section made the normative statement: 'When threshold =3D= =3D "0", n MUST be 1 and the output is= a codex32 secret.'

I= =E2=80=99ve updated the PR with these changes and would appreciate your rev= iew.

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

Best regards, Ben Westgate



On Monday, September 1, 2025 at 6:34:39=E2=80=AFAM UTC-5 Ja= vier Mateos wrote:
Hi = Ben,

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

Reviewing the specification, =C2=A0I = believe I see two areas where we could improve clarity for implementers:
1) The DRNG=E2=86=925-bit extraction process could benefit from explic= it pseudocode to avoid implementation variations
2) The rule 'thresh= old =3D=3D 0 implies n =3D=3D 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 es= cribi=C3=B3:

Hello = bitcoin-dev,

I=E2=80=99m Ben Westgate, a contributor interested in deterministic wall= et backups and seed management.

Per BIP-0002, I propose listing BIP-00= 93 (codex32) as an application of
BIP-0085 (Deterministic Entropy from BIP3= 2 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}'/{in= dex}'

Codex32, defined in BIP-93, is a human-re= adable encoding with checksumming and share indexing designed for SSS backu= ps of BIP-0032 seeds. This PR proposes a deterministic way to generate code= x32 strings using BIP-85.

Rationale

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

  • Codex32 offers error correction, hand verification, identifiers, and sec= ret 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 improve= s interoperability.

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

<= p>Feedback is welcome.

Best regards,
Ben Westgate
<= /blockquote>

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