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.
Regarding the impracticality of adding an additional note, I have the following reasons:
Regarding the second question, you are correct that an extended public key must be handled more carefully than a regular public key. However, in practice, hardware wallets export the extended public key at the change level to the frontend software. This allows the software to create new addresses for deposits or scan change addresses. Hardware wallets are designed never to retrieve any private keys, so it is still impossible to recreate the private key of account or change node. Therefore, the risk is the same as on BIP 44. An attacker who steals the extended public key can spy on all transactions for a specified coin type in a specified account, but that is the extent of the risk.
The idea of using a different application code for each token would be an option, but you must consider that you can only create addresses valid for the coin type, not the token. It is always possible for someone to send a token to an incorrect address, causing the token to be locked because the application is not designed for that token. In the end, all token applications (which will likely converge into one) will need access to all addresses of a coin type within the same account.
The primary goal of this modification is to conceal a user's identity from anyone analyzing transactions on the blockchain. For instance, if someone receives both ETH and USDT in their wallet, the same deposit, change, and possibly withdrawal addresses will be used. Consequently, these addresses become linked, undermining the privacy feature provided by using different addresses, including change addresses.
By default, independent addresses should be generated for each token or the main chain. Users will be encouraged to use only the addresses recommended by the application for that token. Additionally, the application will use token-specific addresses for its internal transactions (change). By default, the application will scan for transactions of a token on the addresses of the main coin and the token-specific addresses. Adding an option to manually scan other token addresses for coins sent to incorrect addresses might be advisable.