PIP-0041:typos and grammar fixes + improvements

PIP/PIP-0041.md

@@ -15,15 +15,15 @@ This PIP proposes solution to a fundamental problem in PascalCoin; how first-tim
 
 ## Motivation
 
-One of the issues with PascalCoin is that new users require an account (PASA) before they can receive PASC. This is known as the "first PASA problem" and is an chicken-and-egg type problem. In all other cryptocurrencies, first-time users can receive their first coins simply by giving the sender their "address". In PascalCoin, a new user that wants to receive PASC for the first time is unable to give an address because they do have an account.  Instead, they must first acquire an account (PASA). This process typically comprises of them scratching their head, searching the internet for information, learning about PASA's and eventually contacting a 3rd party PASA dispenser (like [FreePasa.org](https://freepasa.org)) to get an account PASA. Only after requesting their account from a 3rd party and waiting 5 minutes for a blockchain confirmation can they finally possess an address to receive their PASC.
+One of the issues with PascalCoin is that new users require an account (PASA) before they can receive PASC. This is known as the "first PASA problem" and is an chicken-and-egg type problem. In all other cryptocurrencies, first-time users can receive their first coins simply by giving the sender their "address". In PascalCoin, a new user that wants to receive PASC for the first time is unable to give an address because they do have an account.  Instead, they must first acquire an account. This process typically comprises of them scratching their head, searching the internet for information, learning about PASA's and eventually contacting a 3rd party PASA dispenser (like [FreePasa.org](https://freepasa.org)) to get their account. Only after all that and waiting 5 minutes for a blockchain confirmation can they finally possess an address to give the sender in order to receive their PASC.
 
-Almost all user feedback on this workflow has been highly negative. Attempts to solve this issue (as Blaise app does) are still bad user experiences and complex. It's a well known principle of product design that onboarding new users should always be as easy and smooth as possible in order maximize the market penetration of that product. Thus it is clear that the "first PASA problem" is an impediment to PascalCoin's growth and needs to be solved. 
+Almost all user feedback on this workflow has been highly negative. Attempts to solve this issue (as Blaise app does) are still a bad user experience and overtly complex. It's a well known principle of product design that onboarding new users should always be as easy and smooth as possible in order maximize the market penetration of that product. Thus it is clear that the "first PASA problem" is an impediment to PascalCoin's growth and needs to be solved. 
 
-This PIP finally solves this problem. It provides first time users an **instant** receive address they can use immediately, just like Bitcoin. This is achieved through the use of E-PASA, Block Policy and a Buy Account operation. In this proposal, all users will be able to receive funds directly to their public key by virtue of an E-PASA of the form **@[1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2]** where their public key is encoded in a base-58 within the square brackets pre-fixed with an @ symbol.
+This PIP finally solves this problem. It provides first time users an **instant** receive address they can use immediately, just like Bitcoin. This is achieved through the use of E-PASA, Block Policy and a Buy Account operation. In this proposal, all users will be able to receive funds directly to their public key by virtue of an E-PASA of the form **@[1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2]**. Here the users public key is encoded in base-58 within square brackets pre-fixed with an @ symbol.
 
-This E-PASA will be translated under-the-hood to a "Buy Account" operation for **any floating** account available in the SafeBox. Floating accounts are very similar to "Public Sale Accounts" except they are owned by no one and have no seller.  The "sale price" for floating accounts is determined by an economic variable in the Block Policy called "New PASA Fee". This fee is "floating" in that it can change with the block policy. This allows the price of new  PASA to always be low enough to onboard new users but high enough to dissuade hoarding and abuse. This value is determined by the PascalCoin community through layer-1 governance (block policy).
+A transaction to to such an E-PASA is translated under-the-hood as a "Buy Account" operation for **any floating** account available in the SafeBox. Floating accounts are very similar to "Public Sale Accounts" except they are owned by no one and have no seller.  The "sale price" for floating accounts is determined by an economic variable in the Block Policy called "New PASA Fee". This fee is "floating" in that it can change with the block policy. This allows the price of new  PASA to always be low enough to onboard new users but high enough to dissuade hoarding and abuse. This value is determined by the PascalCoin community through a layer-1 governance system called [Block Policy][2].
 
-With the implementation of E-PASA, when sending transactions users can enter an E-PASA. Thus, by simply entering an E-PASA of the form above, the PascalCoin node can produce a "Pay to key" style Buy Account operation under-the-hood. This allows the sender to simply send to a recipient's account or key, as they desire. This is also true at the API-level.
+From the senders perspective, this solution requires no change to their workflow. With the implementation of E-PASA, when sending transactions the sender can enter an E-PASA recipient. Thus, by simply entering an E-PASA of the form described above, the PascalCoin node can automatically produce a "Pay to key" style Buy Account operation under-the-hood. Thus it allows a sender to sent to a recipient's account or key, as they desire. This is also true at the API-level where the API sender is an E-PASA and can perform a Pay to Key by virtue of the recipient's address alone without any other details.
 
 ## Specification
 
@@ -33,46 +33,48 @@ With the implementation of E-PASA, when sending transactions users can enter an
 
 A. New transaction sub-type called "buy floating account".
 
-B. Same logic as "buy account" except for the following changes:
+B. Implements same logic as "buy account" except for the following changes:
 
    B.1. The "account to buy" is 0 and ignored
    
    B.2. The "account to pay" is 0 and ignored (i.e. sellers account)
    
-C. On execution
+C. On execution,
 
-   C.1 The **first** PASA in the SafeBox with type "Floating" is selected as "account to buy"
+   C.1 The **first** PASA in the SafeBox with type "Floating" is selected as the "account to buy"
    
    C.2 The "Sale Price" for C.1 is taken from the Block Policy variable "New PASA Fee"
    
-   C.3 The account is purchased exactly the same except "account to pay" is credited 0 PASC (i.e. the New PASA Fee is **burned**).
+   C.3 The account is purchased in exactly the same manner as Buy Account except "account to pay" is credited 0 PASC (i.e. the New PASA Fee is **burned**).
 
 #### 1.2 JSON API
 
-A. New method called “Pay to Key” that works as follows:
+A. New method called “Pay to Key” is offered that works as follows:
 
    A.1 Arguments are Account, Public Key, Quantity
    
-   A.2 Builds a "Buy Floating Account" as per (1) using arguments in (A.1)
-   
+   A.2 Builds a "Buy Floating Account" operation  as per (1.1) using arguments in (A.1)
+
 
-B. Update "SendTransaction" method such that
+B. Update "SendTransaction" method such that,
 
    B.1 If target E-PASA is of the form *"@[Base58Key]"* then B.2 else B.3
    
-   B.2 Route to "Pay To Key" method using Base58Key as buyers key, and same Account, 
-   
-Quantity arguments 
+   B.2 Route to "Pay To Key" method using the parsed Base58Key as buyers key, keeping other arguments unchanged then finish
 
    B.3 Continue as a normal SendTransaction
 
 ### GUI Changes
 
-No changes required since this feature is enabled with E-PASA support (PIP-0027).   A pay to key will occur under-the-hood when someone sends a transaction to "@[1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2]" address.
+No changes are required since this feature is enabled with E-PASA support (PIP-0027).   A pay to key will occur under-the-hood when someone sends a transaction to "@[1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2]" address.
 
 ## Rationale
 
-The design approach is to provide a pure in-protocol PASA distribution solution for first time users. The design also is seamless in that a new operation is not required and works through the use of an [E-PASA][1].  This proposal definitively solves the first-PASA problem and provides an in-protocol distribution mechanism for PASA's whilst maintaining the commoditization principles that made PASA's great to begin with. Also, there will be no need for 3rd party infrastructure FreePasa.org or GetPasa.com and the hundreds of thousands of accounts available to Foundation can be made floating. Also with Block Policy, all new PASA's are by default set to floating (except the miner/dev reward ones).
+The design approach is to provide a pure in-protocol PASA distribution solution for first time users. The design also is seamless in that a new operation is not required and minimizes implementation complexity as it leverages existing and other proposed new features.
+
+This proposal definitively solves the first-PASA problem and provides an in-protocol distribution mechanism for PASA's whilst maintaining the commoditization principles that made PASA's great to begin with. 
+
+Also, there will be no need for 3rd party infrastructure FreePasa.org or GetPasa.com and the hundreds of thousands of accounts available to Foundation can be made floating. Also with Block Policy, all new PASA's are by default set to floating (except the miner/dev reward ones).
 
 ## Backwards Compatibility