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 >