[bitcoindev] Idea for BIP : Deterministic Wallets with Token support

[bitcoindev] Idea for BIP : Deterministic Wallets with Token support

[Forrest96er]

[-- Attachment #1.1: Type: text/plain, Size: 2158 bytes --]



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.

[-- Attachment #1.2: Type: text/html, Size: 2465 bytes --]

[bitcoindev] Re: Idea for BIP : Deterministic Wallets with Token support

[Aneesh Karve]

[-- Attachment #1.1: Type: text/plain, Size: 3771 bytes --]

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

> Simply adding an additional node to the derivation path is not practical 
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 
to suit your security needs. From BIP-32:

> One weakness that may not be immediately obvious, is that knowledge of a 
parent extended public key plus any non-hardened private key descending 
from it is equivalent to knowing the parent extended private key (and thus 
every private and public 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.

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 purposes, 
expressly to solve the issue of a single secret that is used, in an 
irreversible way, to populate multiple wallets for multiple purposes. You 
could have a different application code for each token, each of which is 
derived from a single master secret.

On Saturday, July 6, 2024 at 1:44:37 PM UTC-7 Forrest96er wrote:

> 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/68895604-0821-483d-b3c5-a0aa711f4158n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4310 bytes --]

[bitcoindev] Re: Idea for BIP : Deterministic Wallets with Token support

[Forrest96er]

[-- Attachment #1.1: Type: text/plain, Size: 6716 bytes --]



Regarding the impracticality of adding an additional note, I have the 
following reasons:

   1. Maintaining a list of all available tokens (which can later be 
   assigned to the index of a new node) is nearly impossible due to the sheer 
   number of available tokens. Additionally, new tokens can be created within 
   seconds on different blockchains, making the list perpetually outdated.
   2. Using the addresses of tokens (or a hash of them) as additional input 
   in HMAC makes an additional node obsulete.
   3. This approach is backward compatible to BIP 44.

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.

Aneesh Karve schrieb am Sonntag, 7. Juli 2024 um 04:43:25 UTC+2:

> Not sure this is relevant to a Bitcoin list but I'll answer in a Bitcoin 
> context.
>
> > Simply adding an additional node to the derivation path is not practical 
> 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 
> to suit your security needs. From BIP-32:
>
> > One weakness that may not be immediately obvious, is that knowledge of a 
> parent extended public key plus any non-hardened private key descending 
> from it is equivalent to knowing the parent extended private key (and thus 
> every private and public 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.
>
> 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 purposes, 
> expressly to solve the issue of a single secret that is used, in an 
> irreversible way, to populate multiple wallets for multiple purposes. You 
> could have a different application code for each token, each of which is 
> derived from a single master secret.
>
> On Saturday, July 6, 2024 at 1:44:37 PM UTC-7 Forrest96er wrote:
>
>> 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/43de6819-f2b2-4ce9-bfa7-8893399e7bf3n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 7532 bytes --]