Apply suggestions from code review

Co-authored-by: chonghe <[email protected]>

book/src/validator-manager-create.md

@@ -41,16 +41,18 @@ Create validators from a mnemonic with:
 lighthouse \
     validator-manager \
     create \
+    --network mainnet \
     --first-index 0 \
     --count 2 \
     --eth1-withdrawal-address <ADDRESS> \
     --suggested-fee-recipient <ADDRESS> \
     --output-path ./
 ```
-
+> If the flag `--first-index` is not provided, it will default to using index 0.
 > The `--suggested-fee-recipient` flag may be omitted to use whatever default
-> value the VC uses. It does not necessarily need to be idential to
+> value the VC uses. It does not necessarily need to be identical to
 > `--eth1-withdrawal-address`.
+> The command will create the `deposits.json` and `validators.json` in the present working directory. If you would like these files to be created in a different directory, change the value of `output-path`, for example `--output-path /desired/directory`. The directory will be created if the path does not exist.
 
 Then, import the validators to a running VC with:
 
@@ -61,7 +63,7 @@ lighthouse \
     --validators-file validators.json \
     --vc-token <API-TOKEN-PATH>
 ```
-
+> This is assuming that `validators.json` is in the present working directory. If it is not, insert the directory of the file.
 > Be sure to remove `./validators.json` after the import is successful since it
 > contains unencrypted validator keystores.
 
@@ -75,9 +77,9 @@ host. This would help protect the mnemonic from being exposed to the Internet.
 
 ### 1. Create the Validators
 
-Run the `create` command, subsituting `<ADDRESS>` for an execution address that
+Run the `create` command, substituting `<ADDRESS>` for an execution address that
 you control. This is where all the staked ETH and rewards will ultimately
-reside, so it's very important that this address is secure, acessible and
+reside, so it's very important that this address is secure, accessible and
 backed-up. The `create` command:
 
 ```bash
@@ -143,7 +145,7 @@ In order to import the validators, the location of the VC `api-token.txt` file
 must be known. The location of the file varies, but it is located in the
 "validator directory" of your data directory. For example:
 `~/.lighthouse/mainnet/validators/api-token.txt`. We will use `<API-TOKEN-PATH>`
-to subsitute this value.
+to subsitute this value. If you are unsure of the `api-token.txt` path, you can run `curl http://localhost:5062/lighthouse/auth` which will show the path.
 
 
 Once the VC is running, use the `import` command to import the validators to the VC:
@@ -170,6 +172,6 @@ The user should now *securely* delete the `validators.json` file (e.g., `shred -
 The `validators.json` contains the unencrypted validator keys and must not be
 shared with anyone.
 
-The validators will now go through 3-4 epochs of [doppelganger
+The validators will now go through 2-3 epochs of [doppelganger
 protection](./validator-doppelganger.md) and will automatically start performing
 their duties when they are deposited and activated. The guide is complete.

book/src/validator-manager-move.md

@@ -56,7 +56,7 @@ There will be two hosts in this example:
 - Host 1 (*"source host"*): Is running the `src-vc`.
 - Host 2 (*"destination host"*): Is running the `dest-vc`.
 
-The example will assume that all commands are run on Host 1. It also assumes
+The example assumes
 that Host 1 is able to SSH to Host 2.
 
 In reality, many host configurations are possible. For example:
@@ -66,7 +66,7 @@ In reality, many host configurations are possible. For example:
 
 ### 1. Configure the Source VC
 
-The source VC needs to have the following flags at a mininum:
+The source VC needs to have the following flags at a minimum:
 
 - `--http`
 - `--unencrypted-http-transport`
@@ -88,7 +88,7 @@ lighthouse \
 
 ### 2. Configure the Destination VC
 
-The destination VC needs to have the following flags at a mininum:
+The destination VC needs to have the following flags at a minimum:
 
 - `--http`
 - `--unencrypted-http-transport`
@@ -109,13 +109,13 @@ lighthouse \
 ```
 
 > The `--enable-doppelganger-protection` flag is not *strictly* required, however
-> it is recommended for an additional layer of safety. It will result in 3-4
+> it is recommended for an additional layer of safety. It will result in 2-3
 > epochs of downtime for the validator after it is moved, which is generally an
 > inconsequential cost in lost rewards or penalties.
 > 
 > Optionally, users can add the `--http-store-passwords-in-secrets-dir` flag if they'd like to have
 > the import validator keystore passwords stored in separate files rather than in the
-> `valdiator-definitions.yml` file. If you don't know what this means, you can safely omit the flag.
+> `validator-definitions.yml` file. If you don't know what this means, you can safely omit the flag.
 
 ### 3. Obtain the Source API Token
 
@@ -125,14 +125,14 @@ source host on its file-system.
 
 On the **source host**, find the location of the `api-token.txt` file and copy the contents. The
 location of the file varies, but it is located in the "validator directory" of your data directory,
-alongside validator keystores. For example: `~/.lighthouse/mainnet/validators/api-token.txt`.
+alongside validator keystores. For example: `~/.lighthouse/mainnet/validators/api-token.txt`. If you are unsure of the `api-token.txt` path, you can run `curl http://localhost:5062/lighthouse/auth` which will show the path.
 
 Copy the contents of that file into a new file on the **destination host** at `~/src-token.txt`. The
 API token should be similar to `api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123`.
 
 ### 4. Create an SSH Tunnel
 
-In one terminal window, SSH to the **destination host** and establish a reverse-SSH connection
+In the **source host**, open a terminal window, SSH to the **destination host** and establish a reverse-SSH connection
 between the **desination host** and the **source host**.
 
 ```bash
@@ -173,9 +173,9 @@ Done.
 
 Once the operation completes successfully, there is nothing else to be done. The
 validators have been removed from the `src-host` and enabled at the `dest-host`.
-If the `--enable-doppelganger-protection` flag was used it may take 3-4 epochs
+If the `--enable-doppelganger-protection` flag was used it may take 2-3 epochs
 for the validators to start attesting and producing blocks on the `dest-host`.
 
-Any errors encounted during the operation should include information on how to
+Any errors encountered during the operation should include information on how to
 proceed. Assistance is also available on our
 [Discord](https://discord.gg/cyAszAh).

book/src/validator-manager.md

@@ -13,7 +13,7 @@ supported by this command.
 
 The validator manager tool is similar to the `lighthouse account-manager` tool,
 except the latter creates files that will be read by the VC next time it starts
-whilst the former makers instant changes to a live VC.
+whilst the former makes instant changes to a live VC.
 
 The `account-manager` is ideal for importing keys created with the
 [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli). On the