Updated multiple pages to be 1 sentence per line.

Updated the following files:

contributors.md
protocol/blockchain/transaction.md
project-history.md
target-audience.md
protocol/blockchain/hash.md

contributors.md

@@ -1,6 +1,7 @@
 # Contributors
 
-This specification was initially created by [Software Verde, LLC](https://softwareverde.com/), the creators of Bitcoin Verde, in association with [Bitcoin Unlimited](https://www.bitcoinunlimited.info/) which provided both funding and content to ensure this project's success.  For more information see [Project History](/project-history).
+This specification was initially created by [Software Verde, LLC](https://softwareverde.com/), the creators of Bitcoin Verde, in association with [Bitcoin Unlimited](https://www.bitcoinunlimited.info/) which provided both funding and content to ensure this project's success.
+For more information see [Project History](/project-history).
 
 ## Content Licensing
 
@@ -14,7 +15,8 @@ By contributing content to this project, you agree that either:
 
 ## Contributor List
 
-The contributor list below shows a list of those that have contributed content.  If you have contributed content and would like to be listed below, feel free to add your name!
+The contributor list below shows a list of those that have contributed content.
+If you have contributed content and would like to be listed below, feel free to add your name!
 
  - __Andrew Stone__, Bitcoin Unlimited Lead Developer
  - __Joshua Green__, Bitcoin Verde Lead Developer

project-history.md

@@ -1,6 +1,9 @@
 # Project History
 
-The Bitcoin Cash Protocol has evolved since its inception by Satoshi Nakamoto in 2009.  These evolutions have taken form from live network protocol changes, hard forks, and soft forks.  The greater Bitcoin community has attempted to document the protocol many times since the creation of the network.  Other documentation sources include:
+The Bitcoin Cash Protocol has evolved since its inception by Satoshi Nakamoto in 2009.
+These evolutions have taken form in live network protocol changes, hard forks, and soft forks.
+The greater Bitcoin community has attempted to document the protocol many times since the creation of the network.
+Other documentation sources include:
 
 - [bitcoin.it](//bitcoin.it)
 - [bitcoin.org/en/developer-reference](//bitcoin.org/en/developer-reference)
@@ -8,6 +11,10 @@ The Bitcoin Cash Protocol has evolved since its inception by Satoshi Nakamoto in
 - [BUwiki](//github.com/bitcoin-unlimited/BUwiki)
 - and more...
 
-In early 2019, Jonathan Silverblood proposed BUIP121, "Create formal BCH specifications", to Bitcoin Unlimited. Soon after, the proposal and an initial budget were approved. Later in 2019 at the Bitcoin Cash City conference in Townsville, QLD Australia, some members of the BCH development community, including Johnathon Silverblood, John Nieri, Josh Ellithorpe, and Mark Lundeberg approached Josh Green of Software Verde to lead the effort of a consolidated descriptive specification for the protocol. After the conference concluded, Software Verde approached Bitcoin Unlimited with an implementation proposal and it was accepted by Andrew Clifford and Andrew Stone. The proposal includes the work of Andrew Stone who had previously started BUwiki with similar objectives.
+In early 2019, Jonathan Silverblood proposed BUIP121, "Create formal BCH specifications", to Bitcoin Unlimited.
+Soon after, the proposal and an initial budget were approved.
+Later in 2019 at the Bitcoin Cash City conference in Townsville, QLD Australia, some members of the BCH development community, including Johnathon Silverblood, John Nieri, Josh Ellithorpe, and Mark Lundeberg approached Josh Green of Software Verde to lead the effort of a consolidated descriptive specification for the protocol.
+After the conference concluded, Software Verde approached Bitcoin Unlimited with an implementation proposal and it was accepted by Andrew Clifford and Andrew Stone.
+The proposal includes the work of Andrew Stone who had previously started BUwiki with similar objectives.
 
 With the funding provided by Bitcoin Unlimited, the Bitcoin Cash Protocol project began as a collaboration within the community, directed by Josh Green in December of 2019.

protocol/blockchain/hash.md

@@ -1,25 +1,38 @@
-# Hashes
+# Hash
 
-A variety of hashing algorithms are used throughout the Bitcoin Cash protocol.  In this specification we will not get into what hashes are, nor the details of the specific hashing algorithms used, as that is covered well elsewhere.  Instead, this page will focus on which hashing algorithms are used, where they are used, and why they are used there.
+A variety of hashing algorithms are used throughout the Bitcoin Cash protocol.
+This specification does not explain what hashes are, nor the details of the specific hashing algorithms used, as that is covered well elsewhere.
+Instead, this page will focus on which hashing algorithms are used, where they are used, and why they are used there.
 
 ## SHA-256
  
-[SHA-256](https://en.wikipedia.org/wiki/SHA-2) is widely used throughout the Bitcoin Cash protocol to identify blocks and transactions along with a variety of purposes in transaction scripts.  The most notable uses of SHA-256 are:
+[SHA-256](https://en.wikipedia.org/wiki/SHA-2) is widely used throughout the Bitcoin Cash protocol to identify blocks and transactions along with a variety of purposes in transaction scripts.
+The most notable uses of SHA-256 are:
 
  - Block Hashing (Double SHA-256)
-	 - A SHA-256 hash is taken of the block header.  The output hash is then hashed again with SHA-256.  This resultant hash is referred to simply as the block hash and is used as a unique identifier for the block.
+	 - A SHA-256 hash is taken of the block header.
-	 - This double hash removes the possibility of a [length extension attack](https://en.wikipedia.org/wiki/Length_extension_attack) which a single SHA-256 is vulnerable to.  While this is generally not a problem for Bitcoin Cash since the pre-image (the actual data of the block) is available, it trades a minor amount of inefficiency for confidence that this property of SHA-256 cannot be exploited.
+The output hash is then hashed again with SHA-256.
-	 - Double SHA-256 has it's own operation for ease-of-use, [OP_HASH256](/protocol/blockchain/script/opcodes/op-hash256)
+This resultant hash is referred to simply as the block hash and is used as a unique identifier for the block.
+	 - This double hash removes the possibility of a [length extension attack](https://en.wikipedia.org/wiki/Length_extension_attack) which a single SHA-256 is vulnerable to.
+While this is generally not a problem for Bitcoin Cash since the pre-image (the actual data of the block) is available, it trades a minor amount of inefficiency for confidence that this property of SHA-256 cannot be exploited.
+	 - Double SHA-256 has its own Bitcoin [Script](/protocol/blockchain/script) operation for ease-of-use, [OP_HASH256](/protocol/blockchain/script/opcodes/op-hash256)
  - Transaction Hashing (Double SHA-256)
-	 - Transactions are also hashed using a double application of SHA-256.  This is referred to as the transaction hash and is used to uniquely identify the transaction.  (NOTE: Historical transaction hashes are not universally unique, there are two sets of two identical coinbase transactions and thus repeated hashes.  Since [BIP-34](/protocol/forks/bip-0034), the block height is now required to be in the coinbase transaction, so this should not be possible in the future.)
+	 - Transactions are also hashed using a double application of SHA-256.
+This is referred to as the transaction hash and is used to uniquely identify the transaction.
+(NOTE: Historical transaction hashes are not universally unique, there are two sets of two identical coinbase transactions (and thus identical hashes).
+Since [BIP-34](/protocol/forks/bip-0034), the block height is now required to be in the coinbase transaction, which drastically reduces the possibility of duplicate transaction hashes in the future.)
 	 - The two cases where this occurred are the following transactions which each appear in two blocks:
-		 - <code>D5D27987D2A3DFC724E359870C6644B40E497BDC0589A033220FE15429D88599</code>
+		 - `D5D27987D2A3DFC724E359870C6644B40E497BDC0589A033220FE15429D88599`
-		 - <code>E3BF3D07D4B0375638D5F1DB5255FE07BA2C4CB067CD81B84EE974B6585FB468</code>
+		 - `E3BF3D07D4B0375638D5F1DB5255FE07BA2C4CB067CD81B84EE974B6585FB468`
 
 ## RIPEMD-160
  
-[RIPEMD-160](https://en.wikipedia.org/wiki/RIPEMD) is used in Bitcoin Cash scripts to create short, quasi-anonymous representations of payees for transactions.  Since its brevity is also a potential liability for the anonymity it provides (since shorter hashes generally provide less collision-resistance), it is used in conjunction with SHA-256 when generating an address from a public key.  That is, <code>(public key) -> SHA-256 -> RIPEMD-160 -> (address)</code>.  This SHA-256 then RIPEMD-160 process has its own operation for ease-of-use, [OP_HASH160](/protocol/blockchain/script/op-codes/op-hash160).
+[RIPEMD-160](https://en.wikipedia.org/wiki/RIPEMD) is used in Bitcoin Cash scripts to create short, quasi-anonymous representations of payees for transactions.
+Since its brevity is also a potential liability for the anonymity it provides (since shorter hashes generally provide less collision-resistance), it is used in conjunction with SHA-256 when generating an address from a public key.
+That is, `(public key) -> SHA-256 -> RIPEMD-160 -> (address)`.
+This SHA-256 then RIPEMD-160 process has its own operation for ease-of-use, [OP_HASH160](/protocol/blockchain/script/op-codes/op-hash160).
  
 ## Murmur
 
-[MurmurHash](https://en.wikipedia.org/wiki/MurmurHash) is used in Bitcoin to support [Bloom filters](https://en.wikipedia.org/wiki/Bloom_filter).  The specific version used is the MurmurHash version 3 (32-bit), with the first hash initialized to <code>(numberOfHashesRequired * 0xFBA4C795L + nonce)</code> where <code>nonce</code> is a randomly chosen 32-bit unsigned integer.
+[MurmurHash](https://en.wikipedia.org/wiki/MurmurHash) is used in Bitcoin to support [Bloom filters](https://en.wikipedia.org/wiki/Bloom_filter).
+The specific version used is the MurmurHash version 3 (32-bit), with the first hash initialized to `(numberOfHashesRequired * 0xFBA4C795L + nonce)` where `nonce` is a randomly chosen 32-bit unsigned integer.

protocol/blockchain/transaction.md

@@ -1,6 +1,13 @@
 # Transaction
 
-A transaction is how transfers are made in the blockchain. It comprises of a set of [transaction inputs](#transaction-inputs) which will be spent to a set of [transaction outputs](#transaction-outputs). The blockchain mining and full node software ensures that every transaction follows the blockchain's rules before admitting the transaction into a block. Verification of a transaction ensures that the inputs have not already been spent, that the total number of satoshis, the smallest quantity of Bitcoin Cash, provided as input is greater than or equal to the number of satoshis output (any extra is given to the miner as a transaction fee), and that the transaction is syntactically and cryptographically valid.
+A Transaction is how bitcoins are transferred on the blockchain.
+It comprises of a set of [Transaction Inputs](#transaction-inputs) which will be spent to a set of [Transaction Outputs](#transaction-outputs).
+The mining nodes and full node software ensures that every transaction follows the blockchain's rules before admitting a transaction into a block.
+
+Verification of a transaction ensures that:
+- The Transaction Inputs have not already been spent.
+- The total value contained in the Transaction Inputs is greater than (or equal) to the value specified within the Transaction Outputs.
+- The Transaction is syntactically and cryptographically valid, and that the previous Unspent Transaction Outputs' [Locking Script](/protocol/blockchain/transaction/locking-script)s are correctly unlocked via the Transaction Inputs' [Unlocking Script](/protocol/blockchain/transaction/unlocking-script).
 
 ## Format
 
@@ -15,7 +22,10 @@ A transaction is how transfers are made in the blockchain. It comprises of a set
 
 ## Transaction Inputs
 
-Transaction inputs are the "debits" of Bitcoin Cash and not only designate the satoshis that will be transferred as a part of the transaction, but they also provide proof of ownership via the [unlocking script](/protocol/blockchain/transaction/unlocking-script).  A transaction input references a unspent transaction output, or UTXO, from a prior transaction.  If a transaction would like to spend multiple UTXOs, it must have multiple inputs, one for each UTXO.
+Transaction inputs are the "debits" of Bitcoin Cash and not only designate the satoshis that will be transferred as a part of the transaction, but they also provide proof of ownership via the [Unlocking Script](/protocol/blockchain/transaction/unlocking-script).
+A Transaction Input references an unspent Transaction Output (oftern referred to as a "UTXO"), from a prior transaction.
+If a Transaction would like to spend multiple UTXOs, it must have multiple inputs, one for each UTXO.
+The Transaction Output that is being spent by a Transaction Input is often referred to as the "PrevOut", short for the "Previous Output".
 
 ### Format
 
@@ -28,7 +38,11 @@ Transaction inputs are the "debits" of Bitcoin Cash and not only designate the s
 
 ## Transaction Outputs
 
-Transaction outputs are the "credits" of Bitcoin Cash.  Each transaction output denotes a number of satoshis and the requirements are spending them.  These requirements take the form of a [locking script](/protocol/blockchain/transaction/locking-script) and can equate to anything from the satoshis only being spendable by the owner of a specific private key, to anyone being able to spend them, to no one being able to spend them.  While a transaction output has not been spent by another transaction (i.e. had its locking script "unlocked" by an input of a valid transaction) it is referred to as an unspent transaction output, or UTXO.  After the output has been spent, it is referred to as a previous output, or PrevOut.
+Transaction outputs are the "credits" of Bitcoin Cash.
+Each transaction output denotes a number of satoshis and the requirements are spending them.
+These requirements take the form of a [locking script](/protocol/blockchain/transaction/locking-script) and can equate to anything from the satoshis only being spendable by the owner of a specific private key, to anyone being able to spend them, to no one being able to spend them.
+While a transaction output has not been spent by another transaction (i.e. had its locking script "unlocked" by an input of a valid transaction) it is referred to as an unspent transaction output, or UTXO.
+A Transaction Output that is being spent by a Transaction Input is often referred to as the "PrevOut", short for the "Previous Output".
 
 ### Format
 
@@ -37,3 +51,7 @@ Transaction outputs are the "credits" of Bitcoin Cash.  Each transaction output
 | value | 8 bytes | unsigned integer<sup>[(LE)](/protocol/misc/endian/little)</sup> | The number of satoshis to be transferred. |
 | locking script length | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the unlocking script in bytes. |
 | locking script | variable | bytes<sup>[(BE)](/protocol/misc/endian/big)</sup> | The contents of the locking script. |
+
+## Transaction Fees
+
+Extra satoshis from the Transaction Inputs that are not accounted for in the Transaction Outputs may be collected by the miner as the transaction fee.

target-audience.md

@@ -1,6 +1,7 @@
 # Target Audience
 
-This specification is intended to meet a variety of needs, depending on their level of comfort with the material involved.  In order of precedence, the goal of this specification is to meet the needs of:
+This specification is intended to meet a variety of needs, depending on their level of comfort with the material involved.
+In order of precedence, the goal of this specification is to meet the needs of:
 
  - Node Developers
 	 - Provide all the details necessary to write a Bitcoin Cash Node implementation from scratch.