Delivery-date: Sat, 06 Jul 2024 19:43:32 -0700
Sender: bitcoindev@googlegroups.com
Date: Sat, 6 Jul 2024 19:10:45 -0700 (PDT)
From: Aneesh Karve <aneesh.karve@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <68895604-0821-483d-b3c5-a0aa711f4158n@googlegroups.com>
In-Reply-To: <72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n@googlegroups.com>
References: <72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n@googlegroups.com>
Subject: [bitcoindev] Re: Idea for BIP : Deterministic Wallets with Token support
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_91826_2069007939.1720318245049"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_91826_2069007939.1720318245049
Content-Type: multipart/alternative; 
	boundary="----=_Part_91827_2049286311.1720318245049"

------=_Part_91827_2049286311.1720318245049
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Not sure this is relevant to a Bitcoin list but I'll answer in a Bitcoin=20
context.

> Simply adding an additional node to the derivation path is not practical=
=20
for various reasons.

What are those reasons?

> I recommend applying the modification at the "Change" node.

The change node does not use hardened derivation and is therefore unlikely=
=20
to suit your security needs. From BIP-32:

> One weakness that may not be immediately obvious, is that knowledge of a=
=20
parent extended public key plus any non-hardened private key descending=20
from it is equivalent to knowing the parent extended private key (and thus=
=20
every private and public key descending from it). This means that extended=
=20
public keys must be treated more carefully than regular public keys. It is=
=20
also the reason for the existence of hardened keys, and why they are used=
=20
for the account level in the tree. This way, a leak of account-specific (or=
=20
below) private keys never risks compromising the master or other accounts.

I may be wrong but I'm not sure that proposing different HMAC params helps=
=20
standardization or Bitcoin in general. I suggest BIP-85 for your purposes,=
=20
expressly to solve the issue of a single secret that is used, in an=20
irreversible way, to populate multiple wallets for multiple purposes. You=
=20
could have a different application code for each token, each of which is=20
derived from a single master secret.

On Saturday, July 6, 2024 at 1:44:37=E2=80=AFPM UTC-7 Forrest96er wrote:

> Hello,
>
> The number of new tokens for Ethereum and Ethereum-like coins has=20
> increased dramatically. However, the wallet structure for managing multip=
le=20
> coins based on a single seed has not been updated to accommodate this new=
=20
> scenario. Currently, all tokens are managed using the same derivation pat=
h,=20
> resulting in the creation of identical addresses across different tokens,=
=20
> significantly reducing privacy. To address this issue, the wallet structu=
re=20
> for HD wallets needs to be updated.
>
> Simply adding an additional node to the derivation path is not practical=
=20
> for various reasons.
>
> A better solution is to use the address or identifier of the token for=20
> creating private and public keys. This can be achieved by adding an=20
> additional input to the HMAC function, which is used to generate child=20
> private and public keys. It is advisable to apply a collision-free hash=
=20
> function before using HMAC.
>
> m / purpose' / coin_type' / account' / change / index
>
> I recommend applying the modification at the "Change" node. Without=20
> modification, the creation of an address for the base coin (no token) is=
=20
> targeted.
>
> With the modification, the token- adress is targeted.
>
> This approach also has the advantage that if hardware wallets are used,=
=20
> only the extended public keys of a coin need to be exported once to the=
=20
> front-end application. After that, the front-end application can generate=
=20
> all public keys needed to scan for transactions on all tokens. Even if a=
=20
> token did not exist at the time of the public key export, it could later =
be=20
> found without any additional export.
>
>   Did I miss something?=20
> If an attacker obtains some public keys used in a transaction for a token=
,=20
> he should not be able to calculate the public keys of other tokens or the=
=20
> base coin. =20
>

--=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 on the web visit https://groups.google.com/d/msgid/=
bitcoindev/68895604-0821-483d-b3c5-a0aa711f4158n%40googlegroups.com.

------=_Part_91827_2049286311.1720318245049
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div>Not sure this is relevant to a Bitcoin list but I'll answer in a Bitco=
in context.</div><div><br /></div>&gt; Simply adding an additional node to =
the derivation path is not practical for various reasons.<br /><br />What a=
re those reasons?<div><br /></div><div>&gt; I recommend applying the modifi=
cation at the "Change" node.</div><div><br /></div><div>The change node doe=
s not use hardened derivation and is therefore unlikely to suit your securi=
ty needs. From BIP-32:</div><div><br /></div><div>&gt;=C2=A0One weakness th=
at may not be immediately obvious, is that knowledge of a parent extended p=
ublic key plus any non-hardened private key descending from it is equivalen=
t to knowing the parent extended private key (and thus every private and pu=
blic key descending from it). This means that extended public keys must be =
treated more carefully than regular public keys. It is also the reason for =
the existence of hardened keys, and why they are used for the account level=
 in the tree. This way, a leak of account-specific (or below) private keys =
never risks compromising the master or other accounts.</div><div><br /></di=
v><div>I may be wrong but I'm not sure that proposing different HMAC params=
 helps standardization or Bitcoin in general. I suggest BIP-85 for your pur=
poses, expressly to solve the issue of a single secret that is used, in an =
irreversible way, to populate multiple wallets for multiple purposes. You c=
ould have a different application code for each token, each of which is der=
ived from a single master secret.</div><div><br /></div><div class=3D"gmail=
_quote"><div dir=3D"auto" class=3D"gmail_attr">On Saturday, July 6, 2024 at=
 1:44:37=E2=80=AFPM UTC-7 Forrest96er wrote:<br/></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204,=
 204, 204); padding-left: 1ex;"><p>Hello,</p><p>The number of new tokens fo=
r Ethereum and Ethereum-like coins has increased dramatically. However, the=
 wallet structure for managing multiple coins based on a single seed has no=
t been updated to accommodate this new scenario. Currently, all tokens are =
managed using the same derivation path, resulting in the creation of identi=
cal addresses across different tokens, significantly reducing privacy. To a=
ddress this issue, the wallet structure for HD wallets needs to be updated.=
</p><p>Simply adding an additional node to the derivation path is not pract=
ical for various reasons.</p><p>A better solution is to use the address or =
identifier of the token for creating private and public keys. This can be a=
chieved by adding an additional input to the HMAC function, which is used t=
o generate child private and public keys. It is advisable to apply a collis=
ion-free hash function before using HMAC.</p><p>m / purpose&#39; / coin_typ=
e&#39; / account&#39; / change / index</p><p>I recommend applying the modif=
ication at the &quot;Change&quot; node. Without modification, the creation =
of an address for the base coin (no token) is targeted.</p><p>With the modi=
fication, the token- adress is targeted.</p><p>This approach also has the a=
dvantage that if hardware wallets are used, only the extended public keys o=
f a coin need to be exported once to the front-end application. After that,=
 the front-end application can generate all public keys needed to scan for =
transactions on all tokens. Even if a token did not exist at the time of th=
e public key export, it could later be found without any additional export.=
<br><br>=C2=A0 Did I miss something? <br>If an attacker obtains some public=
 keys used in a transaction for a token, he should not be able to calculate=
 the public keys of other tokens or the base coin.=C2=A0=C2=A0<br></p></blo=
ckquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/68895604-0821-483d-b3c5-a0aa711f4158n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/68895604-0821-483d-b3c5-a0aa711f4158n%40googlegroups.com</a>.=
<br />

------=_Part_91827_2049286311.1720318245049--

------=_Part_91826_2069007939.1720318245049--