Add typos check (#2040)

Author: locallycompact

CHANGELOG.md

@@ -109,7 +109,7 @@ changes.
 - There is a new `--deposit-deadline` argument to hydra-node that determines the maximum time for the hydra-node to detect a deposit.
   After this time has passed users can recover a deposit in case it wasn't observed previously.
 
-- **BREAKING** hydra-node accepts multiple `hydra-scripts-tx-id` as a comma-seperated list, as the outcome of changes in the Hydra scripts publishing.
+- **BREAKING** hydra-node accepts multiple `hydra-scripts-tx-id` as a comma-separated list, as the outcome of changes in the Hydra scripts publishing.
 
 - Tested with `cardano-node 10.1.2` and `cardano-cli 10.1.1.0`.
 
@@ -162,7 +162,7 @@ changes.
 
 - Adds a manual recipient address entry to `hydra-tui` and fixes event handling. [#1607](https://github.com/cardano-scaling/hydra/pull/1607)
 
-- Add a demo mode to hydra-cluster to facilitate network resiliance tests [#1552](https://github.com/cardano-scaling/hydra/pull/1552)
+- Add a demo mode to hydra-cluster to facilitate network resilience tests [#1552](https://github.com/cardano-scaling/hydra/pull/1552)
 
 ## [0.18.1] - 2024-08-15
 
@@ -191,15 +191,15 @@ changes.
 
 - Change `--start-chain-from` to always use the newer point when also a head state is known. [#1471](https://github.com/cardano-scaling/hydra/pull/1471)
 
-- Moved several pages from "core concepts" into the user manual and developer docs to futher improve user journey. [#1486](https://github.com/cardano-scaling/hydra/pull/1486)
+- Moved several pages from "core concepts" into the user manual and developer docs to further improve user journey. [#1486](https://github.com/cardano-scaling/hydra/pull/1486)
 
 - Offline mode of `hydra-node` uses `--node-id` to derive an artificial offline `headId`. [#1551](https://github.com/cardano-scaling/hydra/pull/1551)
 
 ## [0.17.0] - 2024-05-20
 
 - **BREAKING** Change `hydra-node` API `/commit` endpoint for committing from scripts [#1380](https://github.com/cardano-scaling/hydra/pull/1380):
   - Instead of the custom `witness` extension of `UTxO`, the endpoint now accepts a _blueprint_ transaction together with the `UTxO` which is spent in this transaction.
-  - Usage is still the same for commiting "normal" `UTxO` owned by public key addresses.
+  - Usage is still the same for committing "normal" `UTxO` owned by public key addresses.
   - Spending from a script `UTxO` now needs the `blueprintTx` request type, which also unlocks more involved use-cases, where the commit transaction should also satisfy script spending constraints (like additional signers, validity ranges etc.)
 
 - _DEPRECATED_ the `GetUTxO` client input and `GetUTxOResponse` server output. Use `GET /snapshot/utxo` instead.
@@ -441,14 +441,14 @@ changes.
       spend multiple UTxOs into a Hydra head.
     - Removes the `MoreThanOneUTxOCommitted` server output on the API.
 
-- Suport commits from external wallets [#215](215)
+- Support commits from external wallets [#215](215)
     - Added the `/commit` HTTP endpoint to the `hydra-node` for creating a draft
       `commit` transaction to commit requested UTxO into a head. This
       transaction can be signed and submitted to the network by the hydra client
       now instead of `hydra-node`.
     - Commits via `/commit` also allow to commit scripts into a Hydra Head. For
       that, the UTxO entry in the HTTP request needs to provide a `witness` with
-      scrpit, datum, and redeemer to be used.
+      script, datum, and redeemer to be used.
     - Removed the need to mark fuel when using external commits. Fees for Hydra
       protocol transactions are paid the largest UTxO held by the internal
       wallet if no marked fuel UTxO is present.
@@ -834,7 +834,7 @@ changes.
 
 - Implement on-chain contestation logic [#192](https://github.com/cardano-scaling/hydra/issues/192):
   + Node will automatically post a `Contest` transaction when it observes a `Close` or `Contest` with an obsolete snapshot
-  + Posting a fan-out transaction is not possible before the contestation dealine has passed
+  + Posting a fan-out transaction is not possible before the contestation deadline has passed
 
 - Transactions can now be submitted as raw CBOR-serialized object, base16 encoded, using the `NewTx` client input. This also supports the text-envelope format from cardano-cli out of the box. See the [api Reference](https://hydra.family/head-protocol/api-reference#operation-publish-/-message).
 
@@ -893,7 +893,7 @@ changes.
 - **BREAKING** Renamed server output `UTxO -> GetUTxOResponse`
   + This should be a better name for the response of `GetUTxO` client input on our API :)
 
-- Updated our dependencies (`plutus`, `cardano-ledger`, etc.) to most recent released versions making scripts smaller and Head transactions slighly cheaper already, see benchmarks for current limits.
+- Updated our dependencies (`plutus`, `cardano-ledger`, etc.) to most recent released versions making scripts smaller and Head transactions slightly cheaper already, see benchmarks for current limits.
 
 #### Fixed
 
@@ -1002,7 +1002,7 @@ changes.
 - 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 all its UTXO in a
   Head, it won't be able to send or receive anything anymore.
-- TUI crashes when user tries to post a new transaction wihout any UTXO
+- TUI crashes when user tries to post a new transaction without any UTXO
   remaining.
 - Not an issue, but a workaround: The internal wallet of `hydra-node` requires a
   UTXO to be marked as "fuel" to drive the Hydra protocol transactions.

SECURITY.md

@@ -61,7 +61,7 @@ Please include as much details as needed to clearly qualify the issue:
 
 6. **Release**: The team creates and publish a release that includes the fix
 
-7. **Announcement**: Concommitant to the release annoucement, the team announces the security vulnerability by making the GitHub issue public. This is the first point that any information regarding the vulnerability is made public.
+7. **Announcement**: Concommitant to the release announcement, the team announces the security vulnerability by making the GitHub issue public. This is the first point that any information regarding the vulnerability is made public.
 
     a. **Credit**: The team publicly acknowledges the contributions of the
        reporter once the vulnerability is resolved, subject to the

docs/adr/2021-06-05_001-record-architectural-decisions.md

@@ -14,7 +14,7 @@ Accepted
 
 We are in search for a means to describe our technical architecture.
 
-We are a small team working in a very lean and agile way (XP), so we naturally prefer also light-weight documentation methods which also accomodate change easily.
+We are a small team working in a very lean and agile way (XP), so we naturally prefer also light-weight documentation methods which also accommodate change easily.
 
 ## Decision
 

docs/adr/2021-08-19_009-simplify-logging.md

@@ -16,7 +16,7 @@ Accepted
 * Providing the needed components and tools to be able to configure logging and monitoring to each operator's liking should not be the responibility of the Hydra node, and requires complex machinery that will need to be maintained and evolved
 * When a problem occurs in production, if the process is not verbose enough it can be very hard to analyse the problem
   * Enabling dynamic changes of verbosity in logs is both complex to implement and comes too late
-  * Deciding in the code on what's the right "severity" for a log entry leads to dropping important information on _how_ some error occured
+  * Deciding in the code on what's the right "severity" for a log entry leads to dropping important information on _how_ some error occurred
 
 ## Decision
 

docs/adr/2022-07-22_019-reference-scripts.md

@@ -32,7 +32,7 @@ Accepted
 
 * Publish outputs holding Hydra scripts out-of-band (option 2), because
   + All scripts would not fit into the `init` transaction directly, we would need to post multiple.
-  + Costs (deposits) would need to be payed for each head instance.
+  + Costs (deposits) would need to be paid for each head instance.
 
 * The scripts are stored at outputs addressed to some **unspendable** `v_publish` validator.
   + This is to avoid DoS risk and unnecessariy centralization

docs/adr/2022-12-05_021-Bounded-transaction-validity-on-Hydra-protocol-transactions.md

@@ -37,7 +37,7 @@ Accepted
   upper bound on the `closeTx`. This was also required so far to compute the
   contestation deadline.
 
-- Different networks (chains) have different slot lenghts, e.g. the preview
+- Different networks (chains) have different slot lengths, e.g. the preview
   network has a slot every `1s`, while our local devnets use `0.1s`. This means
   hardcoded values like `closeGraceTime` need to be _in sync_ with the
   underlying network.
@@ -105,5 +105,5 @@ Accepted
   constructing transactions since we cannot convert arbitrary point in times to
   slots.
 
-- All parties need to aggree on contestation period before trying to run a Head
+- All parties need to agree on contestation period before trying to run a Head
   protocol otherwise InitTx will be ignored.

docs/adr/2023-04-26_023-local-chain-state.md

@@ -27,7 +27,7 @@ Accepted
 - [#185](https://github.com/cardano-scaling/hydra/issues/185) plans to improve
   rollback management.
 
-The following picture details the race condition through an exemple:
+The following picture details the race condition through an example:
 
 1. The DirectChain component fetch some `chainState 0` from the `headState`
 

docs/adr/2023-09-09_027-network-resilience.md

@@ -33,7 +33,7 @@ Therefore, the scope of this ADR is to address only point 1. above: Ensure broad
   * It also takes care of reconnecting to peers when a failure is detected which relieves us from doing so, but any reconnection implies a reset of each peer's state machine which means we need to make sure any change to the state of pending/received messages is handled by the applicative layer
   * Our [FireForget protocol](https://github.com/cardano-scaling/hydra/blob/8a8e0829964132bde8949e5249a1ab303af92fb8/hydra-node/src/Hydra/Network/Ouroboros/Type.hs#L31) ignores connections/disconnections
   * Ouroboros/typed-protocols provides enough machinery to implement a reliable broadcast protocol, for example by reusing existing `[KeepAlive](https://github.com/input-output-hk/ouroboros-network/tree/master/ouroboros-network-protocols/src/Ouroboros/Network/Protocol/KeepAlive)` protocol and building a more robust point-to-point protocol than what we have now
-  * There is a minor limitation, namely that the subscription mechanism does not handle connections invidually, but as a set of equivalent point-to-point full duplex connections whose size (valency) needs to be maintained at a certain threshold, which means that unless backed in the protocol itself, protocol state-machine and applications are not aware of the identity of the remote peer
+  * There is a minor limitation, namely that the subscription mechanism does not handle connections individually, but as a set of equivalent point-to-point full duplex connections whose size (valency) needs to be maintained at a certain threshold, which means that unless backed in the protocol itself, protocol state-machine and applications are not aware of the identity of the remote peer
 * We have built our `Network` infrastructure over the concept of relatively independent layers, each implementing a similar interface with different kind of messages, to `broadcast` messages to all peers and be notified of incoming messages through a `callback`.
   * This pipes-like abstraction allows us to compose our network stack like:
 

docs/adr/2024-01-27_031-constant-memory.md

@@ -22,7 +22,7 @@ used to serve in-memory data are using a common haskell list as a data
 structure. We should stream the data keeping the memory bounded as the first
 optimisation.
 
-It is also not necesary to output the whole history of messages by default and
+It is also not necessary to output the whole history of messages by default and
 only do that if clients request to see the whole history. Internally our
 `ServerOutput` type could be remapped to `StateChanged` since the two are
 almost identical. Any new information must be streamed to the clients

docs/adr/2025-02-12_032-network-properties-etcd.md

@@ -59,12 +59,12 @@ Accepted
   - Docker image users should not see any different UX
   - We can ship the binary through `hydra-node`.
 
-- Introspectability network as the `etcd` cluster is queriable could improve debugging experience
+- Introspectability network as the `etcd` cluster is queryable could improve debugging experience
 
 - Persisted state for networking changes as there will be no `acks`, but the `etcd` Write Ahead Log (WAL) and a last seen revision.
 
 - Can keep same user experience on configuration
-  - Full, static topology with listing everone as `--peer`
+  - Full, static topology with listing everyone as `--peer`
   - Simpler configuration via [peer discovery](https://etcd.io/docs/v3.5/op-guide/clustering/#discovery) possible
 
 - `PeerConnected` semantics needs to change to an overall `HydraNetworkConnected`