1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
|
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 <bitcoindev+bncBDSMPXWBREDRBS4BVC2AMGQEODYEOPI@googlegroups.com>)
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 <bitcoindev@gnusha.org>; 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 <aneesh.karve@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
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: <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_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
<div>Not sure this is relevant to a Bitcoin list but I'll answer in a Bitco=
in context.</div><div><br /></div>> Simply adding an additional node to =
the derivation path is not practical for various reasons.<br /><br />What a=
re those reasons?<div><br /></div><div>> I recommend applying the modifi=
cation at the "Change" node.</div><div><br /></div><div>The change node doe=
s not use hardened derivation and is therefore unlikely to suit your securi=
ty needs. From BIP-32:</div><div><br /></div><div>>=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.</div><div><br /></di=
v><div>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.</div><div><br /></div><div class=3D"gmail=
_quote"><div dir=3D"auto" class=3D"gmail_attr">On Saturday, July 6, 2024 at=
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 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.=
</p><p>Simply adding an additional node to the derivation path is not pract=
ical for various reasons.</p><p>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.</p><p>m / purpose' / coin_typ=
e' / account' / change / index</p><p>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.</p><p>With the modi=
fication, the token- adress is targeted.</p><p>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.=
<br><br>=C2=A0 Did I miss something? <br>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<br></p></blo=
ckquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" 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/68895604-0821-483d-b3c5-a0aa711f4158n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/68895604-0821-483d-b3c5-a0aa711f4158n%40googlegroups.com</a>.=
<br />
------=_Part_91827_2049286311.1720318245049--
------=_Part_91826_2069007939.1720318245049--
|
