Fully automated process.

[samoht9277]

The flag --non_interactive allows to disable confirmation to some inputs, but seedphrase and password are still required manual inputs, with no way to fully automate the process with a command.

Two new flags (or reading environment variables) to pass the seedphrase and the password would be helpful for advanced users who try to create the deposit data and the keystore automatically.

A security warning alongside the descriptions should say that this flags are dangerous.

[remyroy]

This is similar to #170. What is your use case for using this feature? Can you give us some details?

[samoht9277]

Thanks for the quick response!

I'm currently trying to fully automate the process of creating a new server, installing all necessary components, waiting for the node to finish syncing, use cast to create a new mnemonic, creating the deposit data and keystore automatically, import the keystore to my CL node, parse the deposit data and send the 32ETH with cast.

If there's a more optimal way to achieve this, lmk. I'm a DevOps and sort of new to all the Ethereum ecosystem.

[jybp]

Big +1 for this feature. --non_interactive is currently misleading / not working for example with new-mnemonic.

Something huge for automation would also be a --json flag that would output the result in json format. But that's beside this specific issue.

[remyroy]

There is some good work that could be done to improve this and #170 . I'm somewhat busy these days but if you want to work on something, we are happy to review and merge a PR related to this. Simply give us a quick overview of what you want to change or add and we'll tell if it make sense to start work on this. If not, we'll be working on this later.

[yorickdowne]

That --non-interactive still requires you to manually handle the mnemonic is tbh by design. It's a new mnemonic, we can't write it into a file!

If you want to automate key handling, you'd create a mnemonic your own way, then use existing-mnemonic

Even better is to use ethstaker-deposit-cli as a library, but somewhere between 0.1.2 and 1.2.0 we broke that. Looking to see where and how ...

[yorickdowne]

@jybp and @samoht9277 , I have thoughts on how this could be done. It may be better to have a discussion in ethstaker Discord, for faster back and forth.

The typical flow is:

• Create a mnemonic somehow
• Use existing-mnemonic either via CLI or as a module to make keys

That first part, "create a mnemonic somehow", could be changed to where new-mnemonic when run with a parameter we need to define, only spits out a mnemonic, doesn't verify the mnemonic, doesn't create keys. Basically --no-validator-keys, or whatever we call it. When --non-interactive, it'd do that without verification and without the "wipe clipboard and screen" steps we take.

That way you don't need another tool.

And, it'll always have to be "create mnemonic in some way step 1; use it to make validators step 2" when automating.

Yes, once we know what we want here, it's also possible to have it spit that out as --json

[jybp]

Happy to chat and understand what could be done sometime next week
jbkiln#8944

[yorickdowne]

Very cool. I’ll ping you in the discord. We don’t do DMs. The discord is at discord.gg/ethstaker

[CoeJoder]

It would be nice to have a true non-interactive for the existing-mnemonic command.
My use case:

Given a mnemonic seed and a list of validator pubkeys, perform a brute-force search for the respective EIP-2334 validator key indices

Reasons for use case:

1. generating additional validator keys which do not conflict with my existing list of validators (starting at highest_index+1)
2. providing the correct validator_start_index and validator_indices options to the generate-bls-to-execution-change command when the original keystores are not on-hand

Current workaround is to specify empty withdrawal address --withdrawal_address=''.

It would be better UX if the program exited with error code and message if required options are not provided when --non_interactive is provided.

[yorickdowne]

@CoeJoder That use case is well covered by ethdo - it runs through the entire space and creates change messages in one go.

“I don’t know how many of these validators are on this mnemonic” is an interesting use case.

[yorickdowne]

@jybp Ive sent a fren request. From there I’d like to move to public discussion on discord.gg/ethstaker - but if it’s easier to start on a DM to join that server, let’s.

I do want the discussion to be public.

[jybp]

@yorickdowne Accepted and joined discord server.

The typical flow is:
Create a mnemonic somehow
Use existing-mnemonic either via CLI or as a module to make keys
That first part, "create a mnemonic somehow", could be changed to where new-mnemonic when run with a parameter we need to define, only spits out a mnemonic, doesn't verify the mnemonic, doesn't create keys. Basically --no-validator-keys, or whatever we call it. When --non-interactive, it'd do that without verification and without the "wipe clipboard and screen" steps we take.

That way you don't need another tool.

And, it'll always have to be "create mnemonic in some way step 1; use it to make validators step 2" when automating.

Yes, once we know what we want here, it's also possible to have it spit that out as --json

I think that would work. At the end of the day the need just is:

1. new-mnemonic: Ability to programmatically interact with the CLI to:
   a. retrieve the generated mnemonic
   b. retrieve the output filenames for deposit_data+keystore.
2. existing-mnemonic: Ability to programmatically pass --mnemonic (flag already present) and parse the output filenames for deposit_data+keystore.

Today it's extremely tedious to automate, in part because parsing human outputs (ANSI escape codes) is not that trivial as well as automating stdin interactions. The ideal solution would be:

• --json to ease parsing.
• --non_interactive not expecting any stdin interactions.

I think we could force the --non_interactive usage/behaviour when --json is specified.

Ideally using both for new-mnemonic would only output:

{
    "mnemonic": "cherry cherry cherry cherry ...",
    "keystore": "./validator_keys/keystore-123.json",
    "deposit_data": "./validator_keys/deposit_data-123.json"
}

And for existing-mnemonic:

{
    "keystore": "./validator_keys/keystore-123.json",
    "deposit_data": "./validator_keys/deposit_data-123.json"
}

[remyroy]

We implemented a 2 steps fully automated workflow with the new generate-mnemonic command. There is no release yet but we'd like to get your feedback on it if you can run it from source. It's in the main branch.

[martin-braun]

@remyroy I'm calling:

deposit generate-mnemonic --mnemonic_language English

Instead of simply generating a mnemonic, it first prompts Please choose your language [1. العربية , 2. ελληνικά, 3. English... which can't be skipped via --non_interactive and then it even gives me this prompt (It also ignores --ignore_connectivity):

*** Internet connectivity detected ***

To mitigate the risk of unauthorized access and safeguard generated key material, it is strongly advised to run this tool in an offline, airgapped environment. Operating online increases susceptibility to poten
tial theft or compromise.

By continuing, you are accepting responsibility for the risk.

I also don't understand why we have the --output_file flag, please just print the mnemonic to STDOUT without any noise and from there we can just pipe it to a file, tee or whatever we desire. I want to retrieve the mnemonic from its your tool's STDOUT. Things like "This is your randomly generated mnemonic:" and "If you also want to generate your validator keystore and deposit files you can now use the existing-mnemonic command." are just unnecessary noise that should be put in the manual or piped to STDERR and not to STDOUT.

I understand that security is a concern, but this should not come at the expense of integration into scripting environments. I want to automate the full setup of a Ethereum node incl. setting up accounts, wallets and validators. I understand the risk. The accounts at the execution layer are very easy to automatically setup and this tool looks like the right one to generate BLS keys when setting up wallets and validators on the consensus layer side.

However, with these prompts all galore, I have to do very hacky POSIX shell gymnastics for now to just print the mnemonic:

printf '3\n\n' | deposit generate-mnemonic --mnemonic_language English | head -n4 | tail -n1

I hope you agree that should absolutely not be the state of the art. I hope you can take our concerns into consideration and make the tool better for everyone, including workflows that rely on it being fully automated. I didn't expect so many roadblocks in my scripting setup when trying to generate BLS keys with ethstaker-deposit-cli.

Thank you.

---

EDIT: The struggle goes on when going to the existing-mnemonic command where prompts like "Repeat your withdrawal address for confirmation.:" and "Please repeat the validator start index to confirm:" come along. Could we make it so that those confirmation flags can be turned off with a flag?

For real, this is a show stopper:

You see I can work around most of these prompts by piping stuff into STDIN, but it stops working for passwords:

printf '3\n'$vi'\n'$wa'\n'$pass'\n' | deposit existing-mnemonic \
  --mnemonic "$mnemonic" \
  --mnemonic_language English \
  --validator_start_index $vi \
  --withdrawal_address "$wa" \
  --keystore_password "$pass" \
  # more args

This tool is officially linked from https://github.com/ethereum/staking-deposit-cli, yet it asks for confirmations of already provided flags, not allowing and respecting global flags in all commands, etc. I understand that this is all free work potentially without funding and that nobody is stopping me from taking action and contributing to address those issues, but I just have to say that I came in with higher expectations, since it's an officially linked repository of the 2nd largest cryptocurrency in the world.

Please excuse my directness, this is just frustrating and I realize that I can't rely on this tool to get the job done.