minor comma, spacing, and wording adjustments

1 files changed, 9 insertions, 4 deletions

diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki
index 3667f4c..02de20b 100644
--- a/bip-0065.mediawiki
+++ b/bip-0065.mediawiki
@@ -40,7 +40,7 @@ An example where this technique is used is in micro-payment channels, where the
 nLockTime field proves that should the receiver vanish the sender is guaranteed
 to get all their escrowed funds back when the nLockTime is reached.
 
-However the nLockTime field is insufficient if you wish to prove that
+However, the nLockTime field is insufficient if you wish to prove that a
 transaction output ''cannot'' be spent until some time in the future, as there
 is no way to prove that the secret keys corresponding to the pubkeys controlling
 the funds have not been used to create a valid signature.
@@ -60,7 +60,7 @@ either Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer
 not to have immediate access to the funds to discourage bad actors from
 attempting to get the secret keys from him by force.
 
-However with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of
+However, with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of
 the form:
 
     IF
@@ -86,12 +86,12 @@ funds with the following scriptSig:
 
 There exist a number of protocols where a transaction output is created that
 requires the co-operation of both parties to spend the output. To ensure the
-failure of one party does not result in the funds becoming lost refund
+failure of one party does not result in the funds becoming lost, refund
 transactions are setup in advance using nLockTime. These refund transactions
 need to be created interactively, and additionaly, are currently vulnerable to
 transaction mutability. CHECKLOCKTIMEVERIFY can be used in these protocols,
 replacing the interactive setup with a non-interactive setup, and additionally,
-making transaction mutability a non-issue.
+making transaction mutability (aka malleability) a non-issue.
 
 
 ====Two-factor wallets====
@@ -171,6 +171,7 @@ assuming miners behave optimally and rationally) but only at a time
 sufficiently far into the future that large miners profitably can't sell the
 sacrifices at a discount.
 
+
 ===Freezing Funds===
 
 In addition to using cold storage, hardware wallets, and P2SH multisig outputs
@@ -181,6 +182,7 @@ be useful in scenarios where reducing duress or confiscation risk is desired.
 
     <expiry time> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG
 
+
 ===Replacing the nLockTime field entirely===
 
 As an aside, note how if the SignatureHash() algorithm could optionally cover
@@ -280,12 +282,14 @@ Thanks goes to Gregory Maxwell for suggesting that the argument be compared
 against the per-transaction nLockTime, rather than the current block height and
 time.
 
+
 ==References==
 
 PayPub - https://github.com/unsystem/paypub
 
 Jeremy Spilman Micropayment Channels - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html
 
+
 ==Implementations==
 
 Python / python-bitcoinlib
@@ -296,6 +300,7 @@ JavaScript / Node.js / bitcore
 
 - https://github.com/mruddy/bip65-demos
 
+
 ==Copyright==
 
 This document is placed in the public domain.