More merge doc updates (#3509)

## Proposed Changes

Address a few shortcomings of the book noticed by users:

- Remove description of redundant execution nodes
- Use an Infura eth1 node rather than an eth2 node in the merge migration example
- Add an example of the fee recipient address format (we support addresses without the 0x prefix, but 0x prefixed feels more canonical).
- Clarify that Windows support is no longer beta
- Add a link to the MSRV to the build-from-source instructions

book/src/installation-binaries.md

@@ -4,8 +4,6 @@ Each Lighthouse release contains several downloadable binaries in the "Assets"
 section of the release. You can find the [releases
 on Github](https://github.com/sigp/lighthouse/releases).
 
-> Note: binaries are provided for Windows native, but Windows Lighthouse support is still in beta testing.
-
 ## Platforms
 
 Binaries are supplied for four platforms:
@@ -13,7 +11,7 @@ Binaries are supplied for four platforms:
 - `x86_64-unknown-linux-gnu`: AMD/Intel 64-bit processors (most desktops, laptops, servers)
 - `aarch64-unknown-linux-gnu`: 64-bit ARM processors (Raspberry Pi 4)
 - `x86_64-apple-darwin`: macOS with Intel chips
-- `x86_64-windows`: Windows with 64-bit processors (Beta)
+- `x86_64-windows`: Windows with 64-bit processors
 
 Additionally there is also a `-portable` suffix which indicates if the `portable` feature is used:
 

book/src/installation-source.md

@@ -52,10 +52,9 @@ choco install cmake --installargs 'ADD_CMAKE_TO_PATH=System'
 choco install llvm
 ```
 
-These dependencies are for compiling Lighthouse natively on Windows, which is currently in beta
+These dependencies are for compiling Lighthouse natively on Windows. Lighthouse can also run
-testing. Lighthouse can also run successfully under the [Windows Subsystem for Linux (WSL)][WSL].
+successfully under the [Windows Subsystem for Linux (WSL)][WSL]. If using Ubuntu under WSL, you
-If using Ubuntu under WSL, you should follow the instructions for Ubuntu listed in the [Dependencies
+should follow the instructions for Ubuntu listed in the [Dependencies (Ubuntu)](#ubuntu) section.
-(Ubuntu)](#ubuntu) section.
 
 [WSL]: https://docs.microsoft.com/en-us/windows/wsl/about
 
@@ -138,6 +137,10 @@ See ["Configuring the `PATH` environment variable"
 
 Make sure you are running the latest version of Rust. If you have installed Rust using rustup, simply type `rustup update`.
 
+If you can't install the latest version of Rust you can instead compile using the Minimum Supported
+Rust Version (MSRV) which is listed under the `rust-version` key in Lighthouse's
+[Cargo.toml](https://github.com/sigp/lighthouse/blob/stable/lighthouse/Cargo.toml).
+
 If compilation fails with `(signal: 9, SIGKILL: kill)`, this could mean your machine ran out of
 memory during compilation. If you are on a resource-constrained device you can
 look into [cross compilation](./cross-compiling.md), or use a [pre-built

book/src/installation.md

@@ -1,6 +1,6 @@
 # 📦 Installation
 
-Lighthouse runs on Linux, macOS, and Windows (still in beta testing).
+Lighthouse runs on Linux, macOS, and Windows.
 
 There are three core methods to obtain the Lighthouse application:
 
@@ -8,9 +8,11 @@ There are three core methods to obtain the Lighthouse application:
 - [Docker images](./docker.md).
 - [Building from source](./installation-source.md).
 
-The community maintains additional installation methods (currently only one).
+Community-maintained additional installation methods:
 
 - [Homebrew package](./homebrew.md).
+- Arch Linux AUR packages: [source](https://aur.archlinux.org/packages/lighthouse-ethereum),
+  [binary](https://aur.archlinux.org/packages/lighthouse-ethereum-bin).
 
 Additionally, there are two extra guides for specific uses:
 

book/src/merge-migration.md

@@ -11,11 +11,12 @@ There are two configuration changes required for a Lighthouse node to operate co
 the merge:
 
 1. You *must* run your own execution engine such as Geth or Nethermind alongside Lighthouse.
-   You *must* update your Lighthouse configuration to connect to the execution engine using new
+   You *must* update your `lighthouse bn` configuration to connect to the execution engine using new
    flags which are documented on this page in the
    [Connecting to an execution engine](#connecting-to-an-execution-engine) section.
 2. If your Lighthouse node has validators attached you *must* nominate an Ethereum address to
-   receive transactions tips from blocks proposed by your validators. This is covered on the
+   receive transactions tips from blocks proposed by your validators. These changes should
+   be made to your `lighthouse vc` configuration, and are covered on the
    [Suggested fee recipient](./suggested-fee-recipient.md) page.
 
 Additionally, you _must_ update Lighthouse to v3.0.0 (or later), and must update your execution
@@ -76,7 +77,7 @@ lighthouse \
     --network mainnet \
     beacon_node \
     --http \
-    --eth1-endpoints http://localhost:8545,https://TOKEN@eth2-beacon-mainnet.infura.io
+    --eth1-endpoints http://localhost:8545,https://mainnet.infura.io/v3/TOKEN
 ```
 
 Converting the above to a post-merge configuration would render:

book/src/redundancy.md

@@ -4,8 +4,8 @@
 
 There are three places in Lighthouse where redundancy is notable:
 
-1. ✅ GOOD: Using a redundant Beacon node in `lighthouse vc --beacon-nodes`
+1. ✅ GOOD: Using a redundant beacon node in `lighthouse vc --beacon-nodes`
-1. ✅ GOOD: Using a redundant execution node in `lighthouse bn --eth1-endpoints`
+1. ❌ NOT SUPPORTED: Using a redundant execution node in `lighthouse bn --execution-endpoint`
 1. ☠️ BAD: Running redundant `lighthouse vc` instances with overlapping keypairs.
 
 I mention (3) since it is unsafe and should not be confused with the other two
@@ -94,23 +94,10 @@ resource consumption akin to running 64+ validators.
 
 ## Redundant execution nodes
 
-Compared to redundancy in beacon nodes (see above), using redundant execution nodes
+Lighthouse previously supported redundant execution nodes for fetching data from the deposit
-is very straight-forward:
+contract. On merged networks _this is no longer supported_. Each Lighthouse beacon node must be
+configured in a 1:1 relationship with an execution node. For more information on the rationale
+behind this decision please see the [Merge Migration](./merge-migration.md) documentation.
 
-1. `lighthouse bn --eth1-endpoints http://localhost:8545`
+To achieve redundancy we recommend configuring [Redundant beacon nodes](#redundant-beacon-nodes)
-1. `lighthouse bn --eth1-endpoints http://localhost:8545,http://192.168.0.1:8545`
+where each has its own execution engine.
-
-In the case of (1), any failure on `http://localhost:8545` will result in a
-failure to update the execution client cache in the beacon node. Consistent failure over a
-period of hours may result in a failure in block production.
-
-However, in the case of (2), the `http://192.168.0.1:8545` execution client endpoint will
-be tried each time the first fails. Execution client endpoints will be tried from first to
-last in the list, until a successful response is obtained.
-
-There is no need for special configuration on the execution client endpoint, all endpoints can (probably should)
-be configured identically.
-
-> Note: When supplying multiple endpoints the `http://localhost:8545` address must be explicitly
-> provided (if it is desired). It will only be used as default if no `--eth1-endpoints` flag is
-> provided at all.

book/src/suggested-fee-recipient.md

@@ -65,11 +65,22 @@ Below is an example of the validator_definitions.yml with `suggested_fee_recipie
 The `--suggested-fee-recipient` can be provided to the VC to act as a default value for all
 validators where a `suggested_fee_recipient` is not loaded from another method.
 
+Provide a 0x-prefixed address, e.g.
+
+```
+lighthouse vc --suggested-fee-recipient 0x25c4a76E7d118705e7Ea2e9b7d8C59930d8aCD3b ...
+```
+
+
 ### 3. Using the "--suggested-fee-recipient" flag on the beacon node
 
 The `--suggested-fee-recipient` can be provided to the BN to act as a default value when the
 validator client does not transmit a `suggested_fee_recipient` to the BN.
 
+```
+lighthouse bn --suggested-fee-recipient 0x25c4a76E7d118705e7Ea2e9b7d8C59930d8aCD3b ...
+```
+
 **This value should be considered an emergency fallback**. You should set the fee recipient in the
 validator client in order for the execution node to be given adequate notice of block proposal.