-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HD wallet support #64
Comments
@pipermerriam what does it take to make your HD wallet python implementation production ready? We actually need this to implement this feature |
cc @kclowes |
PR which implemented it: Branch where it exists: https://github.com/ethereum/eth-account/tree/feat/hdaccount Code: https://github.com/ethereum/eth-account/blob/feat/hdaccount/eth_account/hdaccount.py I'd say to be production ready:
And even then, if we were to be using this to receive funds, I'd want to do a bunch of rigorous sanity checking that the addresses and private keys it generates properly match and don't result in unrecoverable funds. |
thanks for the input! 1 seems easy - 2 a bit harder but doable 3 even harder but doable background I am asking: we kind of need it for wave2 |
@ligi what is the timeline for wave2? |
Unfortunately I do not know. Got a very rough estimate of wave1+1month once - but I will try to get a more reliable timeline. |
I think it would be tight, but assuming we can get a security audit in time, I think it could be doable. I think it would be good to have the three of us hop on a call soon and figure out what are the most minimal features we need to get this working. |
yes - let's do a call soon. |
@ligi I think we may have come up with an approach that feels both safe and allows use of the HD wallet code.
I'm not necessarily pushing for this above #69 and #70 but rather posing a possible solution. Let us know if you like that and we can start working on it. |
Another option would be this: https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742/40 |
eth-account should be used @fubuloubu recently PRed HD wallets: ethereum/eth-account#88 |
Should we isolate the handling of the key from the plugin to improve security? |
if we are confident enough in the implementation we should be able to provide the server with only the public part of the key and let it derive the sub-keys. The offline address generation approach is also a totally fine low-tech approach to ensure security and funds availability and might actually be easier to implement so I'm only pointing out the "safe" way to do on-demand address generation on the server to highlight it as an option, not necessarily advocate for it as the right choice. |
As a side note, only private key derivation is currently implemented. It should be fairly easy to support public key derivation too, but that will require a bunch of test cases that I couldn't find. It should be easy enough to create our own test cases however, it's basically a triangular verification of the derived private keys (which we test against the official test vectors) create the given derived public keys (through doing secp256k1 derive). The biggest question in adding this feature is how the API might look like, which is the bigger reason I decided not to implement it in ethereum/eth-account#88 |
Thanks for the input @pipermerriam and @fubuloubu - how long do you think this change would take? |
I currently don't have a lot of time to implement it, but it wouldn't be too difficult. I could guide someone along if you wanted it sooner rather than later. Not my day job 😆 |
@fubuloubu thanks for the info! I think we will go with the list then for now ;-) |
FWIW I think public key derivation would be straightforward to implement. cc @marcgarreau as he's been working on this stuff too |
means one address per payment in via one HD wallet.
reasons:
The text was updated successfully, but these errors were encountered: