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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <marek@palatinus.cz>) id 1Wd1l1-0004QP-CY
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 18:18:55 +0000
X-ACL-Warn:
Received: from mail-ve0-f178.google.com ([209.85.128.178])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wd1ky-0005hp-2X
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 18:18:55 +0000
Received: by mail-ve0-f178.google.com with SMTP id jw12so1657518veb.9
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 11:18:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:cc:content-type;
bh=IVGRQu1qAuPgsQlmHfTAO8CWO3agZlAHx3VOr5hwfHQ=;
b=FtY6bU5aB+5Yaqv4Hks2EWuIzpM+LFtTWvmgcdoE55ETD06fOxpCHZOJzEJ6frgXDn
MGygMbjKtNniHkbQz/e6gmTUDsJRM7Fqd8kwUVDoAigxG9aNJKWUkt1vp6HRr3LqyHp+
sSrIV/XDSFv7K8kchbwkfzI/VO/ASMrSDmEimyQyo2rZe/74v04v5innc2+mXuR7HSbC
nYtrgwpgAFY4MyIl3rt1V/Eb1TR57IzaH3aU/ogOE5V5mWPmuV05kUj0PzwNRq6CnUNg
PfH6thrXsIhN73JjV2ybT/c/iBzxM/n1mFoAq7SfsH5GUQ+3TYIXxJ4Hu4KiL7lG4Psc
RqzA==
X-Gm-Message-State: ALoCoQkGLgXY6OdcYOj4cTwjD3olAupb6r16EAytz4AWj/FjsA4FO3z1/3cpF7QpVdLgbQ6+TxeN
X-Received: by 10.52.31.167 with SMTP id b7mr727817vdi.79.1398277126364; Wed,
23 Apr 2014 11:18:46 -0700 (PDT)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.58.234.68 with HTTP; Wed, 23 Apr 2014 11:18:16 -0700 (PDT)
In-Reply-To: <CAJna-HhPm0U2odPgRji7zJqCZCWuXKT_=ayC2tsajjRX5TiCXg@mail.gmail.com>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
<F2C8C044-EF92-4CCE-9235-28CA7FCE3526@bitsofproof.com>
<CAJHLa0PPAsBLgsy0vgPpUp=UzeR_fWUEzFb5+xtmODEk4MGPVQ@mail.gmail.com>
<CAJfRnm7V6fgcj=TMfa2ZTYWOKtE5aoUT1xnVtKUSyriB=6cagQ@mail.gmail.com>
<CAPg+sBjwf1TcK1CGKVKFzYbV-78j8t-pav7=PEgG7Yqi6-yE7A@mail.gmail.com>
<53344FF8.7030204@gk2.sk>
<CAPg+sBhbx5vy_hewAkFPaiXHzSMNH0qLhEYGjPmQMjR5StP-tw@mail.gmail.com>
<CAJna-Hi0JnrF2_rUx0rGkdnsuCoaD01e3Gobpn+QqbL=D1Uivg@mail.gmail.com>
<CAJna-HirtsGLfAhfUf9dAYEGWo6g=o=eAU187c2pdW8vDFGkPw@mail.gmail.com>
<CAPg+sBg8wDH9yTUoyhRbuzVtbD8hGxya8tOnV4pMToHy3gLrzw@mail.gmail.com>
<CAJna-HiN_1KQmpDJFFX6mGvM63RC0xwXxvfuorpihnzYf4=fsQ@mail.gmail.com>
<CAJna-HgfpyHX_0AHwt1Hkj0qhD_-xOcpxsZ9KXq=7CPgwse1hA@mail.gmail.com>
<CAPg+sBguSQ8dk1xXKinX+ez4BmdM3sz-huruuhD6NCTsp0kRBQ@mail.gmail.com>
<CAJna-Hib6umrkG0pAQzQvsyBMxOU6P675TURsVuWSU_ci9+X_A@mail.gmail.com>
<CAPg+sBiwzfXDAM0FKsBPi8d6E5y_nK5FDyfPvPhOTAA+f8654Q@mail.gmail.com>
<CAJna-HhPm0U2odPgRji7zJqCZCWuXKT_=ayC2tsajjRX5TiCXg@mail.gmail.com>
From: slush <slush@centrum.cz>
Date: Wed, 23 Apr 2014 20:18:16 +0200
X-Google-Sender-Auth: iJRVq1hye2gXIzkdLGJ5mroudK4
Message-ID: <CAJna-Hh2t-E=fm9V0EH+qOQTx+qsmcBemEJmML0G9PgsrJr5eg@mail.gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=bcaec51d27906a36ca04f7b9c386
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(slush[at]centrum.cz)
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Wd1ky-0005hp-2X
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: Wed, 23 Apr 2014 18:18:55 -0000
--bcaec51d27906a36ca04f7b9c386
Content-Type: text/plain; charset=ISO-8859-1
For those who don't follow github pull requests regularly; there's pull
request for BIP64 defining HD wallet structure as discussed in this thread:
https://github.com/bitcoin/bips/pull/52
On Wed, Apr 23, 2014 at 8:01 PM, slush <slush@centrum.cz> wrote:
>
>
>
> On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote:
>>
>> Storing the seed is superior to storing the master node already
>> (whether coin specific or not), as it is smaller.
>>
>>
> ...Except that you're loosing flexibility (serialization, deserialization)
> which gives you BIP32 node.
>
> I see "bip32 seed" as some transitional, internal state from raw entropy
> to bip32 master node and this seed should not be handled by the end user in
> any form. In the oposite, well-serialized bip32 node (in xpriv, or even in
> mnemonic format) can be used very widely and have no downsides against
> using raw "bip32 seed".
>
>
>>
>> Fair enough, it would break strictly BIP32. Then again, BIP32 is a
>> *Bitcoin* improvement proposal, and not something that necessarily
>> applies to other coins (they can adopt it of course, I don't care).
>>
>>
> I also don't care too much about altcoins, but people want them so me, as
> infrastructure developer, need to think about it. And I don't see any
> reason for breaking compatibility between Bitcoin and other altcoins. I
> would be happier if there will be another sentence than "Bitcoin seed", but
> honestly, who cares. It is just some magic string for hashing the raw
> seed...
>
>
>> What I dislike is that this removes the ability of using the magic in
>> the serialization to prevent importing a chain from the wrong coin.
>>
>
> The truth is that even existing software which handle bip32 don't care
> about 'version' at all. I think that "xpub/xprv" distinction is the only
> useful feature of version, so user se if it stores public or private
> information.
>
> But using prefixes which doesn't enforce anything is even more dangerous.
> If somebody exports node "dogeblablabla", it creates false exceptations
> that there's only dogecoin stored.
>
> Marek
>
--bcaec51d27906a36ca04f7b9c386
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">For those who don't follow github pull requests regula=
rly; there's pull request for BIP64 defining HD wallet structure as dis=
cussed in this thread:<div><br></div><div><a href=3D"https://github.com/bit=
coin/bips/pull/52">https://github.com/bitcoin/bips/pull/52</a><br>
</div><div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D=
"gmail_quote">On Wed, Apr 23, 2014 at 8:01 PM, slush <span dir=3D"ltr"><=
<a href=3D"mailto:slush@centrum.cz" target=3D"_blank">slush@centrum.cz</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"">On Wed, Apr 23, 2014=
at 7:42 PM, Pieter Wuille <span dir=3D"ltr"><<a href=3D"mailto:pieter.w=
uille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com</a>></span> w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
Storing the seed is superior to storing the master node already<br>
(whether coin specific or not), as it is smaller.<br>
<br></blockquote><div><br></div></div><div>...Except that you're loosin=
g flexibility (serialization, deserialization) which gives you BIP32 node.<=
/div><div><br></div><div>I see "bip32 seed" as some transitional,=
internal state from raw entropy to bip32 master node and this seed should =
not be handled by the end user in any form. In the oposite, well-serialized=
bip32 node (in xpriv, or even in mnemonic format) can be used very widely =
and have no downsides against using raw "bip32 seed".</div>
<div class=3D"">
<div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
</div>Fair enough, it would break strictly BIP32. Then again, BIP32 is a<br=
>
*Bitcoin* improvement proposal, and not something that necessarily<br>
applies to other coins (they can adopt it of course, I don't care).<br>
<br></blockquote><div><br></div></div><div>I also don't care too much a=
bout altcoins, but people want them so me, as infrastructure developer, nee=
d to think about it. And I don't see any reason for breaking compatibil=
ity between Bitcoin and other altcoins. I would be happier if there will be=
another sentence than "Bitcoin seed", but honestly, who cares. I=
t is just some magic string for hashing the raw seed...</div>
<div class=3D"">
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
What I dislike is that this removes the ability of using the magic in<br>
the serialization to prevent importing a chain from the wrong coin.<br></bl=
ockquote><div><br></div></div><div>The truth is that even existing software=
which handle bip32 don't care about 'version' at all. I think =
that "xpub/xprv" distinction is the only useful feature of versio=
n, so user se if it stores public or private information.</div>
<div><br></div><div>But using prefixes which doesn't enforce anything i=
s even more dangerous. If somebody exports node "dogeblablabla", =
it creates false exceptations that there's only dogecoin stored.</div>
<div><br></div><div>=A0Marek</div></div></div></div>
</blockquote></div><br></div>
--bcaec51d27906a36ca04f7b9c386--
|
