From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: <53344FF8.7030204@gk2.sk> Date: Wed, 23 Apr 2014 19:42:58 +0200 Message-ID: From: Pieter Wuille To: slush 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 Subject: Re: [Bitcoin-development] New BIP32 structure X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 17:43:04 -0000 On Tue, Apr 8, 2014 at 5:41 PM, slush 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