From b28d312e14778412cb58ae007ca82d581f92a641 Mon Sep 17 00:00:00 2001 From: leopardracer <136604165+leopardracer@users.noreply.github.com> Date: Tue, 12 Nov 2024 21:21:53 +0200 Subject: [PATCH] fix: typos in documentation files (#1525) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit **Description** This pull request contains changes to improve clarity, correctness and structure. Please review the changes and let me know if any additional changes are needed. 1. Corrected "compatability" → "compatibility" 2. Corrected "transacton" → "transaction" 3. Corrected "double-sigining" → "double-signing" 4. Corrected "entires" → "entries" 5. Corrected "empthHash" → "emptyHash" 6. Corrected "reponse" → "response" **PR checklist** - [x] Tests written/updated - [ ] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [x] Updated relevant documentation (`docs/` or `spec/`) and code comments --- mempool/cat/spec.md | 4 ++-- spec/consensus/signing.md | 2 +- spec/core/encoding.md | 4 ++-- spec/p2p/v0.34/pex.md | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/mempool/cat/spec.md b/mempool/cat/spec.md index 2cd35bd87a..2048e6d7d2 100644 --- a/mempool/cat/spec.md +++ b/mempool/cat/spec.md @@ -38,7 +38,7 @@ message WantTx { Both `SeenTx` and `WantTx` contain the sha256 hash of the raw transaction bytes. `SeenTx` also contains an optional `p2p.ID` that corresponds to the peer that the node recieved the tx from. The only validation for both is that the byte slice of the `tx_key` MUST have a length of 32. -Both messages are sent across a new channel with the ID: `byte(0x31)`. This enables cross compatability as discussed in greater detail below. +Both messages are sent across a new channel with the ID: `byte(0x31)`. This enables cross compatibility as discussed in greater detail below. > **Note:** > The term `SeenTx` is used over the more common `HasTx` because the transaction pool contains sophisticated eviction logic. TTL's, higher priority transactions and reCheckTx may mean that a transaction pool *had* a transaction but does not have it any more. Semantically it's more appropriate to use `SeenTx` to imply not the presence of a transaction but that the node has seen it and dealt with it accordingly. @@ -53,7 +53,7 @@ A node in the protocol has two distinct modes: "broadcast" and "request/response A `SeenTx` is broadcasted to ALL nodes upon receiving a "new" transaction from a peer. The transaction pool does not need to track every unique inbound transaction, therefore "new" is identified as: - The node does not currently have the transaction -- The node did not recently reject the transacton or has recently seen the same transaction committed (subject to the size of the cache) +- The node did not recently reject the transaction or has recently seen the same transaction committed (subject to the size of the cache) - The node did not recently evict the transaction (subject to the size of the cache) Given this criteria, it is feasible, yet unlikely that a node receives two `SeenTx` messages from the same peer for the same transaction. diff --git a/spec/consensus/signing.md b/spec/consensus/signing.md index 38afe35022..18fa1454f5 100644 --- a/spec/consensus/signing.md +++ b/spec/consensus/signing.md @@ -5,7 +5,7 @@ Here we specify the rules for validating a proposal and vote before signing. First we include some general notes on validating data structures common to both types. -We then provide specific validation rules for each. Finally, we include validation rules to prevent double-sigining. +We then provide specific validation rules for each. Finally, we include validation rules to prevent double-signing. ## SignedMsgType diff --git a/spec/core/encoding.md b/spec/core/encoding.md index 0c2fdb1f63..25d979b6c5 100644 --- a/spec/core/encoding.md +++ b/spec/core/encoding.md @@ -19,7 +19,7 @@ For details on varints, see the [protobuf spec](https://developers.google.com/protocol-buffers/docs/encoding#varints). For example, the byte-array `[0xA, 0xB]` would be encoded as `0x020A0B`, -while a byte-array containing 300 entires beginning with `[0xA, 0xB, ...]` would +while a byte-array containing 300 entries beginning with `[0xA, 0xB, ...]` would be encoded as `0xAC020A0B...` where `0xAC02` is the UVarint encoding of 300. ## Hashing @@ -171,7 +171,7 @@ func getSplitPoint(k int) { ... } func MerkleRoot(items [][]byte) []byte{ switch len(items) { case 0: - return empthHash() + return emptyHash() case 1: return leafHash(items[0]) default: diff --git a/spec/p2p/v0.34/pex.md b/spec/p2p/v0.34/pex.md index 8243eaa559..8f49e84af7 100644 --- a/spec/p2p/v0.34/pex.md +++ b/spec/p2p/v0.34/pex.md @@ -106,6 +106,6 @@ A node receives two type of messages as part of the PEX protocol: - `PexRequest`: a request for addresses received from a peer, handled as described [here](./pex-protocol.md#providing-addresses) -- `PexAddrs`: a list of addresses received from a peer, as a reponse to a PEX +- `PexAddrs`: a list of addresses received from a peer, as a response to a PEX request sent by the node, as described [here](./pex-protocol.md#responses)