rich1.0npub1ad7209g90jnu400x74quws0xv8gpxs2fxnjexnpwqnrxwa39exdq5gl2p6https://nostr.ae/npub1ad7209g90jnu400x74quws0xv8gpxs2fxnjexnpwqnrxwa39exdq5gl2p6njumphttps://nostr.ae📅 Original date posted:2014-04-08 📝 Original message:On Tue, Apr 8, 2014 at 3:53 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote: > I see the cause of our disagreement now. > > You actually want to share a single BIP32 tree across different > currency types, but do it in a way that guarantees that they never use > the same keys. > > I would have expected that different chains would use independent > chains, and have serializations encode which chain they belong to. > > Let me offer an alternative suggestion, which is compatible with the > original default BIP32 structure: > * You can use one seed across different chains, but the master nodes > are separate. > * To derive the master node from the seed, the key string "Bitcoin > seed" is replaced by something chain-specific. > I've discussed the solution of "Litecoin seed" in BIP32 HMAC with Litecoin devs already, and after long discussion we've concluded that it is generally bad idea. When changing "Bitcoin seed" constant to something different, same *entropy* will produce different *master node*. That's actually the opposite what's requested, because xprv serialization format stores *node*, not *entropy*. By changing HMAC constant, you still won't be able to store one node and derive wallets for multiple coins at same time. > * Every encoded node (including master nodes) has a chain-specific > serialization magic. > This is in practice almost the same as your suggestion, except that > the m/cointype' in m/cointype'/account'/change/n is replaced by > different masters. The only disadvantage I see is that you do not have > a way to encode the "super master" that is the parent of all > chain-specific masters. You can - and with the same security > properties - encode the seed, though. > > Actually I don't understand why there's such disagreement about "cointype" level here, what it breaks? I see it as the cleanest solution so far. It is forward and backward compatible, does need any special extension to bip32 (to be strict, bip32 says "Bitcoin seed", so client using "Litecoin seed" cannot be "bip32 compatible"). Of course, the problem of "cointype" can be solved in zillion ways, but still using cointype in bip32 path seem to be the most elegant way so far, because it fullfill all requirements for single backup, for separating pubkeys and for handling all coins by one master... Marek -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/5da80ea7/attachment.html>