{"type":"rich","version":"1.0","author_name":"npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","author_url":"https://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-23\n📝 Original message:On Tue, Apr 8, 2014 at 5:41 PM, slush \u003cslush at centrum.cz\u003e wrote:\n\u003e I've discussed the solution of \"Litecoin seed\" in BIP32 HMAC with Litecoin\n\u003e devs already, and after long discussion we've concluded that it is generally\n\u003e bad idea.\n\u003e\n\u003e When changing \"Bitcoin seed\" constant to something different, same *entropy*\n\u003e will produce different *master node*. That's actually the opposite what's\n\u003e requested, because xprv serialization format stores *node*, not *entropy*.\n\u003e By changing HMAC constant, you still won't be able to store one node and\n\u003e derive wallets for multiple coins at same time.\n\nStoring the seed is superior to storing the master node already\n(whether coin specific or not), as it is smaller.\n\nAll this changes is making the seed the \"super master\" which allows\ngenerating the coin-specific masters (which get an actual useful\nfunction: revealing your entire-tree, but only one coin's subset of\nit).\n\n\u003e\u003e * Every encoded node (including master nodes) has a chain-specific\n\u003e\u003e serialization magic.\n\u003e\u003e\n\u003e\u003e This is in practice almost the same as your suggestion, except that\n\u003e\u003e the m/cointype' in m/cointype'/account'/change/n is replaced by\n\u003e\u003e different masters. The only disadvantage I see is that you do not have\n\u003e\u003e a way to encode the \"super master\" that is the parent of all\n\u003e\u003e chain-specific masters. You can - and with the same security\n\u003e\u003e properties - encode the seed, though.\n\u003e\u003e\n\u003e\n\u003e Actually I don't understand why there's such disagreement about \"cointype\"\n\u003e level here, what it breaks? I see it as the cleanest solution so far. It is\n\u003e forward and backward compatible, does need any special extension to bip32\n\u003e (to be strict, bip32 says \"Bitcoin seed\", so client using \"Litecoin seed\"\n\u003e cannot be \"bip32 compatible\").\n\nFair enough, it would break strictly BIP32. Then again, BIP32 is a\n*Bitcoin* improvement proposal, and not something that necessarily\napplies to other coins (they can adopt it of course, I don't care).\n\nWhat I dislike is that this removes the ability of using the magic in\nthe serialization to prevent importing a chain from the wrong coin.\nThe standard could just say that instead of \"Bitcoin seed\", you'd use\n\"Coin seed: \" + magic, so you don't need an extra mapping from\ncointype to seed strings.\n\n-- \nPieter"}