From 6cd98e8d3d39295e593aa54b069c4cc9b8fdb8d2 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Tue, 3 Oct 2023 10:46:55 +0200 Subject: [PATCH 1/8] fix typos --- docs/core-concepts/behavior.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/core-concepts/behavior.md b/docs/core-concepts/behavior.md index 3fe33149416..8590b4c9b91 100644 --- a/docs/core-concepts/behavior.md +++ b/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`. From 7916a79d8704001f63fd626a09a059802415b13f Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Tue, 3 Oct 2023 10:49:02 +0200 Subject: [PATCH 2/8] fix typo --- docs/core-concepts/scalability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core-concepts/scalability.md b/docs/core-concepts/scalability.md index 8a8486f8497..e9bfa0c8228 100644 --- a/docs/core-concepts/scalability.md +++ b/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 From a42fcba939fdfe12afa0ce994650fed30ad11bb1 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Tue, 3 Oct 2023 10:49:53 +0200 Subject: [PATCH 3/8] fix typo --- docs/monthly/2023-02-monthly.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/monthly/2023-02-monthly.md b/docs/monthly/2023-02-monthly.md index 3cbd0c8e0ec..1b2dd3195e9 100644 --- a/docs/monthly/2023-02-monthly.md +++ b/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 From 74910d970fdd11095423bb39b16f30d463df9f1d Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Tue, 3 Oct 2023 10:50:41 +0200 Subject: [PATCH 4/8] fix typo --- docs/core-concepts/faq/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core-concepts/faq/index.md b/docs/core-concepts/faq/index.md index f5189a0a78c..18e9a028163 100644 --- a/docs/core-concepts/faq/index.md +++ b/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. From 55ecfb878954e6d0734729efba7fd56b6bb4547f Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Tue, 3 Oct 2023 10:51:54 +0200 Subject: [PATCH 5/8] fix typos --- docs/docs/known-issues.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/docs/known-issues.md b/docs/docs/known-issues.md index da658ec20e2..73aa0f7bddd 100644 --- a/docs/docs/known-issues.md +++ b/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 From 60a758f7afec1ed027f07859b67dfc02f6ba7638 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Tue, 3 Oct 2023 10:55:22 +0200 Subject: [PATCH 6/8] fix typo --- docs/docs/getting-started/operating-hydra.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/getting-started/operating-hydra.md b/docs/docs/getting-started/operating-hydra.md index 3e23368c619..e2d5829f249 100644 --- a/docs/docs/getting-started/operating-hydra.md +++ b/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/). ::: From a4106bbc3cd16240400d2241a405907dbc8e5d63 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Tue, 3 Oct 2023 10:56:47 +0200 Subject: [PATCH 7/8] fix typo --- docs/docs/getting-started/quickstart.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/docs/getting-started/quickstart.md b/docs/docs/getting-started/quickstart.md index 47f9ae1a98f..89161c3e169 100644 --- a/docs/docs/getting-started/quickstart.md +++ b/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). From 19d86a38385a5409f540b5cb8605ef884ef27697 Mon Sep 17 00:00:00 2001 From: Sasha Bogicevic Date: Wed, 4 Oct 2023 09:08:33 +0200 Subject: [PATCH 8/8] Fix the text in the actual parser --- hydra-node/src/Hydra/Options.hs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hydra-node/src/Hydra/Options.hs b/hydra-node/src/Hydra/Options.hs index 2e6ae6c7ca6..515b3c69353 100644 --- a/hydra-node/src/Hydra/Options.hs +++ b/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." )