typos

Author: psztorc

bip-blind-merged-mining.mediawiki

@@ -194,12 +194,13 @@ M8_V1 does not require the Lightning network but does have new requirements for
 
 A M8_V1 TxOut is expected to contain:
 
+<pre>
     1-byte - OP_RETURN (0x6a)
     1-byte - Push the following 36 bytes (0x24)
     4-byte - Message header (0xD1617368)
     32-bytes  - h* side:block hash
     5~7-bytes - BMM request identifying bytes (0x00bf00) + prevBlockRef & ChainIndex (sidechain mini-header)
-    
+</pre>
 
 In the first version of M8, we need to introduce the concept of Immediate Expiration (see above). In other words, we need a way for Simon to construct many payments to multiple Marys, such that only one of these is ever included; and only then if Simon's txn is expected to coincide with the finding of Simon's side:block.
 
@@ -225,17 +226,19 @@ Interestingly, these payments (M8) will *always* be directed to miners from non-
 
 ===== M8_V2 With Lightning =====
 
-M8_V2 requires having a LN-channel open with a miner. This may not always be practical (or even possible), especially today.
+M8_V2 requires having a LN-channel pathway open with a miner. This may not always be practical (or even possible), especially today.
 
 A M8_V1 TxOut is expected to contain:
 
+<pre>
     1-byte - OP_RETURN (0x6a)
     1-byte - Push the following 68 bytes (0x44)
     4-byte - Message header (0xD0520C6E)
     32-bytes  - h* side:block hash
     32-bytes  - prevSideBlockHash
     5~7-bytes - BMM request identifying bytes (0x00bf00) + prevBlockRef & ChainIndex (sidechain mini-header)
-    
+</pre>
+
 
 Notice that, in M8_V1, Simon could reuse the same h\* all he wanted, because only one M8_V1 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* M8s. So, we will never know what the M8s were or how many had an effect on anything.