public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Forrest96er <abel.fricke@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Idea for BIP : Deterministic Wallets with Token support
Date: Sat, 6 Jul 2024 13:41:42 -0700 (PDT)	[thread overview]
Message-ID: <72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n@googlegroups.com> (raw)


[-- 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 --]

             reply	other threads:[~2024-07-06 20:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-06 20:41 Forrest96er [this message]
2024-07-07  2:10 ` [bitcoindev] Re: Idea for BIP : Deterministic Wallets with Token support Aneesh Karve
2024-07-09  0:55   ` Forrest96er

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n@googlegroups.com \
    --to=abel.fricke@gmail.com \
    --cc=bitcoindev@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox