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
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1WSyhX-00061t-UE
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Mar 2014 01:01:47 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.48 as permitted sender)
client-ip=209.85.192.48; envelope-from=etotheipi@gmail.com;
helo=mail-qg0-f48.google.com;
Received: from mail-qg0-f48.google.com ([209.85.192.48])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WSyhW-0005vz-No
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Mar 2014 01:01:47 +0000
Received: by mail-qg0-f48.google.com with SMTP id j107so1917424qga.21
for <bitcoin-development@lists.sourceforge.net>;
Wed, 26 Mar 2014 18:01:41 -0700 (PDT)
X-Received: by 10.224.112.74 with SMTP id v10mr40792416qap.57.1395882101143;
Wed, 26 Mar 2014 18:01:41 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPSA id c5sm540018qge.21.2014.03.26.18.01.40
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 26 Mar 2014 18:01:40 -0700 (PDT)
Message-ID: <53337874.7010300@gmail.com>
Date: Wed, 26 Mar 2014 21:01:40 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
<lgvobr$q44$1@ger.gmane.org>
In-Reply-To: <lgvobr$q44$1@ger.gmane.org>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative;
boundary="------------020707030508040903050505"
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [209.85.192.48 listed in list.dnswl.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WSyhW-0005vz-No
Subject: Re: [Bitcoin-development] New BIP32 structure
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: Thu, 27 Mar 2014 01:01:48 -0000
This is a multi-part message in MIME format.
--------------020707030508040903050505
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
This might be tangential, but the comment about "refund" chains reminded
me. Armory will be implementing multi-sig/linked wallets where a each
device has a parallel HDW branch and produces P2SH addresses. For those
types of wallets, I plan to allocate two chains /per signing
authority/. If you have a shared 2-of-2 wallet split between your phone
and your spouse's phone, your phone would distribute addresses on P2SH
chain 0 and generate change addresses on P2SH chain 1. Your spouse's
phone would use chains 2 and 3.
So if you and your spouse switch to a new app that supports M-of-N
linked wallets, it should search for coin history along the first 2*N
chains.
-Alan
On 03/26/2014 07:37 PM, Andreas Schildbach wrote:
> Thanks for starting the discussion on finding a better structure.
>
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.
> I heard from multiple sources that using this standard some wallets will
> only see a subset of the addresses/keys of some other wallets.
> Implementation differences can always happen (and should addresses as
> bugs), but I think its unacceptable that this source of issues is by design.
>
> I suggest we agree on an even simpler least common denominator and
> wallets that want to implement some feature on top of that can do but
> are encouraged to pick a totally different "cointype". I guess that
> would mean removing reserved and account.
>
> I'm still thinking it might be a good idea to have a separate chain for
> "refunds". Refunds will be rarely used and thus need a much slower
> moving window than receiving addresses or change.
>
>
> On 03/26/2014 09:49 PM, Mike Hearn wrote:
>> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
>> our BIP32 wallet structures would be compatible - and I discovered that
>> only I was planning to use the default structure.
>>
>> Because I'm hopeful that we can get a lot of interoperability between
>> wallets with regards to importing 12-words paper wallets, we
>> brainstormed to find a structure acceptable to everyone and ended up with:
>>
>> /m/cointype/reserved'/account'/change/n
>>
>> The extra levels require some explanation:
>>
>> * cointype: This is zero for Bitcoin. This is here to support two
>> things, one is supporting alt coins based off the same root seed.
>> Right now nobody seemed very bothered about alt coins but sometimes
>> feature requests do come in for this. Arguably there is no need and
>> alt coins could just use the same keys as Bitcoin, but it may help
>> avoid confusion if they don't.
>>
>> More usefully, cointype can distinguish between keys intended for
>> things like multisig outputs, e.g. for watchdog services. This means
>> if your wallet does not know about the extra protocol layers
>> involved in this, it can still import the "raw" money and it will
>> just ignore/not see the keys used in more complex transactions.
>>
>> * reserved is for "other stuff". I actually don't recall why we ended
>> up with this. It may have been intended to split out multisig
>> outputs etc from cointype. Marek, Thomas?
>>
>> * account is for keeping essentially wallets-within-a-wallet to avoid
>> mixing of coins. If you want that.
>>
>> * change is 0 for receiving addresses, 1 for change addresses.
>>
>> * n is the actual key index
>>
>> For bitcoinj we're targeting a deliberately limited feature set for hdw
>> v1 so I would just set the first three values all to zero and that is a
>> perfectly fine way to be compatible.
>>
>> The goal here is that the same seed can be written down once, and meet
>> all the users needs, whilst still allowing some drift between what
>> wallets support.
>>
>> Pieter made the I think valid point that you can't really encode how
>> keys are meant to be used into just an HDW hierarchy and normally you'd
>> need some metadata as well. However, I feel interop between wallets is
>> more important than arriving at the most perfect possible arrangement,
>> which feels a little like bikeshedding, so I'm happy to just go with the
>> flow on this one.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------020707030508040903050505
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 bgcolor="#FFFFFF" text="#000000">
This might be tangential, but the comment about "refund" chains
reminded me. Armory will be implementing multi-sig/linked wallets
where a each device has a parallel HDW branch and produces P2SH
addresses. For those types of wallets, I plan to allocate two
chains <i>per signing authority</i>. If you have a shared 2-of-2
wallet split between your phone and your spouse's phone, your phone
would distribute addresses on P2SH chain 0 and generate change
addresses on P2SH chain 1. Your spouse's phone would use chains 2
and 3. <br>
<br>
So if you and your spouse switch to a new app that supports M-of-N
linked wallets, it should search for coin history along the first
2*N chains.<br>
-Alan<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 03/26/2014 07:37 PM, Andreas
Schildbach wrote:<br>
</div>
<blockquote cite="mid:lgvobr$q44$1@ger.gmane.org" type="cite">
<pre wrap="">Thanks for starting the discussion on finding a better structure.
For me, the most important thing is either we're 100% interoperable or
0%. There should not be anything inbetween, as users will delete seeds
without knowing there is still money in them on another implementation.
I heard from multiple sources that using this standard some wallets will
only see a subset of the addresses/keys of some other wallets.
Implementation differences can always happen (and should addresses as
bugs), but I think its unacceptable that this source of issues is by design.
I suggest we agree on an even simpler least common denominator and
wallets that want to implement some feature on top of that can do but
are encouraged to pick a totally different "cointype". I guess that
would mean removing reserved and account.
I'm still thinking it might be a good idea to have a separate chain for
"refunds". Refunds will be rarely used and thus need a much slower
moving window than receiving addresses or change.
On 03/26/2014 09:49 PM, Mike Hearn wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
our BIP32 wallet structures would be compatible - and I discovered that
only I was planning to use the default structure.
Because I'm hopeful that we can get a lot of interoperability between
wallets with regards to importing 12-words paper wallets, we
brainstormed to find a structure acceptable to everyone and ended up with:
/m/cointype/reserved'/account'/change/n
The extra levels require some explanation:
* cointype: This is zero for Bitcoin. This is here to support two
things, one is supporting alt coins based off the same root seed.
Right now nobody seemed very bothered about alt coins but sometimes
feature requests do come in for this. Arguably there is no need and
alt coins could just use the same keys as Bitcoin, but it may help
avoid confusion if they don't.
More usefully, cointype can distinguish between keys intended for
things like multisig outputs, e.g. for watchdog services. This means
if your wallet does not know about the extra protocol layers
involved in this, it can still import the "raw" money and it will
just ignore/not see the keys used in more complex transactions.
* reserved is for "other stuff". I actually don't recall why we ended
up with this. It may have been intended to split out multisig
outputs etc from cointype. Marek, Thomas?
* account is for keeping essentially wallets-within-a-wallet to avoid
mixing of coins. If you want that.
* change is 0 for receiving addresses, 1 for change addresses.
* n is the actual key index
For bitcoinj we're targeting a deliberately limited feature set for hdw
v1 so I would just set the first three values all to zero and that is a
perfectly fine way to be compatible.
The goal here is that the same seed can be written down once, and meet
all the users needs, whilst still allowing some drift between what
wallets support.
Pieter made the I think valid point that you can't really encode how
keys are meant to be used into just an HDW hierarchy and normally you'd
need some metadata as well. However, I feel interop between wallets is
more important than arriving at the most perfect possible arrangement,
which feels a little like bikeshedding, so I'm happy to just go with the
flow on this one.
------------------------------------------------------------------------------
_______________________________________________
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>
<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>
--------------020707030508040903050505--
|
