Merge pull request #1505 from GoodDaisy/master

Fix typos

bip-0088.mediawiki

@@ -89,7 +89,7 @@ installation of malicious or incorrect profiles, though.
 
 ==Specification==
 
-The format for the template was choosen to make it easy to read, convenient and visually unambigous. 
+The format for the template was chosen to make it easy to read, convenient and visually unambigous. 
 
 Template starts with optional prefix <code>m/</code>, and then one or more sections delimited by the slash character (<code>/</code>).
 
@@ -127,13 +127,13 @@ Constraints:
 # To avoid ambiguity, an index range that matches a single value MUST be specified as Unit range.
 # To avoid ambiguity, an index range <code>0-2147483647</code> is not allowed, and MUST be specified as Wildcard index template instead
 # For Non-unit range, range_end MUST be larger than range_start.
-# If there is more than one index range within the Ranged index template, range_start of the second and any subsequent range MUST be larger than the range_end of the preceeding range.
+# If there is more than one index range within the Ranged index template, range_start of the second and any subsequent range MUST be larger than the range_end of the preceding range.
 # To avoid ambiguity, all representations of integer values larger than 0 MUST NOT start with character <code>0</code> (no leading zeroes allowed).
 # If hardened marker appears within any section in the path template, all preceding sections MUST also specify hardened matching.
 # To avoid ambiguity, if a hardened marker appears within any section in the path template, all preceding sections MUST also use the same hardened marker (either <code>h</code> or <code>'</code>).
 # To avoid ambiguity, trailing slashes (for example, <code>1/2/</code>) and duplicate slashes (for example, <code>0//1</code>) MUST NOT appear in the template.
 
-It may be desireable to have fully unambiguous encoding, where for each valid path template string, there is no other valid template string that matches the exact same set of paths. This would enable someone to compare templates for equality through a simple string equality check, without any parsing.
+It may be desirable to have fully unambiguous encoding, where for each valid path template string, there is no other valid template string that matches the exact same set of paths. This would enable someone to compare templates for equality through a simple string equality check, without any parsing.
 
 To achieve this, two extra rules are needed:
 

bip-0152.mediawiki

@@ -211,7 +211,7 @@ There are several design goals for the Short ID calculation:
 
 SipHash is a secure, fast, and simple 64-bit MAC designed for network traffic authentication and collision-resistant hash tables. We truncate the output from SipHash-2-4 to 48 bits (see next section) in order to minimize space. The resulting 48-bit hash is certainly not large enough to avoid intentionally created individual collisons, but by using the block hash as a key to SipHash, an attacker cannot predict what keys will be used once their transactions are actually included in a relayed block. We mix in a per-connection 64-bit nonce to obtain independent short IDs on every connection, so that even block creators cannot control where collisions occur, and random collisions only ever affect a small number of connections at any given time. The mixing is done using SHA256(block_header || nonce), which is slow compared to SipHash, but only done once per block. It also adds the ability for nodes to choose the nonce in a better than random way to minimize collisions, though that is not necessary for correct behaviour. Conversely, nodes can also abuse this ability to increase their ability to introduce collisions in the blocks they relay themselves. However, they can already cause more problems by simply refusing to relay blocks. That is inevitable, and this design only seeks to prevent network-wide misbehavior.
 
-====Random collision probabilty====
+====Random collision probability====
 
 Thanks to the block-header-based SipHash keys, we can assume that the only collisions on links between honest nodes are random ones.
 

bip-0176.mediawiki

@@ -16,7 +16,7 @@ Bits is presented here as the standard term for 100 (one hundred) satoshis or 1/
 == Motivation ==
 The bitcoin price has grown over the years and once the price is past $10,000 USD or so, bitcoin amounts under $10 USD start having enough decimal places that it's difficult to tell whether the user is off by a factor of 10 or not. Switching the denomination to "bits" makes comprehension easier. For example, when BTC is $15,000 USD, $10.05 is a somewhat confusing 0.00067 BTC, versus 670 bits, which is a lot clearer.
 
-Additonally, reverse comparisons are easier as 59 bits being $1 is easier to comprehend for most people than 0.000059 BTC being $1. Similar comparisons can be made to other currencies: 1 yen being 0.8 bits, 1 won being 0.07 bits and so on.
+Additionally, reverse comparisons are easier as 59 bits being $1 is easier to comprehend for most people than 0.000059 BTC being $1. Similar comparisons can be made to other currencies: 1 yen being 0.8 bits, 1 won being 0.07 bits and so on.
 
 Potential benefits of utilizing "bits" include:
 

bip-0300.mediawiki

@@ -290,7 +290,7 @@ For example: if there are two sidechains, and we wish to upvote the 7th bundle o
 The version number allows us to shrink the upvote vector in many cases.
 Version 0x00 omits the upvote vector entirely (ie, 6 bytes for the whole M4) and sets this block's M4 equal to the previous block's M4.
 Version 0x01 uses one byte per sidechain, and can be used while all ACKed withdrawals have an index under 256 (ie, 99.99%+ of the time).
-Version 0x02 uses a full two bytes per sidechain (each encoded in little endian), but it always works no matter how many withdrawl proposals exist.
+Version 0x02 uses a full two bytes per sidechain (each encoded in little endian), but it always works no matter how many withdrawal proposals exist.
 Version 0x03 omits the upvote vector, and instead upvotes only those withdrawals that are leading their rivals by at least 50 votes.
 
 If a sidechain has no pending bundles, then it is skipped over when M4 is created and parsed.
@@ -465,7 +465,7 @@ M2: 1 get, 1 delete, 1 create
 M3: 3 get, 1 delete, 2 create, 2 hash
   for each coinbase output: search for prior M3 for this sidechain
   lookup if M3 was ever rejected or paid in the past
-  for each prior proposed withdrawl: (included in 1 get+delete+create)
+  for each prior proposed withdrawal: (included in 1 get+delete+create)
 M4: 1 get
   + for every proposed withdraw, 1 get, 1 delete, 1 create, 1 add
   v0 needs to read and parse previous block

bip-0330.mediawiki

@@ -210,7 +210,7 @@ The reconcildiff message is used by reconciliation initiator to announce transac
 | uint32[] || ask_shortids || The short IDs that the sender did not have.
 |}
 
-Upon receipt a "reconcildiff" message with ''success=1'' (reconciliation success), a node sends an "inv" message for the transactions requested by 32-bit IDs (first vector) containing their wtxids (with parent transactions occuring before their dependencies).
+Upon receipt a "reconcildiff" message with ''success=1'' (reconciliation success), a node sends an "inv" message for the transactions requested by 32-bit IDs (first vector) containing their wtxids (with parent transactions occurring before their dependencies).
 If ''success=0'' (reconciliation failure), receiver should announce all transactions from the reconciliation set via an "inv" message.
 In both cases, transactions the sender of the message thinks the receiver is missing are announced via an "inv" message.
 The regular "inv" deduplication should apply.