{"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:53 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003ewrote:\n\n\u003e I see the cause of our disagreement now.\n\u003e\n\u003e You actually want to share a single BIP32 tree across different\n\u003e currency types, but do it in a way that guarantees that they never use\n\u003e the same keys.\n\u003e\n\u003e I would have expected that different chains would use independent\n\u003e chains, and have serializations encode which chain they belong to.\n\u003e\n\u003e Let me offer an alternative suggestion, which is compatible with the\n\u003e original default BIP32 structure:\n\u003e * You can use one seed across different chains, but the master nodes\n\u003e are separate.\n\u003e * To derive the master node from the seed, the key string \"Bitcoin\n\u003e seed\" is replaced by something chain-specific.\n\u003e\n\nI've discussed the solution of \"Litecoin seed\" in BIP32 HMAC with Litecoin\ndevs already, and after long discussion we've concluded that it is\ngenerally bad idea.\n\nWhen changing \"Bitcoin seed\" constant to something different, same\n*entropy* will produce different *master node*. That's actually the\nopposite what's requested, because xprv serialization format stores *node*,\nnot *entropy*. By changing HMAC constant, you still won't be able to store\none node and derive wallets for multiple coins at same time.\n\n\n\n\u003e * Every encoded node (including master nodes) has a chain-specific\n\u003e serialization magic.\n\u003e\nThis is in practice almost the same as your suggestion, except that\n\u003e the m/cointype' in m/cointype'/account'/change/n is replaced by\n\u003e different masters. The only disadvantage I see is that you do not have\n\u003e a way to encode the \"super master\" that is the parent of all\n\u003e chain-specific masters. You can - and with the same security\n\u003e properties - encode the seed, though.\n\u003e\n\u003e\nActually I don't understand why there's such disagreement about \"cointype\"\nlevel here, what it breaks? I see it as the cleanest solution so far. It is\nforward and backward compatible, does need any special extension to bip32\n(to be strict, bip32 says \"Bitcoin seed\", so client using \"Litecoin seed\"\ncannot be \"bip32 compatible\").\n\nOf course, the problem of \"cointype\" can be solved in zillion ways, but\nstill using cointype in bip32 path seem to be the most elegant way so far,\nbecause it fullfill all requirements for single backup, for separating\npubkeys and for handling all coins by one master...\n\nMarek\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/5da80ea7/attachment.html\u003e"}