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; 
MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New BIP32 structure
Precedence: list

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