Delivery-date: Sat, 06 Jul 2024 13:44:44 -0700
Sender: bitcoindev@googlegroups.com
Date: Sat, 6 Jul 2024 13:41:42 -0700 (PDT)
From: Forrest96er <abel.fricke@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n@googlegroups.com>
Subject: [bitcoindev] Idea for BIP : Deterministic Wallets with Token support
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_571092_1154064334.1720298502096"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_571092_1154064334.1720298502096
Content-Type: multipart/alternative; 
	boundary="----=_Part_571093_1418156991.1720298502096"

------=_Part_571093_1418156991.1720298502096
Content-Type: text/plain; charset="UTF-8"


Hello,

The number of new tokens for Ethereum and Ethereum-like coins has increased 
dramatically. However, the wallet structure for managing multiple coins 
based on a single seed has not been updated to accommodate this new 
scenario. Currently, all tokens are managed using the same derivation path, 
resulting in the creation of identical addresses across different tokens, 
significantly reducing privacy. To address this issue, the wallet structure 
for HD wallets needs to be updated.

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

A better solution is to use the address or identifier of the token for 
creating private and public keys. This can be achieved by adding an 
additional input to the HMAC function, which is used to generate child 
private and public keys. It is advisable to apply a collision-free hash 
function before using HMAC.

m / purpose' / coin_type' / account' / change / index

I recommend applying the modification at the "Change" node. Without 
modification, the creation of an address for the base coin (no token) is 
targeted.

With the modification, the token- adress is targeted.

This approach also has the advantage that if hardware wallets are used, 
only the extended public keys of 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 the public key export, it could later be 
found without any additional export.

  Did I miss something? 
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.  

-- 
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 on the web visit https://groups.google.com/d/msgid/bitcoindev/72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n%40googlegroups.com.

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

<p>Hello,</p><p>The number of new tokens for Ethereum and Ethereum-like coi=
ns has increased dramatically. However, the wallet structure for managing m=
ultiple coins based on a single seed has not been updated to accommodate th=
is new scenario. Currently, all tokens are managed using the same derivatio=
n path, resulting in the creation of identical addresses across different t=
okens, significantly reducing privacy. To address this issue, the wallet st=
ructure for HD wallets needs to be updated.</p><p>Simply adding an addition=
al node to the derivation path is not practical for various reasons.</p><p>=
A better solution is to use the address or identifier of the token for crea=
ting private and public keys. This can be achieved by adding an additional =
input to the HMAC function, which is used to generate child private and pub=
lic keys. It is advisable to apply a collision-free hash function before us=
ing HMAC.</p><p>m / purpose' / coin_type' / account' / change / index</p><p=
>I recommend applying the modification at the "Change" node. Without modifi=
cation, the creation of an address for the base coin (no token) is targeted=
.</p><p>With the modification, the token- adress is targeted.</p><p>This ap=
proach also has the advantage that if hardware wallets are used, only the e=
xtended public keys of a coin need to be exported once to the front-end app=
lication. After that, the front-end application can generate all public key=
s needed to scan for transactions on all tokens. Even if a token did not ex=
ist at the time of the public key export, it could later be found without a=
ny additional export.<br /><br />=C2=A0 Did I miss something? <br />If an a=
ttacker obtains some public keys used in a transaction for a token, he shou=
ld not be able to calculate the public keys of other tokens or the base coi=
n.=C2=A0=C2=A0<br /></p>

<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/72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n%40googlegroups.com</a>.=
<br />

------=_Part_571093_1418156991.1720298502096--

------=_Part_571092_1154064334.1720298502096--