From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 08 Jul 2024 18:16:31 -0700 Received: from mail-yw1-f189.google.com ([209.85.128.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sQzT4-0005Jg-Mo for bitcoindev@gnusha.org; Mon, 08 Jul 2024 18:16:31 -0700 Received: by mail-yw1-f189.google.com with SMTP id 00721157ae682-651e54bb41bsf78392477b3.1 for ; Mon, 08 Jul 2024 18:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1720487784; x=1721092584; 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=sJa9ax9qj0fpZ3o9/AZHLV+Ub1+JBSmDHcrz3aKPKeA=; b=RpZKEno3hDXrDsv/80j2y1tx3xPF80mNaGg0eOqkrOdc03Y2OUB+XlI9sm6QYDNQ2K bjFVyu8Fn5Mlv6bRoGAbfVmE0Io+Ho9LpCHW8Qes/mxiE0Q2DyjraVynGil+6DBcczRA xPRQfDo2pm4eUm6ZOuysiei4b0mOqleGT3n7vMz4eg8M8cSLIo6Kjps9i+0Ya9QZM1Ua NaiKGrUYyXY/eKesN76i/UXKyjjngRtAcxOl9CSV4F+0DudKvJkAEaEFm69fC+r0POfx 6lnxSU3W9nSxA/JOD17hgOGsMiTKNEL4GMOlcrRdwHFvigtoHchvY3ZFEepvUaaQTbkR jOcg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720487784; x=1721092584; 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=sJa9ax9qj0fpZ3o9/AZHLV+Ub1+JBSmDHcrz3aKPKeA=; b=AK8vFSHMyKXMdvS+5/Jgy3dvBc5BARvmzj1TfJXLR2cR98LsADseT58j5Tnn+PAeJj LJuBrcGldqix6K57n7Ygq1AgR0xFwCDOXB4vpqV5ocYwpbLXvZhR7G3GDkX7f0M5UI+c l3Y6jLgHuEErLNBCE2oSNPptO6XiFrWj4rYcINPCOPEpocY1AhsRZ863oSYVt+d915BR rujPcGYY/8jgZkpv2d8pec8hhC5xTusqTC2UQKnb9AfuN1j7Ch/b84m1cdnMJhax5YaT Lf6zTiXJlmX9EOa3dCR5eTgPcYfF7kx41X96Isy1rLdJgWtm4ZzJuHal0KGisOfhwgZK eqpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720487784; x=1721092584; 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=sJa9ax9qj0fpZ3o9/AZHLV+Ub1+JBSmDHcrz3aKPKeA=; b=KtOt722Dwus4MXuJb8UBUUP4hGAZ9Um/En1CCZYtIeYrCjeuPdsOxwUaYxPTx/Ua09 DtC/8/1c4XUejjZGwWJSdCbpi5x5EjqzQ8ocmvZXpiYM0Afwoj86qaZvQ96Hv+Qur0DN 7gXc3UKB18kN1G/lWk5FTU+e7/K5TPEohs5l/585iiQZlb1bGP4dJqlNZrtnO+H400ib 7jR0N5fDY9Ghtzg2jIrbO/qQQcJ6MAMHtLehVgnJsVPt925S78nTciJhBHQdhxXg21Ry aK0GsLpawEBsX4NJnfcQtWapdEfmDE08kUqbPsg5N09H9bOa+b7OrZYXOT8L5ilbFTLD 7A7g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCV10BqmfFIqubQBVhjJG58xhuGNwGgJdbpSrZ4BrSNptkIvStzcISnvUIhRRxhhy1DBGbTZGqaYk5jtJfDjVjiC80Xu9Vs= X-Gm-Message-State: AOJu0YwqznMP40E9kFE1fzOFQaO0T5g1AdE0jf53fhEVsqefngLgX537 ks3ed19iRYTX6iiLjbuO3K5pPefwbjbHh77PVKO6iq+ovbBzCKse X-Google-Smtp-Source: AGHT+IF5H9bGs3aFc+nWv0NIi7k/FbM924WVqZBuFaYhhMpQeOrJ5g1YAtPBbpBsDe7vL7a0/E+X6Q== X-Received: by 2002:a25:8005:0:b0:e03:4f88:81f1 with SMTP id 3f1490d57ef6-e041b03c556mr1791858276.5.1720487784377; Mon, 08 Jul 2024 18:16:24 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:1006:b0:e03:22b3:3c02 with SMTP id 3f1490d57ef6-e03bced5d27ls3076743276.0.-pod-prod-00-us; Mon, 08 Jul 2024 18:16:23 -0700 (PDT) X-Received: by 2002:a05:6902:1002:b0:e02:f35c:d398 with SMTP id 3f1490d57ef6-e041d05c5ffmr22818276.0.1720487782894; Mon, 08 Jul 2024 18:16:22 -0700 (PDT) Received: by 2002:a05:690c:3012:b0:64b:8595:7a39 with SMTP id 00721157ae682-65145091b38ms7b3; Mon, 8 Jul 2024 17:55:27 -0700 (PDT) X-Received: by 2002:a05:690c:f14:b0:648:2a9d:1a63 with SMTP id 00721157ae682-658f11a5b00mr365787b3.7.1720486526755; Mon, 08 Jul 2024 17:55:26 -0700 (PDT) Date: Mon, 8 Jul 2024 17:55:26 -0700 (PDT) From: Forrest96er To: Bitcoin Development Mailing List Message-Id: <43de6819-f2b2-4ce9-bfa7-8893399e7bf3n@googlegroups.com> In-Reply-To: <68895604-0821-483d-b3c5-a0aa711f4158n@googlegroups.com> References: <72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n@googlegroups.com> <68895604-0821-483d-b3c5-a0aa711f4158n@googlegroups.com> Subject: [bitcoindev] Re: Idea for BIP : Deterministic Wallets with Token support MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_52910_337614476.1720486526436" X-Original-Sender: abel.fricke@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_52910_337614476.1720486526436 Content-Type: multipart/alternative; boundary="----=_Part_52911_19162783.1720486526436" ------=_Part_52911_19162783.1720486526436 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Regarding the impracticality of adding an additional note, I have the=20 following reasons: 1. Maintaining a list of all available tokens (which can later be=20 assigned to the index of a new node) is nearly impossible due to the she= er=20 number of available tokens. Additionally, new tokens can be created with= in=20 seconds on different blockchains, making the list perpetually outdated. 2. Using the addresses of tokens (or a hash of them) as additional input= =20 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= =20 must be handled more carefully than a regular public key. However, in=20 practice, hardware wallets export the extended public key at the change=20 level to the frontend software. This allows the software to create new=20 addresses for deposits or scan change addresses. Hardware wallets are=20 designed never to retrieve any private keys, so it is still impossible to= =20 recreate the private key of account or change node. Therefore, the risk is= =20 the same as on BIP 44. An attacker who steals the extended public key can= =20 spy on all transactions for a specified coin type in a specified account,= =20 but that is the extent of the risk. The idea of using a different application code for each token would be an= =20 option, but you must consider that you can only create addresses valid for= =20 the coin type, not the token. It is always possible for someone to send a= =20 token to an incorrect address, causing the token to be locked because the= =20 application is not designed for that token. In the end, all token=20 applications (which will likely converge into one) will need access to all= =20 addresses of a coin type within the same account. The primary goal of this modification is to conceal a user's identity from= =20 anyone analyzing transactions on the blockchain. For instance, if someone= =20 receives both ETH and USDT in their wallet, the same deposit, change, and= =20 possibly withdrawal addresses will be used. Consequently, these addresses= =20 become linked, undermining the privacy feature provided by using different= =20 addresses, including change addresses. By default, independent addresses should be generated for each token or the= =20 main chain. Users will be encouraged to use only the addresses recommended= =20 by the application for that token. Additionally, the application will use= =20 token-specific addresses for its internal transactions (change). By=20 default, the application will scan for transactions of a token on the=20 addresses of the main coin and the token-specific addresses. Adding an=20 option to manually scan other token addresses for coins sent to incorrect= =20 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= =20 > context. > > > Simply adding an additional node to the derivation path is not practica= l=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 unlikel= y=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 thu= s=20 > every private and public key descending from it). This means that extende= d=20 > public keys must be treated more carefully than regular public keys. It i= s=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 help= s=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 multi= ple=20 >> coins based on a single seed has not been updated to accommodate this ne= w=20 >> scenario. Currently, all tokens are managed using the same derivation pa= th,=20 >> resulting in the creation of identical addresses across different tokens= ,=20 >> significantly reducing privacy. To address this issue, the wallet struct= ure=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 generat= e=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=20 >> token, he should not be able to calculate the public keys of other token= s=20 >> or the 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/43de6819-f2b2-4ce9-bfa7-8893399e7bf3n%40googlegroups.com. ------=_Part_52911_19162783.1720486526436 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Regarding the impracticality of adding an additional note, I have the fo= llowing reasons:

  1. Maintaining a list of all available tokens (whi= ch can later be assigned to the index of a new node) is nearly impossible d= ue to the sheer number of available tokens. Additionally, new tokens can be= created within seconds on different blockchains, making the list perpetual= ly outdated.
  2. Using the addresses of tokens (or a hash of them) as a= dditional input in HMAC makes an additional node obsulete.
  3. This app= roach is backward compatible to BIP 44.

Regarding the second qu= estion, you are correct that an extended public key must be handled more ca= refully than a regular public key. However, in practice, hardware wallets e= xport the extended public key at the change level to the frontend software.= This allows the software to create new addresses for deposits or scan chan= ge addresses. Hardware wallets are designed never to retrieve any private k= eys, so it is still impossible to recreate the private key of account or ch= ange node. Therefore, the risk is the same as on BIP 44. An attacker who st= eals the extended public key can spy on all transactions for a specified co= in type in a specified account, but that is the extent of the risk.

T= he idea of using a different application code for each token would be an op= tion, but you must consider that you can only create addresses valid for th= e coin type, not the token. It is always possible for someone to send a tok= en to an incorrect address, causing the token to be locked because the appl= ication 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.

<= /div>

The pr= imary goal of this modification is to conceal a user's identity from anyone= analyzing transactions on the blockchain. For instance, if someone receive= s both ETH and USDT in their wallet, the same deposit, change, and possibly= withdrawal addresses will be used. Consequently, these addresses become li= nked, undermining the privacy feature provided by using different addresses= , including change addresses.

=

By default, independent addresses should be generated for each tok= en or the main chain. Users will be encouraged to use only the addresses re= commended by the application for that token. Additionally, the application = will use token-specific addresses for its internal transactions (change). B= y default, the application will scan for transactions of a token on the add= resses of the main coin and the token-specific addresses. Adding an option = to manually scan other token addresses for coins sent to incorrect addresse= s might be advisable.


Aneesh Karve schrieb am Sonntag, 7. Juli 2024 um 04:4= 3:25 UTC+2:
<= div>Not sure this is relevant to a Bitcoin list but I'll answer in a Bi= tcoin context.

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

What are = those reasons?

> I recommend applying the modificatio= n at the "Change" node.

The change node = does not use hardened derivation and is therefore unlikely to suit your sec= urity needs. From BIP-32:

>=C2=A0One weakness t= hat may not be immediately obvious, is that knowledge of a parent extended = public key plus any non-hardened private key descending from it is equivale= nt to knowing the parent extended private key (and thus every private and p= ublic 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 leve= l 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 par= ams 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. Yo= u could have a different application code for each token, each of which is = derived from a single master secret.

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

Hello,

The number of new tokens for Ethere= um and Ethereum-like coins has increased dramatically. However, the wallet = structure for managing multiple coins based on a single seed has not been u= pdated to accommodate this new scenario. Currently, all tokens are managed = using the same derivation path, resulting in the creation of identical addr= esses across different tokens, significantly reducing privacy. To address t= his issue, the wallet structure for HD wallets needs to be updated.

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

A better solution is to use the address or identifi= er 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 genera= te 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 ad= dress 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 fro= nt-end application can generate all public keys needed to scan for transact= ions 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.

= =C2=A0 Did I miss something?
If an attacker obtains some public keys us= ed in a transaction for a token, he should not be able to calculate the pub= lic 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/43de6819-f2b2-4ce9-bfa7-8893399e7bf3n%40googlegroups.com.=
------=_Part_52911_19162783.1720486526436-- ------=_Part_52910_337614476.1720486526436--