From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 04 Sep 2025 09:51:05 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uuDAt-0007Pj-Tl for bitcoindev@gnusha.org; Thu, 04 Sep 2025 09:51:04 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-3197d9e1c38sf1080326fac.3 for ; Thu, 04 Sep 2025 09:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1757004657; x=1757609457; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to: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=8vK2HD0OfBcX+Zb2DFjRBLzgrBYq34PhBbYI9Art1V8=; b=OVg7MNnGSTaCQE+Tvn3e7QdYAPh3cw694zQBg+hGdPY7+ZovqJQ2o7YZLPT9uEfPYt yzs6BRhs8dk7muslA176h/l2ihHkTPUq/heVwrnVfhruVKmJMOiuUomjWBeCoQF0oMSn 0kkqtbKJN5ZUb5M/k+huiFMIyp0TDEY9r7q//UqO3HhWQQ22yjOzWMnWS32wJ0az5wD+ EZdXNINo7yYbUKBIM+qScQVa2P9vw48UEDAtGvYY3DD733k9abpsKCd4pm3L87NNBmow BLVCpXiCoe3BJCGMMLA0UIxiPVpeFiYDkWXy5jE/eNS7e+IMIxYBTbdpj8ZGNiJViS4q D9kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757004657; x=1757609457; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8vK2HD0OfBcX+Zb2DFjRBLzgrBYq34PhBbYI9Art1V8=; b=xAXjU27pq1UKKYkxjWYDyi35XuWR1tH9+zBBedDXovF9i7csTjYCiUcxxQmFRlRqGT LW02A3PtBcI54bN0ZT/4PQHQLK5PSaqbJO9tq1VZmCMVz9ioAFblnjJEXOwHbqkdSLiy yhyZws9K3Y1AQML+jdV/j5UQ+9dtw4TT8Ob9BWJKSo/m7PNXgTNsiGswgRoLiW9gk5Fx FMTLl2eLqTg042Wd3sn7UVvJeu4EQQThTKwe071wdjUyCsuMYsiMXjRr3cEtIC3cjgfS 4006Q4ehATQUV/sCqzzVyhQEdRko8JQz8nvvuX4PRcfz78/ijc0Y3P7KqznLvYXp3w10 +U6A== X-Forwarded-Encrypted: i=1; AJvYcCVBGDEou2585ElyfNCZb1EYGRi+16lXrmsEV1F7wNZ3W0Iqjzl17FHNSxNMLQYK848jB4nxU59bYE0h@gnusha.org X-Gm-Message-State: AOJu0YzaNWthTWI33EXQ46ySv0MJ89F1/RpBOUHpqayOdj8sOUPqna53 oZhJmSQLOgveeGm5odTqqMex4NrFh9n+9EDSWaQhM4VXBQMXolg3HS9H X-Google-Smtp-Source: AGHT+IEMRx+QW5fmKCO6oVoEupOO5oJtJewU5bKvVbsWJANO8SyjemUm8Vw2LpxERdIThaCCIDRLFw== X-Received: by 2002:a05:6870:7007:b0:300:d9f4:dfaa with SMTP id 586e51a60fabf-31963347379mr10450566fac.27.1757004657096; Thu, 04 Sep 2025 09:50:57 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZf5w98GGguxHFFdycJuEUNhfqKVFbvaJ8aztUR8oace+g== Received: by 2002:a05:6871:81d1:10b0:319:c62c:c8e0 with SMTP id 586e51a60fabf-319c62cd023ls1477227fac.0.-pod-prod-07-us; Thu, 04 Sep 2025 09:50:54 -0700 (PDT) X-Received: by 2002:a05:6808:3309:b0:438:3df9:8867 with SMTP id 5614622812f47-4383df990dcmr1543859b6e.18.1757004653910; Thu, 04 Sep 2025 09:50:53 -0700 (PDT) Received: by 2002:a05:690c:2b83:b0:71b:f426:a5b0 with SMTP id 00721157ae682-72281037cc5ms7b3; Tue, 2 Sep 2025 17:44:08 -0700 (PDT) X-Received: by 2002:a05:690c:4d84:b0:71b:f83a:afa0 with SMTP id 00721157ae682-7227640e8a2mr169026227b3.22.1756860247555; Tue, 02 Sep 2025 17:44:07 -0700 (PDT) Date: Tue, 2 Sep 2025 17:44:07 -0700 (PDT) From: "'Ben Westgate' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <4064eb1b-f430-4ccd-958e-aa03c653439dn@googlegroups.com> In-Reply-To: <9513ab67-511b-4f24-bcfe-e77e8d9112cdn@googlegroups.com> References: <774faeb9-6c6b-4545-8071-56ec03e78cd0n@googlegroups.com> <8a0d48f9-bc15-492f-8b81-14dac4729a5cn@googlegroups.com> <9513ab67-511b-4f24-bcfe-e77e8d9112cdn@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_390004_422932088.1756860247256" X-Original-Sender: BenWestgate@Protonmail.com X-Original-From: Ben Westgate Reply-To: Ben Westgate 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: -1.0 (-) ------=_Part_390004_422932088.1756860247256 Content-Type: multipart/alternative; boundary="----=_Part_390005_364410716.1756860247256" ------=_Part_390005_364410716.1756860247256 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 RNG= =20 entropy to maintain information-theoretic security. - see value in it to stretch entropy when users won=E2=80=99t provide enoug= h 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 wro= te: Hi Ben, Thank you for implementing those changes so promptly. I reviewed the commit= =20 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 pattern= =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 and= =20 row to the n table to clarify the t=3D=3D0 constraint on n, removed the not= es=20 and in the unshared secret section made the normative statement: 'When thre= shold=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 re= view. Commit:=20 https://github.com/BenWestgate/bips/commit/fa6e9788bf04d271792ed4ea89a112d1= 2284ef02 Best regards, Ben Westgate On Monday, September 1, 2025 at 6:34:39=E2=80=AFAM UTC-5 Javier Mateos wrot= e: 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 ps= eudocode=20 to avoid implementation variations 2) The rule 'threshold =3D=3D 0 implies n =3D=3D 1' currently appears as a = note but=20 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 wallet = 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 *, similar= =20 to the existing BIP39 application. This allows wallets to derive codex32=20 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}'/{i= d2}'/{id3}'/{index}'=20 =20 Codex32, defined in BIP-93, is a human-readable encoding with checksumming= =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 wro= te: > 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= =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 your= review. >> >> Commit:=20 >> https://github.com/BenWestgate/bips/commit/fa6e9788bf04d271792ed4ea89a11= 2d12284ef02 >> >> Best regards, Ben Westgate >> >> >> On Monday, September 1, 2025 at 6:34:39=E2=80=AFAM UTC-5 Javier Mateos w= rote: >> >>> 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 explici= t=20 >>> pseudocode to avoid implementation variations >>> 2) The rule 'threshold =3D=3D 0 implies n =3D=3D 1' currently appears a= s 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 wa= llet=20 >>>> backups 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 deri= ve=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=20 >>>> checksumming and share indexing designed for SSS backups of BIP-0032 s= eeds.=20 >>>> This PR proposes a deterministic way to generate codex32 strings using= =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:code= x32=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/= 4064eb1b-f430-4ccd-958e-aa03c653439dn%40googlegroups.com. ------=_Part_390005_364410716.1756860247256 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks Javier for con= firming my updates address your concerns,

Andrew Poelstra a= nd 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.
<= div>- prefer wallets generate t fresh initial strings by directly encoding RNG entropy to ma= intain information-theoretic security.
- see value in it to stretch entropy when users won=E2=80=99t provide enoug= h for direct encoding but don't trust their hRNG<= /span>.
- consid= er codex32 backups for a bip85 root keys a very good idea.

I welcome further feed= back 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=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 = 2025 a las 20:15:11 UTC-3, Ben Westgate escribi=C3=B3:

Hi Javier,

Thank you for your feedbac= k.

I added pseudocode = for the character value selection. I added a column and row to the n table = to clarify the t=3D=3D0 constraint on n, removed the notes and in the unsha= red 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 review.

Commit: https://github.com/BenWestgate/bips/commi= t/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-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 ext= raction process could benefit from explicit pseudocode to avoid implementat= ion variations
2) The rule 'threshold =3D=3D 0 implies n =3D=3D 1' cur= rently 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 escri= bi=C3=B3:

Hello bitcoin-d= ev,

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

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

Summary

  • Application number: 93'

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

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 coul= d use the BIP-85 dice application, but defining a direct application improv= es interoperability.

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

Feedback is welcome.

= Best regards,
Ben Westgate


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 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/4064eb1b-f430-4ccd-958e-aa03c653439dn%40googlegroups.com.
------=_Part_390005_364410716.1756860247256-- ------=_Part_390004_422932088.1756860247256--