Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd1l1-0004QP-CY for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 18:18:55 +0000 X-ACL-Warn: Received: from mail-ve0-f178.google.com ([209.85.128.178]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd1ky-0005hp-2X for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 18:18:55 +0000 Received: by mail-ve0-f178.google.com with SMTP id jw12so1657518veb.9 for ; Wed, 23 Apr 2014 11:18:46 -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:cc:content-type; bh=IVGRQu1qAuPgsQlmHfTAO8CWO3agZlAHx3VOr5hwfHQ=; b=FtY6bU5aB+5Yaqv4Hks2EWuIzpM+LFtTWvmgcdoE55ETD06fOxpCHZOJzEJ6frgXDn MGygMbjKtNniHkbQz/e6gmTUDsJRM7Fqd8kwUVDoAigxG9aNJKWUkt1vp6HRr3LqyHp+ sSrIV/XDSFv7K8kchbwkfzI/VO/ASMrSDmEimyQyo2rZe/74v04v5innc2+mXuR7HSbC nYtrgwpgAFY4MyIl3rt1V/Eb1TR57IzaH3aU/ogOE5V5mWPmuV05kUj0PzwNRq6CnUNg PfH6thrXsIhN73JjV2ybT/c/iBzxM/n1mFoAq7SfsH5GUQ+3TYIXxJ4Hu4KiL7lG4Psc RqzA== X-Gm-Message-State: ALoCoQkGLgXY6OdcYOj4cTwjD3olAupb6r16EAytz4AWj/FjsA4FO3z1/3cpF7QpVdLgbQ6+TxeN X-Received: by 10.52.31.167 with SMTP id b7mr727817vdi.79.1398277126364; Wed, 23 Apr 2014 11:18:46 -0700 (PDT) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.58.234.68 with HTTP; Wed, 23 Apr 2014 11:18:16 -0700 (PDT) In-Reply-To: References: <53344FF8.7030204@gk2.sk> From: slush Date: Wed, 23 Apr 2014 20:18:16 +0200 X-Google-Sender-Auth: iJRVq1hye2gXIzkdLGJ5mroudK4 Message-ID: Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=bcaec51d27906a36ca04f7b9c386 X-Spam-Score: 2.2 (++) 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.2 MISSING_HEADERS Missing To: header 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Wd1ky-0005hp-2X 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 18:18:55 -0000 --bcaec51d27906a36ca04f7b9c386 Content-Type: text/plain; charset=ISO-8859-1 For those who don't follow github pull requests regularly; there's pull request for BIP64 defining HD wallet structure as discussed in this thread: https://github.com/bitcoin/bips/pull/52 On Wed, Apr 23, 2014 at 8:01 PM, slush wrote: > > > > On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille wrote: >> >> Storing the seed is superior to storing the master node already >> (whether coin specific or not), as it is smaller. >> >> > ...Except that you're loosing flexibility (serialization, deserialization) > which gives you BIP32 node. > > I see "bip32 seed" as some transitional, internal state from raw entropy > to bip32 master node and this seed should not be handled by the end user in > any form. In the oposite, well-serialized bip32 node (in xpriv, or even in > mnemonic format) can be used very widely and have no downsides against > using raw "bip32 seed". > > >> >> 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). >> >> > I also don't care too much about altcoins, but people want them so me, as > infrastructure developer, need to think about it. And I don't see any > reason for breaking compatibility between Bitcoin and other altcoins. I > would be happier if there will be another sentence than "Bitcoin seed", but > honestly, who cares. It is just some magic string for hashing the raw > seed... > > >> 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 truth is that even existing software which handle bip32 don't care > about 'version' at all. I think that "xpub/xprv" distinction is the only > useful feature of version, so user se if it stores public or private > information. > > But using prefixes which doesn't enforce anything is even more dangerous. > If somebody exports node "dogeblablabla", it creates false exceptations > that there's only dogecoin stored. > > Marek > --bcaec51d27906a36ca04f7b9c386 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For those who don't follow github pull requests regula= rly; there's pull request for BIP64 defining HD wallet structure as dis= cussed in this thread:




On Wed, Apr 23, 2014 at 8:01 PM, slush <= slush@centrum.cz&= gt; wrote:



On Wed, Apr 23, 2014= at 7:42 PM, Pieter Wuille <pieter.wuille@gmail.com> w= rote:
Storing the seed is superior to storing the master node already
(whether coin specific or not), as it is smaller.


...Except that you're loosin= g flexibility (serialization, deserialization) which gives you BIP32 node.<= /div>

I see "bip32 seed" as some transitional,= internal state from raw entropy to bip32 master node and this seed should = not be handled by the end user in any form. In the oposite, well-serialized= bip32 node (in xpriv, or even in mnemonic format) can be used very widely = and have no downsides against using raw "bip32 seed".
=A0

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).


I also don't care too much a= bout altcoins, but people want them so me, as infrastructure developer, nee= d to think about it. And I don't see any reason for breaking compatibil= ity between Bitcoin and other altcoins. I would be happier if there will be= another sentence than "Bitcoin seed", but honestly, who cares. I= t is just some magic string for hashing the raw seed...
=A0
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 truth is that even existing software= which handle bip32 don't care about 'version' at all. I think = that "xpub/xprv" distinction is the only useful feature of versio= n, so user se if it stores public or private information.

But using prefixes which doesn't enforce anything i= s even more dangerous. If somebody exports node "dogeblablabla", = it creates false exceptations that there's only dogecoin stored.

=A0Marek

--bcaec51d27906a36ca04f7b9c386--