From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 06 Jul 2024 19:43:32 -0700 Received: from mail-yb1-f188.google.com ([209.85.219.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sQHsB-0002tc-CV for bitcoindev@gnusha.org; Sat, 06 Jul 2024 19:43:31 -0700 Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e03623b24ddsf5166391276.1 for ; Sat, 06 Jul 2024 19:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1720320205; x=1720925005; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=lrdGh135s1KsyyTn0GgqQA2bOXKTm33w2OMbfBi62po=; b=xdktcSyZI2/jt8vD0RvpXppJAz0JsQzbB1pwKJbHGZZ1WV72l4QTQX4Y0R7maUeH6k sDTsc0Bp30qhVEw/1NZY1RIvgHq0Oz9d9Rz/o1u7g/NgD9nwTP7qe+SPm1iGZ/DvZ4DI 42UN/lduHdv91P2yvoybCFPQmIQQMs1YTcL7OyKzTIACbzw3HAHqfab7Z9lF0/G0MkoF rXerYsPSYbRPeH0nzkZ+sxNFosrBxyKESPjdLR0TSV6NmaSqelCk7NFujbLcatBH10Hp ZISfnARAKAQf/tCwLgjlbO0idnmJKBQTjhN/lw/bYqciPjYxih9cnTTP73vwMSS291GA F6Og== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720320205; x=1720925005; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=lrdGh135s1KsyyTn0GgqQA2bOXKTm33w2OMbfBi62po=; b=R2WqTkKQKx2dennkVzCqhl9qAbMa9g5SiYhtCqYiFK93UPNQ9IZ3CjqGF6w8WXXtsC tqV0HZXV8ZYOW0ABOlYOceBS4YLmFeznk/qoziCekZaeJ923HE/tXOB+IAjZEa+77iOx e8VzTzeHmwofp3zBXS2fWx8/Zqd/KteKiHoJan0zu6QAzUj3YkA9VErZHoDwf80Us99t pE4EDD38YeBMsXQ//RYudwAohwRFJtO9hqmV1vm1AzDlq/snSI7kYfcj/3cpNzpleweg 1KfIOIBcQpMocZc4Of9cp1JnyrC3Ik0T1tS8NhEfwLkN1pZE8uduucaKHJ2rsbbNfFmX cS3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720320205; x=1720925005; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=lrdGh135s1KsyyTn0GgqQA2bOXKTm33w2OMbfBi62po=; b=K40cRX0/hqXTDKP7KZOvuLxBeie1ZRayBbcukVvkaa+poNI0dnWiZK2J4ZicCTL+ee Ur0VBEC6CzRceUaezu7FxICxHfPbIqokwrRwlgEXplXbEINhl3lE+0cCYYvdyq5VFzRe 4o5NrU1YAjIY2blN3OM9o7DsUb5io8n7W+6tdhn3+6ekpIb+YrML5Dm6HPMH6MMYLAZq H/lZegODKWskvzi9+ZYiS92kEC4hyuCsOhaubEcP8HmXSNJFTm5cFLhAmbFvSJGvKlFM jhA02pIcSvDjKxf4dzu7tZhB5wg0t5UCZzqIDltb2mWL7I1rBayrTnJKtZ1RJzgYYt19 etRw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCW7ZngC7UI7aaD4O/NOJm1TVEd2v0PkhbZLdgE2bw612HazahJmM6ivB+jhtKXDZ0k0qoQFSHwbOCqyOOtHWy60NX73pBY= X-Gm-Message-State: AOJu0YwVWA1E8oroyLrdrVVTkb+8i8eAxW2CLN2qIIKzP6nmkr6caEvy /W5OYRK1Y0gU6/g2kAtvvH5l9j0NRX5z48OPWsZEmbs5soxNvQHC X-Google-Smtp-Source: AGHT+IHZyWy6HnYqXHE3BlYaHoQ/6hnmDZh10W25DqYOq8QZU9nnwXw3fgJ+ymOFYwjDAD/GwCCU/Q== X-Received: by 2002:a25:a8a:0:b0:e03:2ba0:309 with SMTP id 3f1490d57ef6-e03c19fa718mr9304724276.41.1720320204680; Sat, 06 Jul 2024 19:43:24 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:18c9:b0:df4:e17a:8653 with SMTP id 3f1490d57ef6-e03bd036897ls4600985276.1.-pod-prod-08-us; Sat, 06 Jul 2024 19:43:23 -0700 (PDT) X-Received: by 2002:a05:6902:18d1:b0:e03:a2f7:729 with SMTP id 3f1490d57ef6-e03c1953432mr758983276.3.1720320203159; Sat, 06 Jul 2024 19:43:23 -0700 (PDT) Received: by 2002:a05:690c:2b8c:b0:64a:6fb4:b878 with SMTP id 00721157ae682-651456616b7ms7b3; Sat, 6 Jul 2024 19:10:46 -0700 (PDT) X-Received: by 2002:a05:6902:154d:b0:de5:2694:45ba with SMTP id 3f1490d57ef6-e03c1649f30mr528474276.0.1720318245304; Sat, 06 Jul 2024 19:10:45 -0700 (PDT) Date: Sat, 6 Jul 2024 19:10:45 -0700 (PDT) From: Aneesh Karve To: Bitcoin Development Mailing List Message-Id: <68895604-0821-483d-b3c5-a0aa711f4158n@googlegroups.com> In-Reply-To: <72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n@googlegroups.com> References: <72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n@googlegroups.com> Subject: [bitcoindev] Re: Idea for BIP : Deterministic Wallets with Token support MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_91826_2069007939.1720318245049" X-Original-Sender: aneesh.karve@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_91826_2069007939.1720318245049 Content-Type: multipart/alternative; boundary="----=_Part_91827_2049286311.1720318245049" ------=_Part_91827_2049286311.1720318245049 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Not sure this is relevant to a Bitcoin list but I'll answer in a Bitcoin=20 context. > Simply adding an additional node to the derivation path is not practical= =20 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= =20 to suit your security needs. From BIP-32: > One weakness that may not be immediately obvious, is that knowledge of a= =20 parent extended public key plus any non-hardened private key descending=20 from it is equivalent to knowing the parent extended private key (and thus= =20 every private and public key descending from it). This means that extended= =20 public keys must be treated more carefully than regular public keys. It is= =20 also the reason for the existence of hardened keys, and why they are used= =20 for the account level in the tree. This way, a leak of account-specific (or= =20 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= =20 standardization or Bitcoin in general. I suggest BIP-85 for your purposes,= =20 expressly to solve the issue of a single secret that is used, in an=20 irreversible way, to populate multiple wallets for multiple purposes. You= =20 could have a different application code for each token, each of which is=20 derived from a single master secret. On Saturday, July 6, 2024 at 1:44:37=E2=80=AFPM UTC-7 Forrest96er wrote: > Hello, > > The number of new tokens for Ethereum and Ethereum-like coins has=20 > increased dramatically. However, the wallet structure for managing multip= le=20 > coins based on a single seed has not been updated to accommodate this new= =20 > scenario. Currently, all tokens are managed using the same derivation pat= h,=20 > resulting in the creation of identical addresses across different tokens,= =20 > significantly reducing privacy. To address this issue, the wallet structu= re=20 > for HD wallets needs to be updated. > > Simply adding an additional node to the derivation path is not practical= =20 > for various reasons. > > A better solution is to use the address or identifier of the token for=20 > creating private and public keys. This can be achieved by adding an=20 > additional input to the HMAC function, which is used to generate child=20 > private and public keys. It is advisable to apply a collision-free hash= =20 > function before using HMAC. > > m / purpose' / coin_type' / account' / change / index > > I recommend applying the modification at the "Change" node. Without=20 > modification, the creation of an address for the base coin (no token) is= =20 > targeted. > > With the modification, the token- adress is targeted. > > This approach also has the advantage that if hardware wallets are used,= =20 > only the extended public keys of a coin need to be exported once to the= =20 > front-end application. After that, the front-end application can generate= =20 > all public keys needed to scan for transactions on all tokens. Even if a= =20 > token did not exist at the time of the public key export, it could later = be=20 > found without any additional export. > > Did I miss something?=20 > If an attacker obtains some public keys used in a transaction for a token= ,=20 > he should not be able to calculate the public keys of other tokens or the= =20 > base coin. =20 > --=20 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 e= mail 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. ------=_Part_91827_2049286311.1720318245049 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not sure this is relevant to a Bitcoin list but I'll answer in a Bitco= in context.

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

What a= re those reasons?

> I recommend applying the modifi= cation at the "Change" node.

The change node doe= s not use hardened derivation and is therefore unlikely to suit your securi= ty needs. From BIP-32:

>=C2=A0One weakness th= at may not be immediately obvious, is that knowledge of a parent extended p= ublic key plus any non-hardened private key descending from it is equivalen= t to knowing the parent extended private key (and thus every private and pu= blic 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 pur= poses, expressly to solve the issue of a single secret that is used, in an = irreversible way, to populate multiple wallets for multiple purposes. You c= ould have a different application code for each token, each of which is der= ived from a single master secret.

On Saturday, July 6, 2024 at= 1:44:37=E2=80=AFPM UTC-7 Forrest96er wrote:

Hello,

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

Simply adding an additional node to the derivation path is not pract= ical 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 a= chieved by adding an additional input to the HMAC function, which is used t= o generate child private and public keys. It is advisable to apply a collis= ion-free hash function before using HMAC.

m / purpose' / coin_typ= e' / account' / change / index

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

With the modi= fication, the token- adress is targeted.

This approach also has the a= dvantage that if hardware wallets are used, only the extended public keys o= f 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 th= e public key export, it could later be found without any additional export.=

=C2=A0 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.=C2=A0=C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/68895604-0821-483d-b3c5-a0aa711f4158n%40googlegroups.com.=
------=_Part_91827_2049286311.1720318245049-- ------=_Part_91826_2069007939.1720318245049--