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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <marek@palatinus.cz>) id 1WXWGY-0005Kq-GN
for bitcoin-development@lists.sourceforge.net;
Tue, 08 Apr 2014 13:40:42 +0000
X-ACL-Warn:
Received: from mail-vc0-f176.google.com ([209.85.220.176])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WXWGX-0005Tr-76
for bitcoin-development@lists.sourceforge.net;
Tue, 08 Apr 2014 13:40:42 +0000
Received: by mail-vc0-f176.google.com with SMTP id lc6so759345vcb.35
for <bitcoin-development@lists.sourceforge.net>;
Tue, 08 Apr 2014 06:40:35 -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:to:cc:content-type;
bh=KYN4l0kkrID34B49CrSf1rH7RCRLlY0sc9+d5DGRiks=;
b=AtlTwWagmrmsGOf/PfxOsmX07/7i5hPfY2s8m8Ht2NKaSCR9oIGA38C9v6PtZkknn/
/lQfaRPgp6S53tWk9ql247pVWrkaVZHhoeRAfoX+GYlnEFdL/93q78eeUCKIEViJrYhU
anNRnGj6cpO/5bOk8uh4fKUwVc6Zg7kNrdtGeKNNehvPHWgGqJ2fk8wtBbFKXjjpKHs2
E8cIWmcc5ZMh/GvZB9NW677PQgWfbqdbRR0BpuZiO0jugeAaOmFxnPUkawfoBK3b996K
zUpVF31Fw+CMBxWTV6oQwaWEU9poxHyISAjf3CoI1XFbTX0TtFqVttpAnobQ7QnbenQq
Oiiw==
X-Gm-Message-State: ALoCoQnS6Vlmy7dEqreB6LpIcandd3T5XONotBkMKoZ61w2thlr88qqNGCQi4bSHu5MDYELOU3kM
X-Received: by 10.58.90.99 with SMTP id bv3mr150831veb.34.1396964435698; Tue,
08 Apr 2014 06:40:35 -0700 (PDT)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.58.234.100 with HTTP; Tue, 8 Apr 2014 06:40:05 -0700 (PDT)
In-Reply-To: <CAPg+sBg8wDH9yTUoyhRbuzVtbD8hGxya8tOnV4pMToHy3gLrzw@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>
From: slush <slush@centrum.cz>
Date: Tue, 8 Apr 2014 15:40:05 +0200
X-Google-Sender-Auth: GpU_ylvDhww2FBSyUbFrpYXvAuc
Message-ID: <CAJna-HiN_1KQmpDJFFX6mGvM63RC0xwXxvfuorpihnzYf4=fsQ@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=089e01182b8ef43a0904f68820a6
X-Spam-Score: 1.0 (+)
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.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1WXWGX-0005Tr-76
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: Tue, 08 Apr 2014 13:40:42 -0000
--089e01182b8ef43a0904f68820a6
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Apr 8, 2014 at 3:18 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote:
> I still don't understand the purpose of cointype. If you don't want to
> risk reusing the same keys across different currencies, just don't use
> the same seed or the same account? That is purely a client-side issue.
>
>
Of course it is purely client-side issue, but it matters.
There's actually no reason to generate, backup and store individual seeds
for various coins and purposes. User can handle all his identities and
altcoins with single seed, avoiding potential issues with using wrong seed
for other purposes.
Actually with accounts and cointypes in the path, you can have all your
crypto funds stored on single seed, which I see as very comfortable
solution.
But to gain advantages of such solution and avoid reusing the same path
across blockchains, we need to separate the space, which is achieved by
cointype.
> If the consensus is to add the cointype anyway, can we fix it to be
> equal to the 4-byte magic in the serialization (after setting the high
> bit to true)? That way there aren't two 4-byte magic codes that need
> to be defined for each, and at the same time make it obvious from the
> serialized form what it is for.
>
>
Serialization magic of bip32 seed is in my opinion completely unnecessary.
Most of software does not care about it anyway; You can use xprv/xpub pair
for main net, testnet, litecoin, dogecoin, whatevercoin.
Instead using the same seed (xprv) and then separate the chains *inside*
the bip32 path seems more useful to me.
Marek
--089e01182b8ef43a0904f68820a6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Apr 8, 2014 at 3:18 PM, Pieter Wuille <span dir=3D"ltr"><<a href=
=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.c=
om</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I still don't understand the purpose of =
cointype. If you don't want to<br>
risk reusing the same keys across different currencies, just don't use<=
br>
the same seed or the same account? That is purely a client-side issue.<br>
<br></blockquote><div><br></div><div>Of course it is purely client-side iss=
ue, but it matters.</div><div><br></div><div>There's actually no reason=
to generate, backup and store individual seeds for various coins and purpo=
ses. User can handle all his identities and altcoins with single seed, avoi=
ding potential issues with using wrong seed for other purposes.</div>
<div><br></div><div>Actually with accounts and cointypes in the path, you c=
an have all your crypto funds stored on single seed, which I see as very co=
mfortable solution.</div><div><br></div><div>But to gain advantages of such=
solution and avoid reusing the same path across blockchains, we need to se=
parate the space, which is achieved by cointype.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
If the consensus is to add the cointype anyway, can we fix it to be<br>
equal to the 4-byte magic in the serialization (after setting the high<br>
bit to true)? That way there aren't two 4-byte magic codes that need<br=
>
to be defined for each, and at the same time make it obvious from the<br>
serialized form what it is for.<br>
<div><div class=3D"h5"><br></div></div></blockquote><div><br></div><div>Ser=
ialization magic of bip32 seed is in my opinion completely unnecessary. Mos=
t of software does not care about it anyway; You can use xprv/xpub pair for=
main net, testnet, litecoin, dogecoin, whatevercoin.</div>
<div><br></div><div>Instead using the same seed (xprv) and then separate th=
e chains *inside* the bip32 path seems more useful to me.</div><div><br></d=
iv><div>Marek=A0</div></div></div></div>
--089e01182b8ef43a0904f68820a6--
|
