<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 8, 2014 at 3:18 PM, Pieter Wuille <span dir="ltr"><<a href="mailto:pieter.wuille@gmail.com" target="_blank">pieter.wuille@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I still don't understand the purpose of cointype. If you don't want to<br>
risk reusing the same keys across different currencies, just don't use<br>
the same seed or the same account? That is purely a client-side issue.<br>
<br></blockquote><div><br></div><div>Of course it is purely client-side issue, but it matters.</div><div><br></div><div>There's actually no reason to generate, backup and store individual seeds for various coins and purposes. User can handle all his identities and altcoins with single seed, avoiding potential issues with using wrong seed for other purposes.</div>
<div><br></div><div>Actually with accounts and cointypes in the path, you can have all your crypto funds stored on single seed, which I see as very comfortable solution.</div><div><br></div><div>But to gain advantages of such solution and avoid reusing the same path across blockchains, we need to separate the space, which is achieved by cointype.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the consensus is to add the cointype anyway, can we fix it to be<br>
equal to the 4-byte magic in the serialization (after setting the high<br>
bit to true)? That way there aren't two 4-byte magic codes that need<br>
to be defined for each, and at the same time make it obvious from the<br>
serialized form what it is for.<br>
<div><div class="h5"><br></div></div></blockquote><div><br></div><div>Serialization magic of bip32 seed is in my opinion completely unnecessary. Most of software does not care about it anyway; You can use xprv/xpub pair for main net, testnet, litecoin, dogecoin, whatevercoin.</div>
<div><br></div><div>Instead using the same seed (xprv) and then separate the chains *inside* the bip32 path seems more useful to me.</div><div><br></div><div>Marek </div></div></div></div>