From: Aneesh Karve <aneesh.karve@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Idea for BIP : Deterministic Wallets with Token support
Date: Sat, 6 Jul 2024 19:10:45 -0700 (PDT) [thread overview]
Message-ID: <68895604-0821-483d-b3c5-a0aa711f4158n@googlegroups.com> (raw)
In-Reply-To: <72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n@googlegroups.com>
[-- 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 --]
next prev parent reply other threads:[~2024-07-07 2:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-06 20:41 [bitcoindev] " Forrest96er
2024-07-07 2:10 ` Aneesh Karve [this message]
2024-07-09 0:55 ` [bitcoindev] " 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=68895604-0821-483d-b3c5-a0aa711f4158n@googlegroups.com \
--to=aneesh.karve@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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