fix: typos in documentation files (#1525)

**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

@@ -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.

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
 

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:

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)