Fixes to 0134

bip-0134.mediawiki

@@ -66,7 +66,7 @@ a transaction.
 CMF tokens are triplets of name, format (like PositiveInteger) and value.
 Names in this scope are defined much like an enumeration where the actual
 integer value (id, below) is equally important to the written name.
-If any token found that is not covered in the next table will make the
+If any token found that is not covered in the next table it will make the
 transaction that contains it invalid.
 
 {| class="wikitable"
@@ -81,7 +81,7 @@ transaction that contains it invalid.
 |-
 |TxInScript    ||  3 ||ByteArray||  Required    ||The 'input' part of the script
 |-
-|TxOutValue    ||  4 ||Integer  ||  Required    ||Amount of satoshi to transfer
+|TxOutValue    ||  4 ||Integer  ||  Required    ||Amount of Satoshis to transfer
 |-
 |TxOutScript   ||  5 ||ByteArray||  Required    ||The 'output' part of the script
 |-
@@ -164,7 +164,7 @@ version it would be placed in the outputs segment.
 === Script v2 ===
 
 The default value of ScriptVersion is number 2, as opposed to the version 1
-of script that the is in use today.  The version 2 is mostly identical
+of script that is in use today.  The version 2 is mostly identical
 to version one, including upgrades made to it over the years and in the 
 future. The only exception is that the OP_CHECKSIG is made dramatically
 simpler.  The input-type for OP_CHECKSIG is now no longer configurable, it is
@@ -184,9 +184,9 @@ modifications to such signatures outside of validating all transactions.
 
 For this reason the merkle tree is extended to include (append) the hash of
 the v4 transactions. The markle tree will continue to have all the
-transactions' tx-ids but appended to that are the v4 hahes that include the
+transactions' tx-ids but appended to that are the v4 hashes that include the
 signatures as well.  Specifically the hash is taken over a data-blob that
-is build up from:
+is built up from:
 
 1. the tx-id
 2. the CMF-tokens 'TxInScript'
@@ -215,7 +215,7 @@ SPV (simple payment validation) wallets need to be updated to receive or
 create the new transaction type.
 
 This BIP introduces a new transaction format without changing or
-deprecating the existing one or any of its practices. Therefor it is
+deprecating the existing one or any of its practices. Therefore it is
 backwards compatible for any existing data or parsing-code.
 
 ==Reference Implementation==
@@ -238,7 +238,8 @@ To be determined
 
 Copyright (c) 2016 Tom Zander <tomz@freedommail.ch>
 
-This document is licensed under the Open Publication License v1.0
+This document is dual-licensed under the Creative-Commons BY-SA license v4.0
+and the Open Publication License v1.0 with the following licence-options:
 
 Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.
 Distribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder.