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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1XXLJh-0002Pk-Qa
for bitcoin-development@lists.sourceforge.net;
Fri, 26 Sep 2014 02:31:29 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.46 as permitted sender)
client-ip=209.85.192.46; envelope-from=etotheipi@gmail.com;
helo=mail-qg0-f46.google.com;
Received: from mail-qg0-f46.google.com ([209.85.192.46])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XXLJg-0005IY-LX
for bitcoin-development@lists.sourceforge.net;
Fri, 26 Sep 2014 02:31:29 +0000
Received: by mail-qg0-f46.google.com with SMTP id q108so8559492qgd.33
for <bitcoin-development@lists.sourceforge.net>;
Thu, 25 Sep 2014 19:31:23 -0700 (PDT)
X-Received: by 10.140.21.177 with SMTP id 46mr14411748qgl.90.1411698683053;
Thu, 25 Sep 2014 19:31:23 -0700 (PDT)
Received: from [192.168.1.85] (c-69-143-221-64.hsd1.md.comcast.net.
[69.143.221.64])
by mx.google.com with ESMTPSA id t2sm3618521qaj.47.2014.09.25.19.31.21
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Thu, 25 Sep 2014 19:31:22 -0700 (PDT)
Message-ID: <5424CFF3.50404@gmail.com>
Date: Thu, 25 Sep 2014 22:31:15 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <53F38542.2000704@monetas.net>
<CAAS2fgT7eUDUHqwtuMF9cj0LvzHdZXxyan+c2ep1dQ8dQGOrHw@mail.gmail.com>
In-Reply-To: <CAAS2fgT7eUDUHqwtuMF9cj0LvzHdZXxyan+c2ep1dQ8dQGOrHw@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------070004030409000605030709"
X-Spam-Score: -0.6 (/)
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
X-Headers-End: 1XXLJg-0005IY-LX
Subject: Re: [Bitcoin-development] BIP43 Purpose code for voting pool HD
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, 26 Sep 2014 02:31:30 -0000
This is a multi-part message in MIME format.
--------------070004030409000605030709
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'm in favor of BIP43.
Adding a "Purpose" node can be used as an identifier for what kind of
tree is in the wallet file we're reading. I can envision a few
different, common tree structures. Perhaps using a non-hardened
first-layer derivation (we have clients who want this). Similarly, my
proposal for a "No-collision mode" for multisig BIP32 trees
<http://sourceforge.net/p/bitcoin/mailman/message/32860512/> is another
variant that might get some traction but not everyone will use it.=20
These things could be "supported" by simply changing the BIP43 "Purpose"
index and wallet software could be designed to recognize and react to
the Purpose node for any number of different tree structures, and ignore
any trees that it doesn't recognize (or maybe be able to view the
balance across all the leaves of the tree but not expand it)
We have clients with special use-cases (complex multi-layer trees) that
are unlikely to be recycled across users. In such cases we might just
use a "random" Purpose that is recognized by their system, and know that
other software won't mess with it. Though it would be better if that
field was encoded in the root seed, instead.
Nonetheless, putting that extra layer between the root and the
"important" tree nodes provides flexibility to BIP32 as a whole.
-Alan
On 09/25/2014 09:53 PM, Gregory Maxwell wrote:
> On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier <justus@monetas.net> w=
rote:
>> Two draft information BIPs are attached.
> I've pinged some people privately but also pinging the list=E2=80=A6 no=
> commentary on this proposal?
>
> -----------------------------------------------------------------------=
-------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Report=
s
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=3D154622311&iu=3D/4140/os=
tg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------070004030409000605030709
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">
I'm in favor of BIP43. <br>
<br>
Adding a "Purpose" node can be used as an identifier for what kind
of tree is in the wallet file we're reading. I can envision a few
different, common tree structures. Perhaps using a non-hardened
first-layer derivation (we have clients who want this). Similarly,
my proposal for a <a
href="http://sourceforge.net/p/bitcoin/mailman/message/32860512/">"No-collision
mode" for multisig BIP32 trees</a> is another variant that might
get some traction but not everyone will use it. These things could
be "supported" by simply changing the BIP43 "Purpose" index and
wallet software could be designed to recognize and react to the
Purpose node for any number of different tree structures, and ignore
any trees that it doesn't recognize (or maybe be able to view the
balance across all the leaves of the tree but not expand it)<br>
<br>
We have clients with special use-cases (complex multi-layer trees)
that are unlikely to be recycled across users. In such cases we
might just use a "random" Purpose that is recognized by their
system, and know that other software won't mess with it. Though it
would be better if that field was encoded in the root seed, instead.<br>
<br>
Nonetheless, putting that extra layer between the root and the
"important" tree nodes provides flexibility to BIP32 as a whole.<br>
-Alan<br>
<br>
<br>
<div class="moz-cite-prefix">On 09/25/2014 09:53 PM, Gregory Maxwell
wrote:<br>
</div>
<blockquote
cite="mid:CAAS2fgT7eUDUHqwtuMF9cj0LvzHdZXxyan+c2ep1dQ8dQGOrHw@mail.gmail.com"
type="cite">
<pre wrap="">On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier <a class="moz-txt-link-rfc2396E" href="mailto:justus@monetas.net"><justus@monetas.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Two draft information BIPs are attached.
</pre>
</blockquote>
<pre wrap="">
I've pinged some people privately but also pinging the list… no
commentary on this proposal?
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk</a>
_______________________________________________
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>
--------------070004030409000605030709--
|
