Fix typos

mining/coordinated-mining.md

@@ -14,7 +14,7 @@ It is important that *only* the exit node broadcast solutions from your CM clust
 
 ## CM Basics
 
-All nodes in the cluster share the same mining address and packing format (e.g. all nodes use `spora_2_6` packing or `composite` packing with the same packing difficulty). Each Miner generates H1 hashes for the partitions they store. Occasionally they will need an H2 for a packed partition they don't store. In this case, they can find another miner in the coordinated mining cluster who does store the required partition packed with the required address, send them the H1 and ask them to calculate the H2. When a valid solution is found (either one- or two-chunk) the solution is sent to the Exit Node. Since the Exit Node is the sole node in the coordinated mining cluster which publishes blocks, there's no risk of "double signing" causing you address to be banned and your pending rewards slashed. Every node in the coordinated mining cluster will still peer with any other nodes on the network as normal.
+All nodes in the cluster share the same mining address and packing format (e.g. all nodes use `spora_2_6` packing or `composite` packing with the same packing difficulty). Each Miner generates H1 hashes for the partitions they store. Occasionally they will need an H2 for a packed partition they don't store. In this case, they can find another miner in the coordinated mining cluster who does store the required partition packed with the required address, send them the H1 and ask them to calculate the H2. When a valid solution is found (either one- or two-chunk) the solution is sent to the Exit Node. Since the Exit Node is the sole node in the coordinated mining cluster which publishes blocks, there's no risk of "double signing" causing your address to be banned and your pending rewards slashed. Every node in the coordinated mining cluster will still peer with any other nodes on the network as normal.
 
 ## VDF Forwarding
 
@@ -27,8 +27,8 @@ On the client servers, you would use the `vdf_server_trusted_peer <Exit Node IP>
 
 - `coordinated_mining`:  Enables coordinated mining mode
 - `local_peer IP:Port`: Registers a node as a local peer which disables rate limiting
-  - While this is not specifically a CM command, it corrects an edge case which may cause rate limiting between CM cluster membe. This is useful for all nodes you operate
-- `cm_peer IP:Port`:  Registers a node as a CM peer and allow sharing H1 and H2 hashes between them
+  - While this is not specifically a CM command, it corrects an edge case which may cause rate limiting between CM cluster members. This is useful for all nodes you operate
+- `cm_peer IP:Port`:  Registers a node as a CM peer and allows sharing H1 and H2 hashes between them
   - Each peer will have to include this flag for each other node in the cluster
 - `cm_api_secret your_secret_12_char_string`: This is the password for your CM cluster, each node must have the same password
 - `cm_exit_peer IP:Port`: This flag must be included on all nodes except for the exit peer

mining/examples.md

@@ -11,7 +11,7 @@ description: >-
 - Your mining address is **not** a private key - it is a public address
 - When mining, only nodes that will sign blocks need to have a private key / wallet.json stored locally
 - If your node will be part of a coordinated mining cluster (and is not the exit node) or is mining as part of a pool, it will never need your private key stored locally
-- For the following examples we will alway use `En2eqsVJARnTVOSh723PBXAKGmKgrGSjQ2YIGwE_ZRI` and `Q5EfKawrRazp11HEDf_NJpxjYMV385j21nlQNjR8_pY` as mining addresses. **Replace them with your own address(es) before running the sample commands.**
+- For the following examples we will always use `En2eqsVJARnTVOSh723PBXAKGmKgrGSjQ2YIGwE_ZRI` and `Q5EfKawrRazp11HEDf_NJpxjYMV385j21nlQNjR8_pY` as mining addresses. **Replace them with your own address(es) before running the sample commands.**
 {% endhint %}
 
 ## Syncing and Packing
@@ -104,7 +104,7 @@ description: >-
 ### Situation
 - You've downloaded 4 partitions of unpacked data
 - You want to pack it so you can mine against it
-- You've downloaded the unpacked partitiona to an 18TB disk
+- You've downloaded the unpacked partition to an 18TB disk
 - You'll pack the data to 4TB disks using the mining address `En2eqsVJARnTVOSh723PBXAKGmKgrGSjQ2YIGwE_ZRI`
 - You'll use the `composite` packing format with a packing difficulty of `1`
 - **NOTE** It's best **not** to mine while you pack. The two processes are both resource intensive and will slow each other down. (i.e. omit the `mine` flag from your configuration)
@@ -337,4 +337,4 @@ mv /opt/data/storage_modules/storage_module_3_En2eqsVJARnTVOSh723PBXAKGmKgrGSjQ2
     ]
 }
 ```
-</details>
+</details>

mining/faqs.md

@@ -74,7 +74,7 @@ a static IP. However your miner will continue to poll, so the lag will be minima
 A slightly bigger issue is your "peer reputation". All peers in the network maintain a rating
 for all other peers based on past activity. It basically boils down to the amount of valid
 data exchanged. As your node sends valid data to peers, your reputation increases. Reputation
-is currently tracked by IP:PORT, so whenever your IP changes, your repuation will be reset.
+is currently tracked by IP:PORT, so whenever your IP changes, your reputation will be reset.
 
 Reputation primarily comes into play when you mine a solution, Peers will process the solutions
 of higher reputation peers first. So if you have a low reputation and mine a block at about
@@ -91,7 +91,7 @@ No, Arweave uses Randomx for packing and mining. RandomX is an ASIC and GPU resi
 
 ### What’s the best hard drive to use?
 
-Any enterprise level hard drive that can sustain the read rates required for your configuration. See [this table](mining-guide.md#Preparation-Packing-Format) for the read speeds required per partition of packed data. Storing more partitionson a single disk will require a higher sustained read rate.In general an SSD will not be cost effective.
+Any enterprise level hard drive that can sustain the read rates required for your configuration. See [this table](mining-guide.md#Preparation-Packing-Format) for the read speeds required per partition of packed data. Storing more partitions on a single disk will require a higher sustained read rate.In general an SSD will not be cost effective.
 
 See the [Hardware Guide](hardware.md) and the [Quickstart Guide](mining-quickstart.md) for more information.
 
@@ -103,7 +103,7 @@ Not at this time, but some contain more data than others, so if you have a limit
 
 As of Arweave 2.8 there are two main packing formats available, `spora_2_6` and `composite`. The `composite` format is further specified by a packing difficulty. See the [Packing Format](mining-guide.md#Preparation-Packing-Format) section of the Mining Guide for more information.
 
-All packing formats provide the same maximum hashrate. A miner who has packed a full replica to `spora_2_6` will have the same hashrate as a miner who has packed a full replica to `composite.1` or `composite.32` - provided both miners are able to read the packed data and peform all hashes at the required rate.
+All packing formats provide the same maximum hashrate. A miner who has packed a full replica to `spora_2_6` will have the same hashrate as a miner who has packed a full replica to `composite.1` or `composite.32` - provided both miners are able to read the packed data and perform all hashes at the required rate.
 
 `spora_2_6` is deprecated and will stop being usable toward the end of 2028. For all new packs we recommend using the `composite` format. The lower read rates that a `composite` packing allows will reduce the hardware resources used during mining (larger disks, lower disk read rate, lower CPU and RAM utilization).
 
@@ -127,7 +127,7 @@ You can also (and should), set up Grafana and Prometheus to give you a very nice
 
 ### What should my VDF speed be?
 
-It should be as low as possible. The network targets an average VDF speed of 1 second and you wnat to be as close to that as possible (or lower).
+It should be as low as possible. The network targets an average VDF speed of 1 second and you want to be as close to that as possible (or lower).
 
 See the [VDF Guide](vdf.md) for more information.
 

mining/hardware.md

@@ -192,7 +192,7 @@ interpret this number. Some points to keep in mind:
 - Each chunk is **256 KiB**
 
 For example, if the `benchmark-packing` tool reports **100 chunks per second** for your CPU,
-you can expect you node to sync at an **upper bound speed of 12.5 to 25 MiB/s.**
+you can expect your node to sync at an **upper bound speed of 12.5 to 25 MiB/s.**
 
 ## Hashing
 
@@ -215,7 +215,7 @@ For the following examples, please keep in mind that with all the benchmarks, th
 computations should be taken as guides. In practice your hashing speed will be impacted by a
 number of factors not captured by the benchmark (e.g. contention with other processes running,
 impact of hyperthreading/SMT, etc...). Also you should budget your CPU capacity to exceed these
-calculations in order to accomodate all the other work your miner is doing (both within the
+calculations in order to accommodate all the other work your miner is doing (both within the
 Arweave node and at the system level).
 
 ### Example 1

mining/metrics.md

@@ -61,12 +61,12 @@ You may want to establish a baseline and set an alert if read rate falls some am
 
 **Metric**: `mining_rate{type="hash"}`
 
-This metric tracks the miner hashrate. The protocol allows for up to 400 H1 hashes and 400 H2 hashes per partition per VDF step. The metric also consider that an H1 hash is 100x less likely to result in a solution and scales the H1 hash count down accordingly. You can roughly interpret that as the protocol allowing 404 solution attempts (combination of H1 and H2 hashes) per partition per VDF step.
+This metric tracks the miner hashrate. The protocol allows for up to 400 H1 hashes and 400 H2 hashes per partition per VDF step. The metric also considers that an H1 hash is 100x less likely to result in a solution and scales the H1 hash count down accordingly. You can roughly interpret that as the protocol allowing 404 solution attempts (combination of H1 and H2 hashes) per partition per VDF step.
 
 Note: hashes are generated after chunks are read, so if your Read Rate chart shows a low read rate, your Hash Rate chart will also be lower.
 
 **Alerting**:
-Re recommend setting an alert on 0 as that indicates your miner is no longer mining. You may also want to establish a baseline and set an alert if hashrate falls some amount below that baseline
+We recommend setting an alert on 0 as that indicates your miner is no longer mining. You may also want to establish a baseline and set an alert if hashrate falls some amount below that baseline
 
 ## Hash Rate vs. Ideal
 
@@ -124,7 +124,7 @@ We recommend setting an alert at 200, and adjusting as needed.
 
 **Metric**: `http_client_get_chunk_duration_seconds_count`
 
-This metric tracks the the number of `GET /chunk2` requests that your node makes to peers.
+This metric tracks the number of `GET /chunk2` requests that your node makes to peers.
 This is the primary method through which a node syncs chunks during the Syncing and Packing
 phase.
 
@@ -140,7 +140,7 @@ This panel tracks the average latency of `GET /chunk2` requests to peers.
 
 **Debugging**: If you believe your sync rate is too slow, consulting this graph might explain
 why. The node should detect and adjust to high latencies by selecting different peers. But it
-can take some time to find new peers - during this period syncin/packing rate may dip.
+can take some time to find new peers - during this period syncing/packing rate may dip.
 
 ## Total Chunks Written
 
@@ -214,13 +214,13 @@ tracks how many of those chunks are currently cached. The cache has a size limit
 is printed periodically by your node (to the console and to the logs), and can be set
 using the `mining_server_chunk_cache_size_limit` launch parameter.
 
-**Debugging**: If your chunk cache size is sonsistently at or above the limit, your miner
-is not able to keep up with its optimal mining rate. This can be for a number of reason,
+**Debugging**: If your chunk cache size is consistently at or above the limit, your miner
+is not able to keep up with its optimal mining rate. This can be for a number of reasons,
 however one thing you can try is increasing the `mining_server_chunk_cache_size_limit`. If
 your miner is only temporarily falling behind (e.g. due to other processes running and
 stealing CPU or disk bandwidth), an increased cache can allow your miner to "catch up".
 
-Note: increaseing the cache size limit may increase your node's memory usage which can
+Note: increasing the cache size limit may increase your node's memory usage which can
 negatively impact performance if you are running near your system's memory limit.
 
 ## HTTP Requests Debug Metrics
@@ -237,7 +237,7 @@ request per type.
 
 **Debugging**: These charts can help you identify activity that could be impacting your
 performance (e.g. mining, syncing, packing). For example a spike in `POST /tx2` or `GET /tx`
-might correspond to a period of high Arweave nework activity. Or a high total latency servicing
+might correspond to a period of high Arweave network activity. Or a high total latency servicing
 `GET /chunk2` might indicate that your node is serving a lot of chunks to peers. Depending
 on the type of activity and how strongly it is impacting your node performance, you can
 take different actions.
@@ -296,4 +296,4 @@ it can process.
 **Metric**: `process_info{type="reductions"}`
 
 This panel tracks Erlang reductions. Reductions are a measure of Eerlang process activity. 
-the more reductions performed by a process, the more CPU cycles it has consumed.
+the more reductions performed by a process, the more CPU cycles it has consumed.