Include grammar fixes from Dawn

1 files changed, 12 insertions, 11 deletions

diff --git a/bip-invoicerequest-extension.mediawiki b/bip-invoicerequest-extension.mediawiki
index 2c0e787..0fc8339 100644
--- a/bip-invoicerequest-extension.mediawiki
+++ b/bip-invoicerequest-extension.mediawiki
@@ -14,20 +14,27 @@
 
 This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol.
 
-# It allows the requestor of a Payment Request to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with. 
+# It allows the requestor (Sender) of a Payment Request to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with. 
 
 # It encrypts the Payment Request that is returned, before handing it off to the SSL/TLS layer to prevent man in the middle viewing of the Payment Request details.
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
 "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
 
+==Definitions==
+{| class="wikitable"
+| Sender    || Entity wishing to transfer value that they control
+|-
+| Receiver  || Entity receiving a value transfer
+|}
+
 ==Motivation==
 
 The motivation for defining this extension to the BIP70 Payment Protocol is to allow 2 parties to exchange payment information in a permissioned and encrypted way such that wallet address communication can become a more automated process. Additionally, this extension allows for the requestor of a PaymentRequest to supply a certificate and signature in order to facilitate identification for address release. This also allows for automated creation of off blockchain transaction logs that are human readable, containing who you transacted with, in addition to the information that it contains today.
 
 The motivation for this extension to BIP70 is threefold:
 
-# Ensure that the payment details can only be seen by the participants in the transaction, and not any third party.  
+# Ensure that the payment details can only be seen by the participants in the transaction, and not by any third party.  
 
 # Enhance the Paument Protocol to allow for store and forward servers in order to allow, for example, mobile wallets to sign and serve Payment Requests.
 
@@ -41,13 +48,6 @@ The motivation for this extension to BIP70 is threefold:
 
 In short we wanted to make bitcoin more human, while at the same time improving transaction privacy.
 
-==Definitions==
-{| class="wikitable"
-| Sender    || Entity wishing to transfer value that they control
-|-
-| Receiver  || Entity receiving a value transfer
-|}
-
 ==Example Use Cases==
 
 1. Address Book
@@ -56,7 +56,7 @@ Let's say a Bitcoin wallet developer would like to offer the ability to store an
 send multiple payments to known entities without having to request an address every time. Static addresses compromise 
 privacy, and address reuse is considered a security risk. BIP32 X-Pubs allow the generation of unique addresses, but 
 watching an X-Pub chain for each person you wish to receive funds from is too resource-intensive for mobile applications, 
-and there is always the risk of unknowingly sending funds to an X-Pub address after the owner has lost access to the 
+and there is always a risk of unknowingly sending funds to an X-Pub address after the owner has lost access to the 
 corresponding private key.
 
 With this BIP, Bitcoin wallets could maintain an "address book" that only needs to store each payee's public key. Adding 
@@ -68,7 +68,7 @@ or destroyed, no communication will be possible, and the sending of funds to a "
 2. Individual Permissioned Address Release
 
 Let's say a Bitcoin wallet developer would like to offer the ability for a user to individually release address information 
-to a new potential sending party only if they can confirm the identity of the potential sending party. BIP70 specifies that 
+to a new potential sending party only if they can confirm the identity of the potential sending party. Currently, BIP70 specifies that 
 the Merchant Server respond to a "pay now" style request with a PaymentRequest, releasing address and X.509 certificate identity 
 information of the potential receiving party.
 
@@ -311,3 +311,4 @@ of an InvoiceRequest, a Store & Forward server, and a EncryptedPaymentRequest.
 * [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman ECDH]
 * [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG]
 * [https://tools.ietf.org/html/rfc6979 RFC6979]
+* [https://en.bitcoin.it/wiki/Address_reuse Address Reuse]