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"
}