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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <matt@envrin.com>) id 1Z646I-0004Pq-DN
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 21:45:26 +0000
X-ACL-Warn:
Received: from 2.7a.be.static.xlhost.com ([209.190.122.2] helo=mail.envrin.com)
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Z646G-0003S5-G3 for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 21:45:26 +0000
Received: from [192.168.1.2] (unknown [223.205.8.105])
by mail.envrin.com (Postfix) with ESMTPA id 9E2DA619EB;
Fri, 19 Jun 2015 17:59:15 -0400 (EDT)
Message-ID: <558488D0.50904@envrin.com>
Date: Sat, 20 Jun 2015 04:25:36 +0700
From: "Matt @ Envrin Group" <matt@envrin.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Matt Smith <matt@gem.co>, bitcoin-development@lists.sourceforge.net
References: <55847E98.3050307@gem.co>
In-Reply-To: <55847E98.3050307@gem.co>
Content-Type: multipart/alternative;
boundary="------------050807080204030006080704"
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Z646G-0003S5-G3
Subject: Re: [Bitcoin-development] Alternate HD path structure: BIP, blog,
or wat?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2015 21:45:26 -0000
This is a multi-part message in MIME format.
--------------050807080204030006080704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Matt,
I think your best bet is probably just push it out privately via blog
post / Github, and see if it gains any traction with other developers.
I'm a little uncertain as to the relevance though. All those variables
(purpose, network, asset_type, account, change, index) need to be stored
internally within the wallet database, as there's no way to retrieve the
path used from just the address, correct? In that case, what's the
meaning of that exact path structure when a) it can't be retrieved from
just the address, and b) the values will be stored internally within the
wallet when you lookup the address.
Matt
On 06/20/2015 03:42 AM, Matt Smith wrote:
> Hey guys,
>
> The crew at Gem is considering a new HD wallet path structure for our
> wallets, which are coin-agnostic, that separates the coin_type field
> into two fields as such:
>
> m / purpose' / network' / asset_type' / account' / change / index
>
> where network refers to the blockchain (0 - bitcoin, 1 - testnet3, 2 -
> litecoin, etc) and the new asset_type refers to the kind of asset to be
> held in accounts below that path (Open Assets, Omni, Counterparty).
>
> The intent is to allow us to validate the address format, select the
> appropriate daemon to scan for tokenized assets, and choose multiple
> blockchain data sources (that may not know anything about token systems
> running on the blockchain they expose) relevant to an HDNode in the
> wallet using only information in the HDNode's path -- without having to
> maintain an explicit mapping of coin_type -> network.
>
> For example, we already have the issue of mapping network identifiers
> because of the lack of standardization across cryptocurrency libraries
> which ends up being ugly and obnoxious to maintain, i.e.
>
> netcode_map = {
> testnet: testnet3,
> bitcoin_testnet: testnet3,
> testnet3: testnet3,
> XTN: testnet3, ...
> }
> netcode_i_want = netcode_map[netcode_returned_by_libwhatever]
>
> We want to avoid maintaining a similar asset_type_to_blockchain mapping.
> Additionally, it would be helpful for utxo selection to exclude utxos
> tied to assets based on path.
>
> BIP43 seems to suggest that we request a BIP number and publish an
> informational BIP specifying the new purpose. If that's not appropriate,
> then maybe we just need to publish the information in a blog post to
> allow any wallet developers who want to to implement
> import_from_gem_structure.
>
> I was also wondering if anyone had previously suggested something
> similar that I missed when cruising the mailing list archives on the
> subject.
>
> Thanks,
> --
> Matt Smith | Gem
> https://gem.co | GH: @thedoctor
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------050807080204030006080704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
Hi Matt,<br>
<br>
I think your best bet is probably just push it out privately via
blog post / Github, and see if it gains any traction with other
developers.<br>
<br>
I'm a little uncertain as to the relevance though. All those
variables (purpose, network, asset_type, account, change, index)
need to be stored internally within the wallet database, as there's
no way to retrieve the path used from just the address, correct? In
that case, what's the meaning of that exact path structure when a)
it can't be retrieved from just the address, and b) the values will
be stored internally within the wallet when you lookup the address.<br>
<br>
Matt<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 06/20/2015 03:42 AM, Matt Smith
wrote:<br>
</div>
<blockquote cite="mid:55847E98.3050307@gem.co" type="cite">
<pre wrap="">Hey guys,
The crew at Gem is considering a new HD wallet path structure for our
wallets, which are coin-agnostic, that separates the coin_type field
into two fields as such:
m / purpose' / network' / asset_type' / account' / change / index
where network refers to the blockchain (0 - bitcoin, 1 - testnet3, 2 -
litecoin, etc) and the new asset_type refers to the kind of asset to be
held in accounts below that path (Open Assets, Omni, Counterparty).
The intent is to allow us to validate the address format, select the
appropriate daemon to scan for tokenized assets, and choose multiple
blockchain data sources (that may not know anything about token systems
running on the blockchain they expose) relevant to an HDNode in the
wallet using only information in the HDNode's path -- without having to
maintain an explicit mapping of coin_type -> network.
For example, we already have the issue of mapping network identifiers
because of the lack of standardization across cryptocurrency libraries
which ends up being ugly and obnoxious to maintain, i.e.
netcode_map = {
testnet: testnet3,
bitcoin_testnet: testnet3,
testnet3: testnet3,
XTN: testnet3, ...
}
netcode_i_want = netcode_map[netcode_returned_by_libwhatever]
We want to avoid maintaining a similar asset_type_to_blockchain mapping.
Additionally, it would be helpful for utxo selection to exclude utxos
tied to assets based on path.
BIP43 seems to suggest that we request a BIP number and publish an
informational BIP specifying the new purpose. If that's not appropriate,
then maybe we just need to publish the information in a blog post to
allow any wallet developers who want to to implement
import_from_gem_structure.
I was also wondering if anyone had previously suggested something
similar that I missed when cruising the mailing list archives on the
subject.
Thanks,
–
Matt Smith | Gem
<a class="moz-txt-link-freetext" href="https://gem.co">https://gem.co</a> | GH: @thedoctor
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------050807080204030006080704--
|
