summaryrefslogtreecommitdiff
path: root/45/855a6cb4702b1912010fe2e40885d649550646
blob: a798c22de992ea41a240ccb467187f05dd30c55d (plain)
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
Delivery-date: Sat, 06 Jul 2024 13:44:44 -0700
Received: from mail-yb1-f192.google.com ([209.85.219.192])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDAN7KU5X4HBBNGZU22AMGQE3LIV6YY@googlegroups.com>)
	id 1sQCGy-0003DF-BM
	for bitcoindev@gnusha.org; Sat, 06 Jul 2024 13:44:44 -0700
Received: by mail-yb1-f192.google.com with SMTP id 3f1490d57ef6-e03a92302d1sf4845057276.1
        for <bitcoindev@gnusha.org>; Sat, 06 Jul 2024 13:44:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1720298678; x=1720903478; 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:message-id:to:from:date:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=i3k+9/v6HRkaAutZzoxNXK7mQX7JPVXn8ROiya2o53E=;
        b=v9dF9bzAhohtrY1TY7ASaVffkbDxpFvjp338uUNfdB3pqu8X4JySu6NJsTdCjHXlhi
         TcHeN6MXYprtf6NPbj2TqAGoGMZj7pj3GNFYCTYTU8hs9BbiAxpxyuKlOowmiFiLapWo
         K5T+WdIEYsc2nOVjMaDwmZu3ozCBbcQlnUBazGJkMvlAf8ecY89yddgwB1UA6rewt+By
         tdFelb7wQNv+gscUH1vveBh4G1TVvDflQBJBKuUU9mzo9xlYtZZMKjwLt0w0AFkB3YTR
         neiu3nuS/We/NltR/gEbdF0j7Qyx+5oBJ9xzTLOt1SdiXtje2zQ4a9enaEG5PxjpGjnZ
         njHQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1720298678; x=1720903478; 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:message-id:to:from:date:from:to:cc:subject:date:message-id
         :reply-to;
        bh=i3k+9/v6HRkaAutZzoxNXK7mQX7JPVXn8ROiya2o53E=;
        b=aB2XHuASRqgGV/I7G+hiRSFQ9Nb07RKi9q75NsQrpx+hQfOSWdcgnDOrAa9P0DR28u
         pyhYmP+j8JUuFClDW3dbeytu6Dvu4FX6VFDa/01oAQ0zDWdzB/ZmQLI1QR7RxGYEJ8Rb
         wr6xK1oUtqrtzacPBThYYuI9UA8/ZGVoLgMiAcliK73sg/Flrmci9neGrEzsrHARDep6
         krXkkpRgiSWCZUYdGjJP1dDimahlNGkIPLVthNptSooGGmA0MV+L6nfLG8Lz7AUJibm0
         vKhHakcYds113tUDVdkNvdIZUraDDspF9OOIP9ViTASJ3YN3vFoA4vnP8ZubshHC/jmX
         EdEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1720298678; x=1720903478;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=i3k+9/v6HRkaAutZzoxNXK7mQX7JPVXn8ROiya2o53E=;
        b=QzIC565L8SBDW1e1EHP0ucKUgI2/wNEWVcHunNgFsF89r6cdA8rol8ejuWcb1Ugilm
         hetcLWPZQI6bnIhVHhoJZFWqnPNmVcsRuphnv1BgXhXD99k3R6xRr8lqtzzkFpY/do54
         8UTHQNRiAd3FpaX0ami+als23ZUFWK50zLYx2DFkDP/x1R/6H65Aac4/jH+6yiVuAAJl
         OgNUmtoNvwYGFsHtOZhyiHFg/PIueDoqoaSWvq2g0tAy1ZTORD3gv88lM9I8IXkOgF48
         YWs+VZaszT0yJ3wplv/RaJJYeIXASmdHOz+9Cn5I2Lpdova4+TWg5mPhugp0UZIyS/mU
         wQGQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVTmcOnPm/AZtU1CuyqXQp2FYHn24QgbAMmOYw8d+Wl8RdvbWVF58pJkGP4mzWz7KUaavaVCIJwTeZue5gfzGxBxVvNtXw=
X-Gm-Message-State: AOJu0YzBC/z55HFe/bi50YZe6xUSl8XtKoYUrD4Tx/dO8icFAVmBhLAv
	bAkfv8kzye4RpB3RNfVtplmGd1dLhute3gFoOkfBcpV6ewxPlXIF
X-Google-Smtp-Source: AGHT+IEwMW1K0ikLkLpbgw3zD8nfwzr/1zhQaZUU3XuPpTfXTXtnnyJh22pUiBUfSQ4PPLExLyRHHA==
X-Received: by 2002:a25:d0c3:0:b0:e03:60b4:1311 with SMTP id 3f1490d57ef6-e03c18f16cdmr8444353276.9.1720298677621;
        Sat, 06 Jul 2024 13:44:37 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:1205:b0:dff:aa9:b9ad with SMTP id
 3f1490d57ef6-e03bd07819cls4334196276.2.-pod-prod-08-us; Sat, 06 Jul 2024
 13:44:36 -0700 (PDT)
X-Received: by 2002:a05:6902:154d:b0:de5:2694:45ba with SMTP id 3f1490d57ef6-e03c1649f30mr486467276.0.1720298676169;
        Sat, 06 Jul 2024 13:44:36 -0700 (PDT)
Received: by 2002:a05:690c:2b8c:b0:64a:6fb4:b878 with SMTP id 00721157ae682-651456616b7ms7b3;
        Sat, 6 Jul 2024 13:41:43 -0700 (PDT)
X-Received: by 2002:a81:9296:0:b0:62d:fbf:920a with SMTP id 00721157ae682-652d8531083mr805027b3.10.1720298502371;
        Sat, 06 Jul 2024 13:41:42 -0700 (PDT)
Date: Sat, 6 Jul 2024 13:41:42 -0700 (PDT)
From: Forrest96er <abel.fricke@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n@googlegroups.com>
Subject: [bitcoindev] Idea for BIP : Deterministic Wallets with Token support
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_571092_1154064334.1720298502096"
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_571092_1154064334.1720298502096
Content-Type: multipart/alternative; 
	boundary="----=_Part_571093_1418156991.1720298502096"

------=_Part_571093_1418156991.1720298502096
Content-Type: text/plain; charset="UTF-8"



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/72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n%40googlegroups.com.

------=_Part_571093_1418156991.1720298502096
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<p>Hello,</p><p>The number of new tokens for Ethereum and Ethereum-like coi=
ns has increased dramatically. However, the wallet structure for managing m=
ultiple coins based on a single seed has not been updated to accommodate th=
is new scenario. Currently, all tokens are managed using the same derivatio=
n path, resulting in the creation of identical addresses across different t=
okens, significantly reducing privacy. To address this issue, the wallet st=
ructure for HD wallets needs to be updated.</p><p>Simply adding an addition=
al node to the derivation path is not practical for various reasons.</p><p>=
A better solution is to use the address or identifier of the token for crea=
ting 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 pub=
lic keys. It is advisable to apply a collision-free hash function before us=
ing HMAC.</p><p>m / purpose' / coin_type' / account' / change / index</p><p=
>I recommend applying the modification at the "Change" node. Without modifi=
cation, the creation of an address for the base coin (no token) is targeted=
.</p><p>With the modification, the token- adress is targeted.</p><p>This ap=
proach also has the advantage that if hardware wallets are used, only the e=
xtended public keys of a coin need to be exported once to the front-end app=
lication. After that, the front-end application can generate all public key=
s needed to scan for transactions on all tokens. Even if a token did not ex=
ist at the time of the public key export, it could later be found without a=
ny additional export.<br /><br />=C2=A0 Did I miss something? <br />If an a=
ttacker obtains some public keys used in a transaction for a token, he shou=
ld not be able to calculate the public keys of other tokens or the base coi=
n.=C2=A0=C2=A0<br /></p>

<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/72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/72e1b8bf-11d0-4ee7-a18a-949d0e8acb16n%40googlegroups.com</a>.=
<br />

------=_Part_571093_1418156991.1720298502096--

------=_Part_571092_1154064334.1720298502096--