diff --git a/bip-hashrate-escrows.mediawiki b/bip-hashrate-escrows.mediawiki
index 74380251..26ed32e8 100644
--- a/bip-hashrate-escrows.mediawiki
+++ b/bip-hashrate-escrows.mediawiki
@@ -1,5 +1,3 @@
-
-
 <pre>
     BIP: ????
     Layer: Consensus (soft fork)
@@ -144,7 +142,7 @@ D1 is updated via M1 and M2.
 ==== New Block Validation Rules ====
 
 
-# Escrows are added in a procedure that resembles BIP 9 soft fork activation: the network must see a properly-formatted M1, followed by "acknowledgement" of the sidechain in 95% of the following 2016 blocks.
+# Escrows are added in a procedure that resembles BIP 9 soft fork activation: the network must see a properly-formatted M1, followed by "acknowledgment" of the sidechain in 95% of the following 2016 blocks.
 # It is possible to "overwrite" an escrow. This requires 6 months (26298 blocks) of M2s, instead of 2 weeks (XXXX). This possibility does not change the security assumptions (because we already assume that users perform extra-protocolic validation at a rate of 1 bit per 26298 blocks).
 
 
@@ -214,9 +212,9 @@ From one block to the next, "ACKs" can only change as follows:
 
 * The ACK-counter of any withdrawal can only change by (-1,0,+1).
 * Within a sidechain-group, upvoting one withdrawal ("+1") requires you to downvote all other withdrawals in that group. However, the minimum ACK-value is zero (and, therefore, downvotes cannot reduce it below zero).
-* While only one withdrawal can be upvoted at once, they can all be unchangd at once ("abstain") and they can all be downvoted at once ("alarm").
+* While only one withdrawal can be upvoted at once, they can all be unchanged at once ("abstain") and they can all be downvoted at once ("alarm").
 
-One option for explict transmission of M4 is:
+One option for explicit transmission of M4 is:
 
     4-byte - Message identifier (0x????????)
     1-byte - Version of this message
@@ -253,7 +251,7 @@ We come, finally, to the critical matter: where users can take their money *out*
 
 In each block, a withdrawal in D2 is considered "approved" if its "ACKs" value meets the threshold (13,150).
 
-Approved withdrawals give the green light to their respective "WT^". A "WT^" is 32-bytes which aspire to represent the withdrawing transtion (the txn that actually withdraws funds from the escrow). The two cannot match exactly, beacuse "WT^" is defined at onset, and the withdrawing TxID depends on the its CTIP input (which is constantly changing).
+Approved withdrawals give the green light to their respective "WT^". A "WT^" is 32-bytes which aspire to represent the withdrawing transaction (the txn that actually withdraws funds from the escrow). The two cannot match exactly, because "WT^" is defined at onset, and the withdrawing TxID depends on the its CTIP input (which is constantly changing).
 
 To solve this, we define a "blinded TxID" as a way of hashing a txn, in which some bytes are first overwritten with zeros. Specifically, these bytes are the first input and the first output.