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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1YgOeK-0004zS-8K
for bitcoin-development@lists.sourceforge.net;
Fri, 10 Apr 2015 02:26:28 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.179 as permitted sender)
client-ip=209.85.220.179; envelope-from=etotheipi@gmail.com;
helo=mail-qk0-f179.google.com;
Received: from mail-qk0-f179.google.com ([209.85.220.179])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YgOeI-0007EI-LV
for bitcoin-development@lists.sourceforge.net;
Fri, 10 Apr 2015 02:26:28 +0000
Received: by qkx62 with SMTP id 62so9819313qkx.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 09 Apr 2015 19:26:21 -0700 (PDT)
X-Received: by 10.140.89.149 with SMTP id v21mr38889081qgd.50.1428632781248;
Thu, 09 Apr 2015 19:26:21 -0700 (PDT)
Received: from [192.168.1.28] (c-69-143-204-74.hsd1.md.comcast.net.
[69.143.204.74])
by mx.google.com with ESMTPSA id y18sm592410qgd.24.2015.04.09.19.26.20
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 09 Apr 2015 19:26:20 -0700 (PDT)
Message-ID: <552734CB.4070903@gmail.com>
Date: Thu, 09 Apr 2015 22:26:19 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: William Swanson <swansontec@gmail.com>
References: <5524D347.4040507@maza.club> <CABjHNoTbLz+dCPkctk95jPkdnagQQxOintYgswKCE6wB=TS9xg@mail.gmail.com> <CACvEmnE6jgeRmTbyoOfW+jf=EB_EmPN4FdBXz-anm4tfKJscqw@mail.gmail.com> <CABjHNoR_Tg6bq3mJ8vkFAOPNHz8RS-FKAEx9APMZAVhct5H0SA@mail.gmail.com> <5526DE29.1060605@maza.club> <CABjHNoQq7OmkmawA-Z-ugd37EFTefh5KqjUThF=fbg1k4u_ThQ@mail.gmail.com> <5526FF23.9040402@gmail.com>
<CABjHNoQUMzUB+Q-dk+C=AzwXkVUC1fJOtVAB4TpXWhg2ONJdBg@mail.gmail.com>
In-Reply-To: <CABjHNoQUMzUB+Q-dk+C=AzwXkVUC1fJOtVAB4TpXWhg2ONJdBg@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------010803040505020508010305"
X-Spam-Score: -1.1 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-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
-0.5 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YgOeI-0007EI-LV
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Request For Discussion / BIP number -
Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets
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, 10 Apr 2015 02:26:28 -0000
This is a multi-part message in MIME format.
--------------010803040505020508010305
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
The motivation was that I came up with it before BIP 45 existed, but
wasn't vocal enough about it because Armory didn't have BIP32 Multisig
trees implemented yet, so I didn't have a strong mental focus or
determination around it. If there's momentum behind BIP45, we should
use it. I wanted to share the document because it was also created to
be educational on the topic of "multisig address generation collisions"
as being disucussed in this thread.
Though we just put in BIP44 with my modification into our new wallet
format (in the works), and if I was to adopt this I'd like to simply
merge the two.
M / purpose' / coin' / account' / *cosigner* / change*0or1* / address
For reference my proposal (and the way I implemented it before BIP45
existed) is just BIP44 but with 2*N change branches instead of 2:
M / purpose' / coin' / account' / change*2N* / address
Our new code has the goal of being able to easily reconfigure your BIP32
tree for your specific application. But for the default
free-public-download software, it would be nice to have a standard
everyone agrees to. BIP44 vs original-BIP32 doesn't really matter since
you only transfer the account branches, but this particular decision
with how the consigners avoid "collisions" does affect it.
-Alan
On 04/09/2015 10:02 PM, William Swanson wrote:
> Hello Alan,
> Your scheme is basically the same as the BIP45 scheme, except that you
> have collapsed the "cosigner_index" and "change" fields into a single
> field with the formula:
>
> combined = 2*cosigner_index + change
>
> This removes one level from the hierarchy, but ultimately produces the
> same number and type of chains as BIP45 (just addressed differently).
>
> I kinda like the BIP45's approach of giving each field has its own
> dedicated purpose. What is the motivation behind flattening the
> hierarchy?
>
> I ask because the wallet I work on, Airbitz, will be adding multi-sig
> at some point in the future, and we need to figure out what kind of HD
> tree structure we will be using. Our ideal structure would basically
> be BIP 44 plus some "no-collision" logic:
>
> m / purpose' / coin_type' / wallet' / cosigner_index / change /
> address_index
>
> I feel like interoperability with Copay would be worth the extra HD
> branch. Assuming Kefkius adds similar no-collision logic, his proposal
> is pretty close to our ideal:
>
> m / purpose' / wallet' / coin_type / cosigner_index / change / address_index
>
> Of course, I am open to hearing your thoughts on this as well.
>
> -William
>
> On Thu, Apr 9, 2015 at 3:37 PM, Alan Reiner <etotheipi@gmail.com> wrote:
>> BTW, I had originally proposed a "no-collision" scheme for
>> multi-signature wallets, which doesn't require modifying the key tree
>> structure at all, except for adding new internal and external chains
>> (2*N chains). All siblings watch all chains, but only generate
>> receiving and change addresses on their two chains.
>>
>> The original document is here, which might be educational for the
>> purposes of understand precisely the problem that needs a solution (and
>> mine is a different solution than BIP45).
>>
>> https://www.dropbox.com/s/58poxi60d8nfj5w/MultisigWalletNoCollide.pdf
>>
>> I prefer not adding even more levels to the key tree, and (IMO) it makes
>> more sense to add more chains to the wallet instead of adding a new tree
>> level (as it allows for a simpler tree in the event that you don't need
>> separate cosigners). But I suspect that there's a certain momentum
>> behind the cosigner-index method already in BIP45? Just throwing it out
>> there.
--------------010803040505020508010305
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
The motivation was that I came up with it before BIP 45 existed, but
wasn't vocal enough about it because Armory didn't have BIP32
Multisig trees implemented yet, so I didn't have a strong mental
focus or determination around it. If there's momentum behind BIP45,
we should use it. I wanted to share the document because it was
also created to be educational on the topic of "multisig address
generation collisions" as being disucussed in this thread.<br>
<br>
Though we just put in BIP44 with my modification into our new wallet
format (in the works), and if I was to adopt this I'd like to simply
merge the two. <br>
<br>
M / purpose' / coin' / account' / <b>cosigner</b> / change<b>0or1</b>
/ address<br>
<br>
For reference my proposal (and the way I implemented it before BIP45
existed) is just BIP44 but with 2*N change branches instead of 2:<br>
<br>
M / purpose' / coin' / account' / change<b>2N</b> / address <br>
<br>
Our new code has the goal of being able to easily reconfigure your
BIP32 tree for your specific application. But for the default
free-public-download software, it would be nice to have a standard
everyone agrees to. BIP44 vs original-BIP32 doesn't really matter
since you only transfer the account branches, but this particular
decision with how the consigners avoid "collisions" does affect it.
<br>
<br>
-Alan<br>
<br>
<br>
<div class="moz-cite-prefix">On 04/09/2015 10:02 PM, William Swanson
wrote:<br>
</div>
<blockquote
cite="mid:CABjHNoQUMzUB+Q-dk+C=AzwXkVUC1fJOtVAB4TpXWhg2ONJdBg@mail.gmail.com"
type="cite">
<pre wrap="">Hello Alan,
Your scheme is basically the same as the BIP45 scheme, except that you
have collapsed the "cosigner_index" and "change" fields into a single
field with the formula:
combined = 2*cosigner_index + change
This removes one level from the hierarchy, but ultimately produces the
same number and type of chains as BIP45 (just addressed differently).
I kinda like the BIP45's approach of giving each field has its own
dedicated purpose. What is the motivation behind flattening the
hierarchy?
I ask because the wallet I work on, Airbitz, will be adding multi-sig
at some point in the future, and we need to figure out what kind of HD
tree structure we will be using. Our ideal structure would basically
be BIP 44 plus some "no-collision" logic:
m / purpose' / coin_type' / wallet' / cosigner_index / change /
address_index
I feel like interoperability with Copay would be worth the extra HD
branch. Assuming Kefkius adds similar no-collision logic, his proposal
is pretty close to our ideal:
m / purpose' / wallet' / coin_type / cosigner_index / change / address_index
Of course, I am open to hearing your thoughts on this as well.
-William
On Thu, Apr 9, 2015 at 3:37 PM, Alan Reiner <a class="moz-txt-link-rfc2396E" href="mailto:etotheipi@gmail.com"><etotheipi@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">BTW, I had originally proposed a "no-collision" scheme for
multi-signature wallets, which doesn't require modifying the key tree
structure at all, except for adding new internal and external chains
(2*N chains). All siblings watch all chains, but only generate
receiving and change addresses on their two chains.
The original document is here, which might be educational for the
purposes of understand precisely the problem that needs a solution (and
mine is a different solution than BIP45).
<a class="moz-txt-link-freetext" href="https://www.dropbox.com/s/58poxi60d8nfj5w/MultisigWalletNoCollide.pdf">https://www.dropbox.com/s/58poxi60d8nfj5w/MultisigWalletNoCollide.pdf</a>
I prefer not adding even more levels to the key tree, and (IMO) it makes
more sense to add more chains to the wallet instead of adding a new tree
level (as it allows for a simpler tree in the event that you don't need
separate cosigners). But I suspect that there's a certain momentum
behind the cosigner-index method already in BIP45? Just throwing it out
there.
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------010803040505020508010305--
|
