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
|
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 <pieter.wuille@gmail.com>) id 1Wd1CK-0002Co-Ln
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 17:43:04 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.173 as permitted sender)
client-ip=209.85.223.173; envelope-from=pieter.wuille@gmail.com;
helo=mail-ie0-f173.google.com;
Received: from mail-ie0-f173.google.com ([209.85.223.173])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wd1CJ-0001i4-T9
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 17:43:04 +0000
Received: by mail-ie0-f173.google.com with SMTP id rl12so1260495iec.18
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 10:42:58 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.43.156.18 with SMTP id lk18mr2860444icc.77.1398274978581;
Wed, 23 Apr 2014 10:42:58 -0700 (PDT)
Received: by 10.50.127.243 with HTTP; Wed, 23 Apr 2014 10:42:58 -0700 (PDT)
In-Reply-To: <CAJna-Hib6umrkG0pAQzQvsyBMxOU6P675TURsVuWSU_ci9+X_A@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>
Date: Wed, 23 Apr 2014 19:42:58 +0200
Message-ID: <CAPg+sBiwzfXDAM0FKsBPi8d6E5y_nK5FDyfPvPhOTAA+f8654Q@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: slush <slush@centrum.cz>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.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
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1Wd1CJ-0001i4-T9
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: Wed, 23 Apr 2014 17:43:04 -0000
On Tue, Apr 8, 2014 at 5:41 PM, slush <slush@centrum.cz> wrote:
> 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.
Storing the seed is superior to storing the master node already
(whether coin specific or not), as it is smaller.
All this changes is making the seed the "super master" which allows
generating the coin-specific masters (which get an actual useful
function: revealing your entire-tree, but only one coin's subset of
it).
>> * 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").
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).
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 standard could just say that instead of "Bitcoin seed", you'd use
"Coin seed: " + magic, so you don't need an extra mapping from
cointype to seed strings.
--
Pieter
|
