From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd1VD-0006fP-TC for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 18:02:35 +0000 X-ACL-Warn: Received: from mail-ve0-f172.google.com ([209.85.128.172]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd1VC-00072C-JL for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 18:02:35 +0000 Received: by mail-ve0-f172.google.com with SMTP id jx11so1577351veb.17 for ; Wed, 23 Apr 2014 11:02:29 -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=O7i+8unB/l02+QWCtiLyUneOptEk3r5yIMuOwbyLkxg=; b=ZFS4tZUjYEBnQVAGfR475ohtWIEA2gjcy8HxM6deNA/vcnqLW/NH06gBN3zbEnXrxJ 5YI9+pqaELTAsOL+hTvbdkn3N2+rAzDvxH6CXCmca+jsa7IeAbktNAxXwXkU/SsXJPZC Z/rZnhcc0hczCe0I521LcQRzUCaTji2ssdRiW9wVbdS7x7QeMrL9XXOZMP8ZNiw9M5nI e5rpQZVXuyw0uRacTx+byvyq0Yow3oSBoxmEjCKLxFSTL+prWmS/frm1okPLXvSW763O 4h7HPtiRdNK38imGmJxwwZmy6TtY0K0MW32fwIqGStPsDx8+Ek0ybwMS4djEQvYN1Hnl /hNg== X-Gm-Message-State: ALoCoQmzLLW+ACIfhxRGiCbznjWgCe1G0vDxVLpSqwzXBryYQ1uCOW2b23n/UYgStDcbSMd13Tpg X-Received: by 10.58.202.106 with SMTP id kh10mr1853997vec.31.1398276149039; Wed, 23 Apr 2014 11:02:29 -0700 (PDT) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.58.234.68 with HTTP; Wed, 23 Apr 2014 11:01:57 -0700 (PDT) In-Reply-To: References: <53344FF8.7030204@gk2.sk> From: slush Date: Wed, 23 Apr 2014 20:01:57 +0200 X-Google-Sender-Auth: QqTlN99eBA3IOpXxR9BrAUyKue8 Message-ID: To: Pieter Wuille Content-Type: multipart/alternative; boundary=047d7bdc945e296a3604f7b9894e 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: 1Wd1VC-00072C-JL 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 18:02:36 -0000 --047d7bdc945e296a3604f7b9894e Content-Type: text/plain; charset=ISO-8859-1 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 --047d7bdc945e296a3604f7b9894e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille &l= t;pieter.wuill= e@gmail.com> 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 flex= ibility (serialization, deserialization) which gives you BIP32 node.
<= div>
I see "bip32 seed" as some transitional, inter= nal 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 ha= ve 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 about a= ltcoins, but people want them so me, as infrastructure developer, need to t= hink about it. And I don't see any reason for breaking compatibility be= tween Bitcoin and other altcoins. I would be happier if there will be anoth= er sentence than "Bitcoin seed", but honestly, who cares. It is j= ust 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 &= quot;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 i= s even more dangerous. If somebody exports node "dogeblablabla", = it creates false exceptations that there's only dogecoin stored.

=A0Marek
--047d7bdc945e296a3604f7b9894e--