path: root/3f/afc716859b7614fe34cc47abd26adfcd481133

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 <bitcoindev+bncBDAN7KU5X4HBBZ46WK2AMGQEDDPO6OA@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <abel.fricke@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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

<p>Regarding the impracticality of adding an additional note, I have the fo=
llowing reasons:</p><ol><li>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.</li><li>Using the addresses of tokens (or a hash of them) as a=
dditional input in HMAC makes an additional node obsulete.</li><li>This app=
roach is backward compatible to BIP 44.</li></ol><p>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.</p><p>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.</p><div><div><div><div><div></div></di=
v></div></div></div><div><div dir=3D"auto"><div><div><div><div><div></div><=
/div></div></div></div><div><div><div><div dir=3D"auto"><div><div><p>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.</p></div></div></div></div></div></div></div>=
</div><p>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.</p><br /><div class=3D"gmail_quote"><div dir=3D"auto"=
 class=3D"gmail_attr">Aneesh Karve schrieb am Sonntag, 7. Juli 2024 um 04:4=
3:25 UTC+2:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 =
0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><=
div>Not sure this is relevant to a Bitcoin list but I&#39;ll answer in a Bi=
tcoin context.</div><div><br></div>&gt; Simply adding an additional node to=
 the derivation path is not practical for various reasons.<br><br>What are =
those reasons?<div><br></div><div>&gt; I recommend applying the modificatio=
n at the &quot;Change&quot; node.</div><div><br></div><div>The change node =
does not use hardened derivation and is therefore unlikely to suit your sec=
urity needs. From BIP-32:</div><div><br></div><div>&gt;=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.</div><div><br></div=
><div>I may be wrong but I&#39;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.</div><div><br></div><div class=3D"gmai=
l_quote"><div dir=3D"auto" class=3D"gmail_attr">On Saturday, July 6, 2024 a=
t 1:44:37=E2=80=AFPM UTC-7 Forrest96er wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><p>Hello,</p><p>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.</p><p>S=
imply adding an additional node to the derivation path is not practical for=
 various reasons.</p><p>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.</p><p>m / purpose&#39; / coin_type&#39; /=
 account&#39; / change / index</p><p>I recommend applying the modification =
at the &quot;Change&quot; node. Without modification, the creation of an ad=
dress for the base coin (no token) is targeted.</p><p>With the modification=
, the token- adress is targeted.</p><p>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.<br><br>=
=C2=A0 Did I miss something? <br>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<br></p></blockquote>=
</div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/43de6819-f2b2-4ce9-bfa7-8893399e7bf3n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/43de6819-f2b2-4ce9-bfa7-8893399e7bf3n%40googlegroups.com</a>.=
<br />

------=_Part_52911_19162783.1720486526436--

------=_Part_52910_337614476.1720486526436--