Small formatting, typographical, and grammatical edits to documentation (#117)

* Fix indentation issue on structured list
* Fix small typographical and grammatical errors in docs

CONTRIBUTING.md

@@ -2,7 +2,7 @@
 
 Find an area you can help with and do it. Open source is about collaboration and open participation. Try to make your code look like what already exists and submit a pull request.
 
-The [list of issues](https://github.com/ignopeverell/grin/issues) is a good place to start, especially the ones tagged as "help wanted" (but don't let that stop you from looking at others).If you're looking for additional ideas, the code includes `TODO` comments for minor to major improvements. Grep is your friend.
+The [list of issues](https://github.com/ignopeverell/grin/issues) is a good place to start, especially the ones tagged as "help wanted" (but don't let that stop you from looking at others). If you're looking for additional ideas, the code includes `TODO` comments for minor to major improvements. Grep is your friend.
 
 Additional tests are rewarded with an immense amount of positive karma. So is documentation.
 

doc/build.md

@@ -98,7 +98,7 @@ Let the mining server find a few blocks, then stop (just ctrl-c) the mining serv
 
 The following outlines a more advanced example simulating a multi-server network with transactions being posted. 
 
-For the sake of example, we're going to run three nodes with varying setups. Create two more directories beside your node1 directory, called node2 and node3. If you want to clear data from your previous run (or anytime you want to reset the blockchain and all peer data,) just delete the wallet.dat file in the server1 directory and run rm -rf .grin to remove grin's database. 
+For the sake of example, we're going to run three nodes with varying setups. Create two more directories beside your node1 directory, called node2 and node3. If you want to clear data from your previous run (or anytime you want to reset the blockchain and all peer data) just delete the wallet.dat file in the server1 directory and run rm -rf .grin to remove grin's database.
 
 ### Node 1: Genesis and Miner
 

doc/chainsync.md

@@ -3,7 +3,7 @@ Blockchain Syncing
 
 We describe here the different methods used by a new node when joining the network
 to catch up with the latest chain state. We start with reminding the reader of the
-following assumptions, that are all characteristics of Grin or MimbleWimble:
+following assumptions, which are all characteristics of Grin or MimbleWimble:
 
 * All block headers include the root hash of all unspent outputs in the chain at
   the time of that block.
@@ -38,7 +38,7 @@ provide history archival and allow later checks and verifications to be made.
 Identical to other blockchains:
 
 * If all nodes we're connected to are dishonest (sybil attack or similar), we can
-  be lied about the whole chain state.
+  be lied to about the whole chain state.
 * Someone with enormous mining power could rewrite the whole history.
 * Etc.
 
@@ -65,7 +65,7 @@ With this information it can verify:
 * the sum of all UTXO commitments equals the expected money supply
 * the root hash of all UTXOs match the root hash in the block header
 
-Once the validation done, the peer can download and validate the blocks content
+Once the validation is done, the peer can download and validate the blocks content
 from the horizon up to the head.
 
 While this algorithm still works for very low values of `Z` (or in the extreme case

doc/merkle.md

@@ -11,7 +11,7 @@ treat Merkle sum trees as the default option, and address the sums here.
 
 A design goal of Grin is that all structures be as easy to implement and
 as simple as possible. MimbleWimble introduces a lot of new cryptography
-so it should made as easy to understand as possible. Its validation rules
+so it should be made as easy to understand as possible. Its validation rules
 are simple to specify (no scripts) and Grin is written in a language with
 very explicit semantics, so simplicity is also good to achieve well-understood
 consensus rules.
@@ -31,8 +31,8 @@ The root sum should be equal to the sum of all excesses since the genesis.
 
 Design requirements:
 
-1. Efficient additions and updating from unspent to spent
-2. Efficient proofs that a specific output was spent
+1. Efficient additions and updating from unspent to spent.
+2. Efficient proofs that a specific output was spent.
 3. Efficient storage of diffs between UTXO roots.
 4. Efficient tree storage even with missing data, even with millions of entries.
 5. If a node commits to NULL, it has no unspent children and its data should
@@ -147,8 +147,8 @@ structure of the tree without needing all the hashes, and can determine which
 nodes are siblings, and so on.
 
 In the output set each node also commits to a sum of its unspent children, so
-a validator knows if it is missing data on unspent coins, by checking whether
-this sum on a pruned node is zero or not.
+a validator knows if it is missing data on unspent coins by checking whether or
+not this sum on a pruned node is zero.
 
 
 ## Algorithms
@@ -200,8 +200,8 @@ In the example above, we have 2 chunks X[A,B] and Y[C,D] and a root chunk
 G[M,E]. The cutoff height H=1 and the root height R=3.
 
 Note that each non-root chunk is a complete and fully valid MMR sum tree in
-itself. The the root chunk, with each chunk replaced with a single pruned
-node is also a complete and fully valid MMR.
+itself. The root chunk, with each chunk replaced with a single pruned node,
+is also a complete and fully valid MMR.
 
 As new leaves get inserted in the tree, more chunks get extracted, reducing the
 size of the root chunk.

doc/pruning.md

@@ -8,12 +8,12 @@ The grin blockchain includes the following types of data (we assume prior
 understanding of the MimbleWimble protocol):
 
 1. Transaction outputs, which include for each output:
-  1. A Pedersen commitment (33 bytes).
-  2. A range proof (over 5KB at this time).
-2. Transaction inputs which are just output references (32 bytes).
+    1. A Pedersen commitment (33 bytes).
+    2. A range proof (over 5KB at this time).
+2. Transaction inputs, which are just output references (32 bytes).
 3. Transaction "proofs", which include for each transaction:
-  1. The excess commitment sum for the transaction (33 bytes).
-  2. A signature generated with the excess (71 bytes average).
+    1. The excess commitment sum for the transaction (33 bytes).
+    2. A signature generated with the excess (71 bytes average).
 4. A block header includes Merkle trees and proof of work (about 250 bytes).
 
 Assuming a blockchain of a million blocks, 10 million transactions (2 inputs, 2.5