{"type":"rich","version":"1.0","author_name":"npub1ad7209g90jnu400x74quws0xv8gpxs2fxnjexnpwqnrxwa39exdq5gl2p6","author_url":"https://nostr.ae/npub1ad7209g90jnu400x74quws0xv8gpxs2fxnjexnpwqnrxwa39exdq5gl2p6","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-08\n📝 Original message:On Tue, Apr 8, 2014 at 3:18 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003ewrote:\n\n\u003e I still don't understand the purpose of cointype. If you don't want to\n\u003e risk reusing the same keys across different currencies, just don't use\n\u003e the same seed or the same account? That is purely a client-side issue.\n\u003e\n\u003e\nOf course it is purely client-side issue, but it matters.\n\nThere's actually no reason to generate, backup and store individual seeds\nfor various coins and purposes. User can handle all his identities and\naltcoins with single seed, avoiding potential issues with using wrong seed\nfor other purposes.\n\nActually with accounts and cointypes in the path, you can have all your\ncrypto funds stored on single seed, which I see as very comfortable\nsolution.\n\nBut to gain advantages of such solution and avoid reusing the same path\nacross blockchains, we need to separate the space, which is achieved by\ncointype.\n\n\n\u003e If the consensus is to add the cointype anyway, can we fix it to be\n\u003e equal to the 4-byte magic in the serialization (after setting the high\n\u003e bit to true)? That way there aren't two 4-byte magic codes that need\n\u003e to be defined for each, and at the same time make it obvious from the\n\u003e serialized form what it is for.\n\u003e\n\u003e\nSerialization magic of bip32 seed is in my opinion completely unnecessary.\nMost of software does not care about it anyway; You can use xprv/xpub pair\nfor main net, testnet, litecoin, dogecoin, whatevercoin.\n\nInstead using the same seed (xprv) and then separate the chains *inside*\nthe bip32 path seems more useful to me.\n\nMarek\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/1e5227bc/attachment.html\u003e"}