Merge pull request #1095 from omahs/patch-1

Fix typos

docs/core-concepts/behavior.md

@@ -24,8 +24,8 @@ There are some options for API clients to control the server outputs. Server out
 
 ## Replay of past server outputs
 
-When a `hydra-node` restarts, by default it will load it's history from persistence and replay previous server outputs to enable clients to re-establish their state upon re-connection. If that happens, obviously some of these outputs are not relevant anymore. One example of this is the `PeerConnected` and `PeerDisconnected`. To make it possible to determine the end of replayed history, client applications can use the `Greetings`, which will be emitted on every `hydra-node` start. See the `hydra-tui` example client for how this is handled.
+When a `hydra-node` restarts, by default it will load its history from persistence and replay previous server outputs to enable clients to re-establish their state upon re-connection. If that happens, obviously some of these outputs are not relevant anymore. One example of this is the `PeerConnected` and `PeerDisconnected`. To make it possible to determine the end of replayed history, client applications can use the `Greetings`, which will be emitted on every `hydra-node` start. See the `hydra-tui` example client for how this is handled.
 
 Clients can optionally decide to skip history outputs and receive only the `Greetings` and following ones. In order to do that they can use query param `history=no`.
 
-For example if the client wants to connect to a local `hydra-node` and doesn't want to view the server history but also want to have the transactions encoded as CBOR (base16) and prevent utxo display in `SnapshotConfirmed` messages, they would connect using default port `4001` and the full path `ws://localhost:4001/?history=no&tx-output=cbor`.
+For example if the client wants to connect to a local `hydra-node` and doesn't want to view the server history but also wants to have the transactions encoded as CBOR (base16) and prevent utxo display in `SnapshotConfirmed` messages, they would connect using default port `4001` and the full path `ws://localhost:4001/?history=no&tx-output=cbor`.

docs/core-concepts/faq/index.md

@@ -64,7 +64,7 @@ In principle, yes! The ledger used for L2 transactions is configurable and can u
 Let's look at two examples:
 
   1. `minUTxOValue = 0`: Outputs with no "ADA" in their value in the L2 would be disallowed on L1 -> this makes fanout not possible. Using partial fanout as also considered within [this feature](https://github.com/input-output-hk/hydra/issues/190) would only disallow fanout of affected UTxOs.
-  2. `maxTxExecutionUnits(L2) > maxTxExecutionUnits(L1)`: Outputs payed to scripts which are too expensive to validate on L1 -> will be fanned out, but become unspendable.
+  2. `maxTxExecutionUnits(L2) > maxTxExecutionUnits(L1)`: Outputs paid to scripts which are too expensive to validate on L1 -> will be fanned out, but become unspendable.
 
 With great power, comes great responsibility. 
 

docs/core-concepts/scalability.md

@@ -16,7 +16,7 @@ it's distributed globally between thousands of block-producing nodes (with quite
 a low bar in system requirements) will have it create a block on average every
 20 seconds.
 
-These limitations ultimately means that any state can only change in discrete
+These limitations ultimately mean that any state can only change in discrete
 steps of this duration. Besides, given peak hours on the blockchain when there
 is a transaction queue, the time required to settle and confirm a transaction
 might also be higher, further increasing the effective settlement time. This is

docs/docs/getting-started/operating-hydra.md

@@ -16,7 +16,7 @@ Following [ADR-9](/adr/9) design principles, the `hydra-node` provides [JSON](ht
 
 :::info
 
-There is an unpublished [log-filter](https://github.com/input-output-hk/hydra/blob/master/hydra-cluster/exe/log-filter/Main.hs) executable that one can attach to a hydra-node in order to trim down the volume of information in the log stream. This filter provides _some_ filtering features, namely removing transactions bodies and replacing them with transaction ids, but it's not general enough to warrant publication. Similar capabilites can be easily provided with tools like [jq](https://stedolan.github.io/jq/).
+There is an unpublished [log-filter](https://github.com/input-output-hk/hydra/blob/master/hydra-cluster/exe/log-filter/Main.hs) executable that one can attach to a hydra-node in order to trim down the volume of information in the log stream. This filter provides _some_ filtering features, namely removing transactions bodies and replacing them with transaction ids, but it's not general enough to warrant publication. Similar capabilities can be easily provided with tools like [jq](https://stedolan.github.io/jq/).
 
 :::
 

docs/docs/getting-started/quickstart.md

@@ -44,7 +44,7 @@ Available options:
   -q,--quiet               Turns off logging.
   -n,--node-id NODE-ID     The Hydra node identifier used on the Hydra network.
                            It is important to have a unique identifier in order
-                           to be able distinguish between connected peers.
+                           to be able to distinguish between connected peers.
   -h,--host IP             Listen address for incoming Hydra network
                            connections. (default: 127.0.0.1)
   -p,--port PORT           Listen port for incoming Hydra network connections.
@@ -151,7 +151,7 @@ From there, each participant is expected to share their verification key with ot
 
 ### Hydra keys
 
-The second set of keys are the so-called Hydra keys, which are used for multi-signing snapshots within a Head. While in the long-run, those keys will be key pairs used within MuSig2 aggregated multi-signature scheme. At present however, the aggregated multisig cryptography is [yet to be implemented](https://github.com/input-output-hk/hydra/issues/193) and the Hydra nodes are a naiive, but secure multi-signature scheme based on Ed25519 keys.
+The second set of keys are the so-called Hydra keys, which are used for multi-signing snapshots within a Head. While in the long-run, those keys will be key pairs used within MuSig2 aggregated multi-signature scheme. At present however, the aggregated multisig cryptography is [yet to be implemented](https://github.com/input-output-hk/hydra/issues/193) and the Hydra nodes are a naive, but secure multi-signature scheme based on Ed25519 keys.
 
 These are similar to cardano keys but are used only in the layer 2. We provide demo key pairs as `alice.{vk,sk}`, `bob.{vk,sk}` and `carol.{vk,sk}` in our [demo folder](https://github.com/input-output-hk/hydra/tree/master/demo).
 

docs/docs/known-issues.md

@@ -40,7 +40,7 @@ Head is open:
 - Using reference scripts on the L2 is non problematic as they will
   be committed back on the L1 along with all the other UTxO
 
-There are couple of items in the roadmap around reducing the risk of loosing funds in a Hydra Head:
+There are couple of items in the roadmap around reducing the risk of losing funds in a Hydra Head:
 
 - [Always abortable Head](https://github.com/input-output-hk/hydra/issues/699)
 - [Limit size/complexity of UTxOs in the Head](https://github.com/input-output-hk/hydra/issues/698)
@@ -76,7 +76,7 @@ implemented has the following consequences:
 
 ### hydra-tui
 
-- TUI crashes when user tries to post a new transaction wihout any UTXO remaining.
+- TUI crashes when user tries to post a new transaction without any UTXO remaining.
 
 - Recipient addresses to send money to in the TUI are inferred from
   the current UTXO set. If a party does not commit a UTXO or consumes

docs/monthly/2023-02-monthly.md

@@ -40,7 +40,7 @@ there are a few things that changed this month:
   technical specification. We expect a release in early March.
 
 - Version **0.10.0** will be the first mainnet compatible release. For this, we
-  created and groomed the main feature item [Mainnnet compatibility
+  created and groomed the main feature item [Mainnet compatibility
   #713](https://github.com/input-output-hk/hydra/issues/713):
   - Not only making it technically compatible but also adding guard rails to
     limit risk (“not shoot yourself in the foot .. with a real gun now”) and

hydra-node/src/Hydra/Options.hs

@@ -444,7 +444,7 @@ nodeIdParser =
         <> metavar "NODE-ID"
         <> help
           "The Hydra node identifier used on the Hydra network. It is \
-          \important to have a unique identifier in order to be able \
+          \important to have a unique identifier in order to be able to \
           \distinguish between connected peers."
     )