Fix typos

README.adoc

@@ -308,7 +308,7 @@ The command-line consensus tool, `omnij-consensus-tool` can be built into a nati
 
 === Building
 
-Before building you'll need a GraalVM setup on your system. Besides intalling the Graal JDK, you'll need to do the following:
+Before building you'll need a GraalVM setup on your system. Besides installing the Graal JDK, you'll need to do the following:
 
 1. Set `GRAAL_HOME` to the `JAVA_HOME` of the GraalVM JDK
 2. With the GraalVM active, type `gu install native-image` to install the optional `native-image` tool.

doc/omni-consensus-hashing.adoc

@@ -35,7 +35,7 @@ It is for these reasons that we propose using a hashing function to create hashe
 
 Details forthcoming.
 
-Note that the hash data does not need to be calculate or stored by Omni Core itself, but can be calculated and stored by integration tests and/or Omniwallet. Hashes could be stored in a SQL databases and indexed by block height and currencyID.
+Note that the hash data does not need to be calculated or stored by Omni Core itself, but can be calculated and stored by integration tests and/or Omniwallet. Hashes could be stored in a SQL databases and indexed by block height and currencyID.
 
 === Defining inputs to the hashes
 
@@ -51,11 +51,11 @@ This is a hash of all consensus data for all currencies in existence at a specif
 
 === Currency Delta Consensus Hash
 
-A hash of only the changes to balances of a specific CurrencyID that occurred during the specific block.  This has may not be very useful and/or may be difficult to compute.
+A hash of only the changes to balances of a specific CurrencyID that occurred during the specific block.  This may not be very useful and/or may be difficult to compute.
 
 === Block Delta Consensus Hash
 
-A hash of the changes to balances of all currencies that occurred during the specific block.  This has may not be very useful and/or may be difficult to compute.
+A hash of the changes to balances of all currencies that occurred during the specific block.  This may not be very useful and/or may be difficult to compute.
 
 == Notes on Hash Algorithms
 

doc/omni-utxo-management.adoc

@@ -52,7 +52,7 @@ https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki[BIP-84: Derivatio
 
 === SLIP 44
 
-SatoshiLabs has created the **SLIP** family of specifications for the purpose of creating interoperability between hardware wallets. Since the **BIP** specifications are very Bitcoin-specific and the understandable reluctance of Bitcoin developers to spend time updating their specification documents for "alt coins", the **SLIP** specifications fill this gap and provide practical standards for wallet manufacturers and developers wishing ot support multiple blockchains in a standard matter.
+SatoshiLabs has created the **SLIP** family of specifications for the purpose of creating interoperability between hardware wallets. Since the **BIP** specifications are very Bitcoin-specific and the understandable reluctance of Bitcoin developers to spend time updating their specification documents for "alt coins", the **SLIP** specifications fill this gap and provide practical standards for wallet manufacturers and developers wishing to support multiple blockchains in a standard matter.
 
 https://github.com/satoshilabs/slips/blob/master/slip-0044.md[SLIP-0044 : Registered coin types for BIP-0044] provides an official registry of BIP 44 coin types for various coins -- _including Omni!_  Omni is listed with coin type *200*.
 

doc/omnij-consensus-tool-manpage.adoc

@@ -80,7 +80,7 @@ Specify an Omni property id
 Write consensus info to _filename_
 
 *-v*, *-verbose*::
-Verbose (logging) outpu.
+Verbose (logging) output.
 
 
 *-x*, *-compare*::
@@ -103,13 +103,13 @@ Perform a consensus comparison
 
 Here are some examples.
 
-* Print consensus info for property id 1 (OMNI) from localhost Omni Core. The command will use the information in `bitcion.conf` to find the local server.
+* Print consensus info for property id 1 (OMNI) from localhost Omni Core. The command will use the information in `bitcoin.conf` to find the local server.
 +
 ------------
 $ omnij-consensus-tool -property 1
 ------------
 
-* Save consensus info for property id 1 (OMNI) from localhost Omni Core to a tab-seperate-value file named `omni_balances.tsv`. The command will use the information in `bitcion.conf` to find the local server.
+* Save consensus info for property id 1 (OMNI) from localhost Omni Core to a tab-separate-value file named `omni_balances.tsv`. The command will use the information in `bitcoin.conf` to find the local server.
 +
 ------------
 $ omnij-consensus-tool -property 1 -output omni_balances.tsv

doc/omnij-test-design-patterns.adoc

@@ -23,17 +23,17 @@ Although the initial focus was testing, it was always the intention to build gen
 
 The core clients are written in pure Java are strongly typed using bitcoinj classes (e.g. Sha256Sum, Address) and use method overloading to create convenience methods with fewer parameters given that Java doesn't support optional parameters.
 
-More detail should be provided here. I've written about this elsewhere (Github Issue comments?) and some of that information should be consoolidated here.
+More detail should be provided here. I've written about this elsewhere (Github Issue comments?) and some of that information should be consolidated here.
 
 === Test Support Classes
 
-Since all the tests are written in the Spock Framework and we want to support rapid development of expressive, non-verbose tests, most of of the test support code is in Groovy -- with much of it being in Groovy traits and in Spock base classes.
+Since all the tests are written in the Spock Framework and we want to support rapid development of expressive, non-verbose tests, most of the test support code is in Groovy -- with much of it being in Groovy traits and in Spock base classes.
 
 As use cases beyond testing are discovered for functionality in test support components, it can be refactored into classes that can be used outside of the test framework and even into pure Java classes when we desire to support the largest possible set of run-time environments.
 
 == Test Framework Design Patterns
 
-A variety of approaches are made for aggregrating test framework functionality into the Spock integration tests. Each approach has advantages and disadvantages and we have been frequently refactoring the code to maximize readability and to make core functionality reusable within the tests and, when desired, outside the tests.
+A variety of approaches are made for aggregating test framework functionality into the Spock integration tests. Each approach has advantages and disadvantages and we have been frequently refactoring the code to maximize readability and to make core functionality reusable within the tests and, when desired, outside the tests.
 
 When test support functionality is useful for (upstream) Bitcoin testing, we place it in a subpackage of `com.msgilligan.bitcoin`, when it is Omni specific we place it in a subpackage of `foundation.omni`.
 
@@ -77,7 +77,7 @@ Disadvantage:
 
 === RPC Clients
 
-When there is functionality that will be useful to any application communicating with Bitcoin/Omni Core via JSON-RPC that functionality can be placed directly in one of the RPC client implementations. Currently all the RPC clients generally try to limit themselves to 1 RPC call per method and try to keep a 1-to-1 relationship betwen client object methods and JSON-RPC methods.
+When there is functionality that will be useful to any application communicating with Bitcoin/Omni Core via JSON-RPC that functionality can be placed directly in one of the RPC client implementations. Currently all the RPC clients generally try to limit themselves to 1 RPC call per method and try to keep a 1-to-1 relationship between client object methods and JSON-RPC methods.
 
 (A minor exception to the 1-to-1 rule is the `OmniExtendedClient` which uses client-side transaction generation and the `sendrawtx_MP` method to create and send Omni transactions that are not supported in the current, stable version of Omni Core.)