Fix: typos (#320) (#327)

* Fix: typos * Fix: typos * Fix: typo (cherry picked from commit 555ff1d) Co-authored-by: omahs <[email protected]>
celestiaorg · Feb 11, 2023 · dafe7fa · dafe7fa
1 parent 38abebd
commit dafe7fa
Show file tree

Hide file tree

Showing 3 changed files with 6 additions and 6 deletions.
diff --git a/docs/core/fast-sync.md b/docs/core/fast-sync.md
@@ -24,7 +24,7 @@ In this mode, the CometBFT daemon will sync hundreds of times faster
 than if it used the real-time consensus process. Once caught up, the
 daemon will switch out of fast sync and into the normal consensus mode.
 After running for some time, the node is considered `caught up` if it
-has at least one peer and it's height is at least as high as the max
+has at least one peer and its height is at least as high as the max
 reported peer height.
 See [the IsCaughtUp method](https://github.com/cometbft/cometbft/blob/v0.34.x/blockchain/v0/pool.go#L168).
 

diff --git a/docs/introduction/what-is-cometbft.md b/docs/introduction/what-is-cometbft.md
@@ -92,7 +92,7 @@ Since then, CometBFT has evolved to be a general purpose blockchain
 consensus engine that can host arbitrary application states. That means
 it can be used as a plug-and-play replacement for the consensus engines
 of other blockchain software. So one can take the current Ethereum code
-base, whether in Rust, or Go, or Haskell, and run it as a ABCI
+base, whether in Rust, or Go, or Haskell, and run it as an ABCI
 application using CometBFT. Indeed, [we did that with
 Ethereum](https://github.com/cosmos/ethermint). And we plan to do
 the same for Bitcoin, ZCash, and various other deterministic
@@ -166,7 +166,7 @@ Teaspoon).
 "consensus engine", communicates with the application via a socket
 protocol that satisfies the ABCI, the CometBFT Socket Protocol.
 
-To draw an analogy, lets talk about a well-known cryptocurrency,
+To draw an analogy, let's talk about a well-known cryptocurrency,
 Bitcoin. Bitcoin is a cryptocurrency blockchain where each node
 maintains a fully audited Unspent Transaction Output (UTXO) database. If
 one wanted to create a Bitcoin-like system on top of ABCI, CometBFT

diff --git a/docs/tutorials/go-built-in.md b/docs/tutorials/go-built-in.md
@@ -218,7 +218,7 @@ Our application will need to write its state out to persistent storage so that i
 can stop and start without losing all of its data.
 
 For this tutorial, we will use [BadgerDB](https://github.com/dgraph-io/badger), a
-a fast embedded key-value store.
+fast embedded key-value store.
 
 First, add Badger as a dependency of your go module using the `go get` command:
 
@@ -302,7 +302,7 @@ its validation checks. The specific value of the code is meaningless to CometBFT
 Non-zero codes are logged by CometBFT so applications can provide more specific
 information on why the transaction was rejected.
 
-Note that `CheckTx` does not execute the transaction, it only verifies that that the transaction could be executed. We do not know yet if the rest of the network has agreed to accept this transaction into a block.
+Note that `CheckTx` does not execute the transaction, it only verifies that the transaction could be executed. We do not know yet if the rest of the network has agreed to accept this transaction into a block.
 
 
 Finally, make sure to add the bytes package to the `import` stanza at the top of `app.go`:
@@ -326,7 +326,7 @@ application over three ABCI method calls: `BeginBlock`, `DeliverTx`, and `EndBlo
 receive a block.
 - `DeliverTx` is called repeatedly, once for each application transaction that was included in the block.
 - `EndBlock` is called once to indicate to the application that no more transactions
-will be delivered to the application in within this block.
+will be delivered to the application within this block.
 
 Note that, to implement these calls in our application we're going to make use of Badger's
 transaction mechanism. We will always refer to these as Badger transactions, not to