BIP32
Ayms opened this issue · comments
Not sure what's the status of the discussion and if there is a consensus (#18 ?) but like probably others I prefer to master my keys instead of relying on the sw, and have some way to recover them in case something happens
So here it is: https://github.com/Ayms/zcash-wallets
Implementation of BIP32 for zcash, for now "z-addresses are derived from the hardened m/0/1 branch as defined in BIP32 with the first four bits of the private keys set to 0 for the spending keys", not sure that inventing something more complicate really adds some value, it depends on how people are using it, at their own risks
FYI and potential comments, you can close it
That's really neat! :)
I don't recommend anyone use this because it's not standardized and we'll be changing the address design in the future.
There is (currently) no way to perform non-hardened child derivation with our z-address design. As a result, adding a PRF surrounding tmp.privateKey might be wise, since it will ensure your spending keys are uniformly distributed.
As for the BIP32 path, may I suggest m/1893' as the base, as a reference to this Zcash issue number?
Perhaps we should move discussion of BIP32 to our zips repository instead.
That's really neat! :)
Thanks
I don't recommend anyone use this because it's not standardized and we'll be changing the address design in the future.
Yes, from my standpoint it's not designed to be trivially used with some 100 addresses generated and one wallet
As you understand the intent is to allow to generate Zcash addresses outside of zcash sw, which you will probably agree is not very intuitive for z-addresses, anyone with some little skills can modify the code and generate what he likes (so it's not so 'made simple' but still not difficult, will reference this post in the warning section) and this gives a means to recover them
And the module is supposed to adapt to design addresses changes
There is (currently) no way to perform non-hardened child derivation with our z-address design. As a result, adding a PRF surrounding tmp.privateKey might be wise, since it will ensure your spending keys are uniformly distributed.
Did not get very well the first sentence, zeroing the first 4 bits is maybe a little abrupt, what sequence would you suggest with PRF?
As for the BIP32 path, may I suggest m/1893' as the base, as a reference to this Zcash issue number?
Yes, cool idea :-) hope people won't think that's a historical reference :-)
Perhaps we should move discussion of BIP32 to our zips repository instead.
Not sure what "zips repository" stands for, probably not the place to discuss this here but still interesting to get some suggestions
FYI: In general, it's probably a bad idea to have so many (Zcash) spending keys unless you need to isolate spend authority of part of your funds. The more keys in your wallet, the slower it is to do anything with zcashd.
Since this is more of a discussion than an issue. I'd like to close it. ZIPs repo is here: https://github.com/zcash/zips Daira added a process for creating a ZIP which you can read through here: https://github.com/zcash/zips/tree/master/drafts/daira-zip-process
You can also discuss these topics on our forum (which could really benefit from having non-mining discussions IMO): https://forum.z.cash/
ZIP, BIP, BEP, ok got it
@ebfull spending keys were supposed to follow the general rule (ie reserve/label) but apparently this is not the case, still don't see how your PRF suggestion distributes better the keys
Closing it
Please see again bitcoin-wallets and zcash-wallets repos, I changed the derivation method, probably that's now closer from what @ebfull suggested and more aligned to Zcash methods, added the magic number 1893 (but still hardened even if useless since this is the default), commented z-addresses by default in wallet.txt, referenced this post