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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <marek@palatinus.cz>) id 1WXY9g-0007R4-AZ
for bitcoin-development@lists.sourceforge.net;
Tue, 08 Apr 2014 15:41:44 +0000
X-ACL-Warn:
Received: from mail-ve0-f171.google.com ([209.85.128.171])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WXY9e-0000Ti-L2
for bitcoin-development@lists.sourceforge.net;
Tue, 08 Apr 2014 15:41:44 +0000
Received: by mail-ve0-f171.google.com with SMTP id jy13so955285veb.30
for <bitcoin-development@lists.sourceforge.net>;
Tue, 08 Apr 2014 08:41:37 -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=Zavy6+2L0X6DQ642w5+JkrrOJIEB80Rza8y1EqaS6rI=;
b=G9FGsVvtS2s2srGuvCAaNWhv/iRW53PuBAuPAHOG3XTrFh8WwMXF+wEhHpG+Ba8Pqi
VBRLSMXAbWxQ45Rn7p2Ku1wQDo+kcwImoMASRWO8I8dIQSpdlE8jl9TX3I1zKdFwpBXX
qFDpdOc9yEA5lB+RODpvIveg1aO1yhL6WFUd1PLaBAPdyf8DJ4uaucYV523T5Qm9YTCz
m+OMNFjg7in8aZ+o4cmSVyS4md92Jk5f+frpBRt73GgwXof1PNX9LLsRMp3D2OC2V4UY
bry/nKiqig2GEJFikNVa7+yyN1geLv0lsz+JkWGf2aopgzoZlPxaUEutNnoTO2ZwHRy/
Pllg==
X-Gm-Message-State: ALoCoQnrjzFvQjrDlk75rOjWya/4eAYzLL9n3YVWFX2vpS0YGK0TOCcVYZxMzO24FeyZOo5HyasK
X-Received: by 10.220.163.3 with SMTP id y3mr3802278vcx.7.1396971697048; Tue,
08 Apr 2014 08:41:37 -0700 (PDT)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.58.234.100 with HTTP; Tue, 8 Apr 2014 08:41:06 -0700 (PDT)
In-Reply-To: <CAPg+sBguSQ8dk1xXKinX+ez4BmdM3sz-huruuhD6NCTsp0kRBQ@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>
From: slush <slush@centrum.cz>
Date: Tue, 8 Apr 2014 17:41:06 +0200
X-Google-Sender-Auth: 8IMv6LNUTGoYvXABfYyzRm6HRIc
Message-ID: <CAJna-Hib6umrkG0pAQzQvsyBMxOU6P675TURsVuWSU_ci9+X_A@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a1133da66c3a21604f689d1b8
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: 1WXY9e-0000Ti-L2
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 15:41:44 -0000
--001a1133da66c3a21604f689d1b8
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Apr 8, 2014 at 3:53 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote:
> I see the cause of our disagreement now.
>
> You actually want to share a single BIP32 tree across different
> currency types, but do it in a way that guarantees that they never use
> the same keys.
>
> I would have expected that different chains would use independent
> chains, and have serializations encode which chain they belong to.
>
> Let me offer an alternative suggestion, which is compatible with the
> original default BIP32 structure:
> * You can use one seed across different chains, but the master nodes
> are separate.
> * To derive the master node from the seed, the key string "Bitcoin
> seed" is replaced by something chain-specific.
>
I've discussed the solution of "Litecoin seed" in BIP32 HMAC with Litecoin
devs already, and after long discussion we've concluded that it is
generally bad idea.
When changing "Bitcoin seed" constant to something different, same
*entropy* will produce different *master node*. That's actually the
opposite what's requested, because xprv serialization format stores *node*,
not *entropy*. By changing HMAC constant, you still won't be able to store
one node and derive wallets for multiple coins at same time.
> * Every encoded node (including master nodes) has a chain-specific
> serialization magic.
>
This is in practice almost the same as your suggestion, except that
> the m/cointype' in m/cointype'/account'/change/n is replaced by
> different masters. The only disadvantage I see is that you do not have
> a way to encode the "super master" that is the parent of all
> chain-specific masters. You can - and with the same security
> properties - encode the seed, though.
>
>
Actually I don't understand why there's such disagreement about "cointype"
level here, what it breaks? I see it as the cleanest solution so far. It is
forward and backward compatible, does need any special extension to bip32
(to be strict, bip32 says "Bitcoin seed", so client using "Litecoin seed"
cannot be "bip32 compatible").
Of course, the problem of "cointype" can be solved in zillion ways, but
still using cointype in bip32 path seem to be the most elegant way so far,
because it fullfill all requirements for single backup, for separating
pubkeys and for handling all coins by one master...
Marek
--001a1133da66c3a21604f689d1b8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote">On Tue, Apr 8, 2014 at 3:53 PM, Pieter Wuille <span dir=3D"ltr">=
<<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wui=
lle@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">I see the cause of our disagreement now.<br>
<br>
You actually want to share a single BIP32 tree across different<br>
currency types, but do it in a way that guarantees that they never use<br>
the same keys.<br>
<br>
I would have expected that different chains would use independent<br>
chains, and have serializations encode which chain they belong to.<br>
<br>
Let me offer an alternative suggestion, which is compatible with the<br>
original default BIP32 structure:<br>
* You can use one seed across different chains, but the master nodes<br>
are separate.<br>
* To derive the master node from the seed, the key string "Bitcoin<br>
seed" is replaced by something chain-specific.<br></blockquote><div><b=
r></div>I've discussed the solution of "Litecoin seed" in BIP=
32 HMAC with Litecoin devs already, and after long discussion we've con=
cluded that it is generally bad idea.<div>
<br></div><div>When changing "Bitcoin seed" constant to something=
different, same *entropy* will produce different *master node*. That's=
actually the opposite what's requested, because xprv serialization for=
mat stores *node*, not *entropy*. By changing HMAC constant, you still won&=
#39;t be able to store one node and derive wallets for multiple coins at sa=
me time.</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex">
* Every encoded node (including master nodes) has a chain-specific<br>
serialization magic.<br></blockquote><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex">
This is in practice almost the same as your suggestion, except that<br>
the m/cointype' in m/cointype'/account'/change/n is replaced by=
<br>
different masters. The only disadvantage I see is that you do not have<br>
a way to encode the "super master" that is the parent of all<br>
chain-specific masters. You can - and with the same security<br>
properties - encode the seed, though.<br>
<span class=3D""><font color=3D"#888888"><br></font></span></blockquote><di=
v><br></div><div>Actually I don't understand why there's such disag=
reement about "cointype" level here, what it breaks? I see it as =
the cleanest solution so far. It is forward and backward compatible, does n=
eed any special extension to bip32 (to be strict, bip32 says "Bitcoin =
seed", so client using "Litecoin seed" cannot be "bip32=
compatible").</div>
<div><br></div><div>Of course, the problem of "cointype" can be s=
olved in zillion ways, but still using cointype in bip32 path seem to be th=
e most elegant way so far, because it fullfill all requirements for single =
backup, for separating pubkeys and for handling all coins by one master...<=
/div>
<div><br></div><div>Marek</div><div><br></div></div></div></div>
--001a1133da66c3a21604f689d1b8--
|
