spellcheck

1 files changed, 8 insertions, 10 deletions

diff --git a/bip-blind-merged-mining.mediawiki b/bip-blind-merged-mining.mediawiki
index ffa883a..7f29f06 100644
--- a/bip-blind-merged-mining.mediawiki
+++ b/bip-blind-merged-mining.mediawiki
@@ -1,4 +1,3 @@
-
 <pre>
 
     BIP: 301
@@ -49,7 +48,7 @@ To buy the right to find a sidechain block, users broadcast BMM Requests.
 
 Here, these can take two forms. The first does not require the Lightning Network, but it does have new requirements for Immediate Expiration (see below). The second inherits Immediate Expiration from the Lightning Network itself, but requires extra preparation and a different/larger message.
 
-Both forms require that certain Critical Data will be committed to within the coinbase of the block that the transaction is included in (see BMM Accept). For the OnChain (non-Lightning) version, we have created a new extended serialization transaction type (very similar to how segwit handles witness data (the witness stack)).
+Both forms require that certain Critical Data will be committed to within the coinbase of the block that the transaction is included in (see BMM Accept). For the OnChain (non-Lightning) version, we have created a new extended serialization transaction type (very similar to how SegWit handles witness data (the witness stack)).
 
 ==== Immediate Expiration ("Fill-or-Kill") ====
 
@@ -78,7 +77,7 @@ sideHeaderHash comes from side:chain (side:nodes build side:blocks/headers). The
 
 prevBlockRef, is a little more complicated (next section). 
 
-To qualify for inclusion in a block, BMM requests are subject to the following reqirements:
+To qualify for inclusion in a block, BMM requests are subject to the following requirements:
 
 # Requests must match a corresponding "BMM Accept" (see last section of BIP).
 # At most, only one Request is allowed in a main:block, per sidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner must choose one single Request to include.
@@ -94,7 +93,7 @@ Above: Three blockchains, with different max length (small number), reorganizati
 
 ===== Extended Serialization =====
 
-To impose new requirements at the transaction level, we borrow the dummy vin & "flag" trick from SegWit style transactions. Unless all of the requirements for sidechain critical data transactions are met by the block it is included in, the transaction is invalid. With SegWit, this extra data is the segwit signature stack, and the extra requirements are the signatures' locations and validity. In the sidechain BMM critical data transactions, the extra data is the (nSidechain, h\*) pair, which must meet the first two requirements (above) as well as the main:blocknumber, which must meet the third requirement (above).
+To impose new requirements at the transaction level, we borrow the dummy vin & "flag" trick from SegWit style transactions. Unless all of the requirements for sidechain critical data transactions are met by the block it is included in, the transaction is invalid. With SegWit, this extra data is the SegWit signature stack, and the extra requirements are the signatures' locations and validity. In the sidechain BMM critical data transactions, the extra data is the (nSidechain, h\*) pair, which must meet the first two requirements (above) as well as the main:blocknumber, which must meet the third requirement (above).
 
 <img src="bip-blind-merged-mining/witness-vs-critical.png?raw=true" align="middle"></img>
 
@@ -110,11 +109,11 @@ Lightning BMMRs require Simons to have a LN-channel pathways open with Marys. Th
 
 LN txns cannot make use of prevSideBlockRef, as no one knows for sure when (or if) they will be broadcast on-chain. Instead, they must use prevSideBlockHash. But they otherwise require the same data:
 
-<pre>	
-    4-bytes - Message header (0xD0520C6E)	
+<pre>   
+    4-bytes - Message header (0xD0520C6E)   
     1-byte - sidechain number
-    32-bytes  - h* side:block hash	
-    32-bytes  - prevSideBlockHash	
+    32-bytes  - h* side:block hash  
+    32-bytes  - prevSideBlockHash   
 </pre>
 
 Notice that, in OnChain BMMRs, Simon could reuse the same h\* all he wanted, because only one OnChain BMMR could be included per main:block per sidechain. However, on the LN no such rule can be enforced, as the goal is to push everything off-chain and include *zero* txns. So, we will never know what the Requests were, or how many had an effect on anything.
@@ -173,7 +172,7 @@ Now that we have described Requests, we can describe how they are accepted.
 
 === BMM Accept ===
 
-For each BMM Request that a main:miner "accepts", main:miners must place an OP Return ouput into their main:coinbase txn. (We've changed the tx-standardness policy to allow multiple OP_RETURNs.)
+For each BMM Request that a main:miner "accepts", main:miners must place an OP Return output into their main:coinbase txn. (We've changed the tx-standardness policy to allow multiple OP_RETURNs.)
 
 The following data is required in the "accept" OP_RETURN output:
     1-byte - OP_RETURN (0x6a)
@@ -233,4 +232,3 @@ Thanks to everyone who contributed to the discussion, especially: ZmnSCPxj, Adam
 ==Copyright==
 
 This BIP is licensed under the BSD 2-clause license.
-