From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 07 Sep 2025 18:09:35 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uvQNx-0006oT-SC for bitcoindev@gnusha.org; Sun, 07 Sep 2025 18:09:35 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-319c9bb72e1sf6560032fac.0 for ; Sun, 07 Sep 2025 18:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1757293767; x=1757898567; 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=ETZBolCKpdxCdA2zeUmxW/IjhmjQcrIx7cx1D26bRTg=; b=A+V/Xmv17rOghZXPkq9HhJUh6u/HdEqgGdIsOyUQqEkOJaXVzs898rTckD6TZI39+u xwdq2aT5m/mnJlu9wvwr8Vwj7oW/XA2Y9gQzmruGI6vczDms9gLT8V6LeMFPBY+ijwvP Agny/LT96rPdFPBzoF7Gnm6bDnOrgSQ5TmKSCjdxfD9oLwKeRhxWHZtCu6h3iLAgzwfl zqt5NKZfwy5bMrmqgETLeGWgCdjXC3EqLgt7XMbN7SCe7u96Q9Q6sFRdvR/LGW49aOF0 yBUOzpHG4TwbGe6gEDVbq1KFz3ThduTzfqn27UR0tcKIH1o/bylsckAB4etjVtxREOwg JSoQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757293767; x=1757898567; 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=ETZBolCKpdxCdA2zeUmxW/IjhmjQcrIx7cx1D26bRTg=; b=ZuHMNQEPBc1CoeRBUN3Wi2Hvp0kaHlgkD61lACGTf3lD9DRq1xT9UZR+Gj/TlZAOup k2NZVbw838OfAX/zFJvmcHYoiJyrJI7Yflp/C6DJUK6dxvxkTx9Wpk15XPRNIso3pwOT lMwxDzqUVEAXDhZbNwWH2f9c+CBFTHNDD2+IZtEJ3McmPW6IiYmUWY26s4b3taYMrce2 kNjFkfRnnR2C7vO/6WSptJCV6oe3W6lO2MICtD9QcbCPCKFo/61W7wqymx6lNwndVCgi OVstjSiFib9WCJVrGHtSTi+5XFv1i4uN0/+GAB2yK+pQ/k/nPyJto7555sYIqc33X2MC MfkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757293767; x=1757898567; 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=ETZBolCKpdxCdA2zeUmxW/IjhmjQcrIx7cx1D26bRTg=; b=op6SGRpLNuo4abo45a6j7PFkZrrTnAVW3IAHy2BMkJsaZEn6bI45FeeKJZndxpJ+xQ Os6qeaJ/NZ2gt1CNQ3hNvnS0lyQP3mamCNXQztPdnLLNXVq39amMJDkwE8BbT3tWhV3/ lcyFYkCN73zF3mzZpLjRDQNp7M1S3XcJTIkZGQ0qdNaIv5JyLIbrBNU+LZAjA1br3uuS YmCYXE6LMDHh2l9xqd50tUHAu/bZOXtvaxo6GKIHRkux4LdI6y+AUDUwT8LFNqrnzDrw gTPEZ1SdEfSFTPfQk1eqPDakp55odaCiMMsM9MimtLEXseh0syt/Iea8nF0u9yXG5f1H TqqA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVQ+rFiR+vmzU1tDN5vuRldGO7PmYLxoLZUFB3qLgM/TcHlFU+vKU65DsuQZrKPBwd/a3dCDm/XoKbq@gnusha.org X-Gm-Message-State: AOJu0YyQdx/IrVoyy5hWvbLtEYYoWnWRApWa723aOUVWVbx3anzceTVn EQQSeUISdVJUxe7q2t//xXQU3vyp0YL74S2HWtSKCqgXIhcOOiJJBKm7 X-Google-Smtp-Source: AGHT+IGrq2XMnWmlynDHTyBCFnWFED0LgDz6QypO1rKU9NrTwQz3fj1kfImq0ywKSNJnS9EtiMWIGg== X-Received: by 2002:a05:6871:eb07:b0:30b:6fa2:695a with SMTP id 586e51a60fabf-32262c73991mr1943857fac.11.1757293767033; Sun, 07 Sep 2025 18:09:27 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARHlJd4mMIdMt3xzcFE7zTOA3NeeSJS41n+35SJBxsNTEe78YQ== Received: by 2002:a05:6870:5490:b0:30b:b85a:bd67 with SMTP id 586e51a60fabf-31d7b3560e2ls1381611fac.2.-pod-prod-00-us-canary; Sun, 07 Sep 2025 18:09:23 -0700 (PDT) X-Received: by 2002:a05:6808:6f84:b0:438:2278:937 with SMTP id 5614622812f47-439ae505a69mr5504248b6e.2.1757293763092; Sun, 07 Sep 2025 18:09:23 -0700 (PDT) Received: by 2002:a0d:e541:0:b0:720:768:1935 with SMTP id 00721157ae682-72a04d07a8bms7b3; Sun, 7 Sep 2025 13:43:01 -0700 (PDT) X-Received: by 2002:a05:690c:3602:b0:720:4a2a:2050 with SMTP id 00721157ae682-72542cf0f4dmr89117757b3.8.1757277780106; Sun, 07 Sep 2025 13:43:00 -0700 (PDT) Date: Sun, 7 Sep 2025 13:42:59 -0700 (PDT) From: Aneesh Karve To: Bitcoin Development Mailing List Message-Id: <78df4103-95f9-4eec-bf84-07977b831929n@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_261654_1714996377.1757277779640" 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_261654_1714996377.1757277779640 Content-Type: multipart/alternative; boundary="----=_Part_261655_408903722.1757277779640" ------=_Part_261655_408903722.1757277779640 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Howdy, a few issues to address for the benefit of future implementers: 1. The reference implementation should be a PR to the 1.3.0=20 implementation (I'll help) so we don't confuse the history or introduce= =20 compatibility issues. 1.3.0 brings a lot more unit tests, composability,= =20 etc. Ethan's original repo ,= =20 which the proposed reference hangs off, has been stagnant for about 4=20 years, doesn't implement the fixes in 1.3.0, etc. 2. The usage of the hrp (human readable prefix) is unclear to me.=20 Traditional path segments are integers and in the examples so is the hrp= =20 but it's also defaulted to"ms" and not clear for implementers how the pa= th=20 should be represented numerically if at all? 3. Similarly the role, nature (relative to the SSSS), and programmatic= =20 structure of the identifiers (idX) is unclear. 2 & 3 should be easily addressed with small changes to the diff; I'd=20 suggest breaking down and explaining each path segment more clearly. 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/= 78df4103-95f9-4eec-bf84-07977b831929n%40googlegroups.com. ------=_Part_261655_408903722.1757277779640 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Howdy, a few issues to address for the benefit of future implementers:
=
  1. The reference implementation should be a PR to the 1.3.0 implementa= tion (I'll help) so we don't confuse the history or introduce compatibility= issues. 1.3.0 brings a lot more unit tests, composability, etc. Ethan's original repo, which= the proposed reference hangs off,=C2=A0has been stagnant for about 4 years= , doesn't implement the fixes in 1.3.0, etc.
  2. The usage of the hrp (= human readable prefix) is unclear to me. Traditional path segments are inte= gers and in the examples so is the hrp but it's also defaulted to"ms" and n= ot clear for implementers how the path should be represented numerically if= at all?
  3. Similarly the role, nature (relative to the SSSS), and pro= grammatic structure of the identifiers (idX) is unclear.
2 &a= mp; 3 should be easily addressed with small changes to the diff; I'd sugges= t breaking down and explaining each path segment more clearly.
<= div>
On Thursday, September 4, 2025 at 9:50:57=E2=80=AFAM UTC-7 Ben Westg= ate wrote:

Thanks Javier for confirm= ing my updates address your concerns,

Andrew Poelstra and <= span>Russell O'Connor gave feedback on the bip85 codex32 applicat= ion, 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.
<= span>
- see value in it to stretch entropy when users won=E2=80=99t provi= de enough for direct encoding but don't trust their = hRNG.
- consider codex32 backups for a bip85 root keys a very good idea.

I welcome furthe= r 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


<= 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/78df4103-95f9-4eec-bf84-07977b831929n%40googlegroups.com.
------=_Part_261655_408903722.1757277779640-- ------=_Part_261654_1714996377.1757277779640--