fix a few typos in spec

docs/spec/abci/abci.md

@@ -12,7 +12,7 @@ ABCI methods are split across 3 separate ABCI *connections*:
 - `Info Connection: Info, SetOption, Query`
 
 The `Consensus Connection` is driven by a consensus protocol and is responsible
-for block exection.
+for block execution.
 The `Mempool Connection` is for validating new transactions, before they're
 shared or included in a block.
 The `Info Connection` is for initialization and for queries from the user.

docs/spec/abci/apps.md

@@ -18,7 +18,7 @@ Here we cover the following components of ABCI applications:
 
 Since Tendermint maintains multiple concurrent ABCI connections, it is typical
 for an application to maintain a distinct state for each, and for the states to
-be sycnronized during `Commit`.
+be synchronized during `Commit`.
 
 ### Commit
 
@@ -41,7 +41,7 @@ the working state for block execution. It should be updated by the calls to
 disk as the "latest committed state" during `Commit`.
 
 Updates made to the DeliverTxState by each method call must be readable by each subsequent method -
-ie. the updates are linearizeable.
+ie. the updates are linearizable.
 
 ### Mempool Connection
 
@@ -76,7 +76,7 @@ block full of invalid transactions if it wants.
 The Mempool Connection should maintain a `QueryState` for answering queries from the user,
 and for initialization when Tendermint first starts up.
 It should always contain the latest committed state associated with the
-latest commited block.
+latest committed block.
 
 QueryState should be set to the latest `DeliverTxState` at the end of every `Commit`,
 ie. after the full block has been processed and the state committed to disk.
@@ -217,7 +217,7 @@ storeBlockHeight = height of the last block Tendermint saw a commit for
 stateBlockHeight = height of the last block for which Tendermint completed all
     block processing and saved all ABCI results to disk
 appBlockHeight = height of the last block for which ABCI app succesfully
-    completely Commit
+    completed Commit
 ```
 
 Note we always have `storeBlockHeight >= stateBlockHeight` and `storeBlockHeight >= appBlockHeight`
@@ -225,7 +225,7 @@ Note also we never call Commit on an ABCI app twice for the same height.
 
 The procedure is as follows.
 
-First, some simeple start conditions:
+First, some simple start conditions:
 
 If `appBlockHeight == 0`, then call InitChain.
 

docs/spec/abci/client-server.md

@@ -88,7 +88,7 @@ The main ABCI server (ie. non-GRPC) provides ordered asynchronous messages.
 This is useful for DeliverTx and CheckTx, since it allows Tendermint to forward
 transactions to the app before it's finished processing previous ones.
 
-Thus, DeliverTx and CheckTx messages are sent asycnhronously, while all other
+Thus, DeliverTx and CheckTx messages are sent asynchronously, while all other
 messages are sent synchronously.
 
 ## Client

docs/spec/blockchain/state.md

@@ -104,11 +104,11 @@ type EvidenceParams struct {
 
 #### BlockSize
 
-The total size of a block is limitted in bytes by the `ConsensusParams.BlockSize.MaxBytes`.
+The total size of a block is limited in bytes by the `ConsensusParams.BlockSize.MaxBytes`.
 Proposed blocks must be less than this size, and will be considered invalid
 otherwise.
 
-Blocks should additionally be limitted by the amount of "gas" consumed by the
+Blocks should additionally be limited by the amount of "gas" consumed by the
 transactions in the block, though this is not yet implemented.
 
 #### TxSize

docs/spec/p2p/peer.md

@@ -40,7 +40,7 @@ It goes as follows:
   - get 96 bytes of output from hkdf-sha256
   - if we had the smaller ephemeral pubkey, use the first 32 bytes for the key for receiving, the second 32 bytes for sending; else the opposite
   - use the last 32 bytes of output for the challenge
-- use a seperate nonce for receiving and sending. Both nonces start at 0, and should support the full 96 bit nonce range
+- use a separate nonce for receiving and sending. Both nonces start at 0, and should support the full 96 bit nonce range
 - all communications from now on are encrypted in 1024 byte frames,
   using the respective secret and nonce. Each nonce is incremented by one after each use.
 - we now have an encrypted channel, but still need to authenticate