Support generating more keys from the same mnemonic

[CarlBeek]

If a validator has already created a few keys & deposits, it would be useful to allow them to create more from the same mnemonic. The footgun risk is very high here as if users use the same keys twice, they will "top up" their existing validators.

One option is to require users to show their existing keystores before they are allowed to create more deposits.

I am very nervous about enabling this functionality if we can't come up with a clever way of not double depositing.

Related to #27

[hwwhww]

What do you think about adding partial pubkey to the keystore and deposit data file names? It may help the users to distinguish the files better.

[JordanCason]

I was talking with Hsiao-Wei and was asked if I could create an issue, However, I believe between this issue #29 and issue #27 would cover my use case with a little tweaking.

I've been looking around for a way to produce the public key from my mnemonic + password that I use for my ledger. This would be done on an air-gapped box. This way when ledger finally implements BLS12-381 key generation my withdraw address should be at index 0. It would be nice if users had a function to produce their public key this way to use as the withdraw address for validators without having to create the wallet.

I will also be running validators for some friends and family and do not wish to be the custodian of there funds. With the above functionality, I could have them create their withdrawal address so that I can create the validator data for them to sign. I think this could be useful for anyone validating for family.

Lastly with the functionality implemented from this issue a user could keep there own separate validator mnemonic + password so that they could continue to add validators over time. I was already planning on keeping track of what validators were created at what index but a possible built-in solution that could be used is to just require the existence of a config file with a validator index count. If the config does not exist than issue a warning about the functionality and precautions that should be takin.

[protolambda]

Is someone looking into this? Wouldn't it be enough to create a command that:

• takes a mnemonic
• takes an account range: start-end
• takes (requires!) the pubkey of the last account, i.e. at start-1 (unless start == 0), to be explicit about where you are generating accounts after. Or something like that
• the current options, like mnemonic language
• outputs keystores like it would as normal

Re-generating keystores is super important, as you would want to use that whenever you delete/remove/lose the keystore. The mnemonic, without ability to do anything with it, is kind of useless. Unless you start importing it into other tooling, which would be dangerous if it's any random tooling from the internet a user searches for while in panic to recover keys.

[gasolin]

FYR prysm provide the recovery from mnemonic feature https://docs.prylabs.network/docs/wallet/deterministic/#wallet-recovery ,
other clients might also provide that.
But still nice to have this feature in eth2.0-deposit-cli

[rafafaf29]

Hello,
I second the possibility of regenerating private keys from mnemonic seeds (as in #80), so we can manage it offline, outside of any validator.
Effectively, we can use the whole mnemonic inside Prysm, and it will generate the same keys, but it's not the keys themselves that are saved on-disk, but the encrypted seed. So it includes every validating key derived from this seed, but also every withdrawal key ! I find it quite dangerous to expose it as a whole on an online computer, as we never know how and when the validator will be hacked.

eth2-deposit-cli permits generating keys separately, and offline, and use it as differents files, so we can put only the relevant validating key on our online validator. But it's possible only on newly created seed (AFAIK), so if you didn't save these files correctly on your first run, you're screwed.
I understand distracted people can do some mistake, using the same key on several validators, so maybe it's a good thing to put a very strong warning when doing so, but i think it's a worse solution to not be able to do so at all.
I would be glad to do some testing and/or documentation if it can help (sadly i'm not a programmer at all, just a curious sysadmin...)

[torfbolt]

I have a branch where reusing a mnemonic is implemented:
https://github.com/torfbolt/eth2.0-deposit-cli

Please note that this is definitely not a polished solution, and doesn't fulfill all the points discussed here. But it might be a starting point.

EDIT: just saw that there's already #123 so my code is probably outdated.

[emansipater]

I'm strongly in support of this feature and would consider it much more than just a "nice to have" (specifically the ability to regenerate the original keys from the mnemonic as in #80 but that issue is marked as a duplicate of this one) . Any person being at all careful for mainnet launch is going to want to test their recovery from their mnemonic before making actual deposits, and they will already have to have loaded eth2deposit-cli onto their secure machine to generate in the first place. Making it an additional scary sounding flag and dumping a giant all-caps warning to the console is sufficient to caution against double validating or double depositing, especially if the launchpad can be convinced to add detection of previous deposits.

[hwwhww]

closing in favor of #123