PIP-0032A: grammar refactoring, spelling fixes, reads well now

PIP/PIP-0032A.md

@@ -13,21 +13,21 @@
 
 ## Summary
 
-A minor protocol change is proposed to enable Atomic Swap capability within the SafeBox.
+A minor protocol change is proposed to enable atomic swap capability within the SafeBox.
 
 ## Motivation
 
-Atomic Swaps are a smart-contract technology that enable the exchange of one cryptocurrency for another without using intermediaries, such as 3rd party exchanges.  Atomic swaps occur as events within the respective blockchains and between the exchanging parties only in a cryptographically secure manner.  Atomic Swaps are a fundamental building block for implementation of decentralized exchanges, such as the planned Pascal DEX. 
+Atomic swaps are a smart-contract technology that enable the exchange of one cryptocurrency for another without using intermediaries, such as 3rd party exchanges.  Atomic swaps occur as events within the respective blockchains and between the exchanging parties only in a cryptographically secure manner.  Atomic Swaps are a fundamental building block for implementation of decentralized exchanges, such as the planned Pascal DEX. 
 
-An Atomic Swap is performed using a type of smart-contract called a _Hash-Locked-Time-Contract_ (HLTC). The "Hash-Lock" aspect requires that the funds within the contract be locked by a hash and that they can only be unlocked by revealing the pre-image of that hash. The "Time-Contract" aspect refers to the contract being exclusively assigned to another party for a fixed, public and immutable period of time. This enables the party to unlock the funds within this time-frame without risk of being pre-empted by any other party. 
+An atomic swap is performed using a type of smart-contract known as a _Hash-Locked-Time-Contract_ (HLTC). The "Hash-Lock" aspect of an HLTC requires that the funds within the contract be locked by a hash and that they only be unlocked by revealing the pre-image of that hash. The "Time-Contract" aspect of an HLTC requires that the contract be exclusively assigned to the other party for a fixed, public and immutable period of time. The time-contract enables the party to unlock the funds within the time-frame without risk of being preempted by any other party. 
 
-By using two matching HLTC's on two independent blockchains, cryptographically-secure Atomic Swaps of cryptocurrency between those blockchains are possible without involving intermediaries. Since PascalCoin already implements "Time-Contracts" in the form of [in-protocol PASA exchange][2], only the "Hash-Locked" aspect of HLTCs require implementation.
+By using two matching HLTC's on two independent blockchains, cross-chain atomic swaps of cryptocurrency between those blockchains is possible without the involvement of intermediaries.  Since PascalCoin already implements "Time-Contracts" in the form of [in-protocol PASA exchange][2], only the "Hash-Locked" aspect of HLTCs require implementation.
 
-The proposal here is to introduce "Hash Locked" accounts such that when used within an in-protocol PASA exchange, achieve an HLTC suitable for Atomic Swaps. With this simple change, the following cross-chain Atomic Swap workflow is possible:
+The proposal here is to introduce the feature of "Hash Locked" accounts such that when combined with in-protocol PASA exchange, an HLTC is achived suitable for cross-chain atomic swaps. With this simple change, the following cross-chain atomic swap work-flow is enabled:
 
-### Atomic Swap Workflow
+### Atomic Swap Work-flow
 
-Suppose Alice has 100 PASC and Bob has 1 BTC, and they wish to perform an Atomic Swap between themselves. The below workflow can be employed:
+Suppose Alice has 100 PASC and Bob has 1 BTC, and they wish to perform an atomic swap between themselves. The below work-flow can be employed:
 
 1. Alice picks a very large random number known as **SECRET**
 
@@ -69,16 +69,16 @@ _The swap has still not occured yet but is setup bi-directionally._
 
 ---
 
-7. Once Alice detects **TXN1** on the BTC chain, she immediately spends it's outputs via a **TXN2** to her own wallet. She thus takes possesion of the 1 BTC, revealing **SECRET** in the process.
+7. Once Alice detects **TXN1** on the BTC chain, she immediately spends its outputs to her own wallet via a **TXN2**. She thus takes possession of the 1 BTC, revealing **SECRET** in the process.
 
 ----
-_**NOTE** In the process of spending TXN1, Alice reveals the SECRET inside of TXN2, which was a necessary condition of the smart-contract defined in **TXN1**, in particular the ```x for H(x) = CODE``` portion._
+_**NOTE** In the process of spending TXN1, Alice necessarily reveals SECRET inside of TXN2 since it was a necessary condition of the smart-contract defined in output of **TXN1**, in particular the ```x for H(x) = CODE``` portion._
 
 ----
 
 8. Bob detects the transaction **TXN2** and extracts **SECRET** from **TXN2**.
 
-9. Bob createas a Purchase Account operation for **X** and includes **SECRET** inside the Payload, thus taking possession of **X** containing the **100 PASC**. 
+9. Bob createas a Purchase Account operation for **X** and includes **SECRET** inside the Payload, thus taking possession of the **100 PASC**. 
  
 10. **Atomic Swap Completed**
 
@@ -86,9 +86,10 @@ _**NOTE** In the process of spending TXN1, Alice reveals the SECRET inside of TX
 _**IMPORTANT**_ 
 
 _Notice that Alice's offer to Bob was locked for 3 weeks, yet Bob's offer to Alice was locked for only 2 weeks._
-* _A time-lock differential is necessary to avoid the scenario where Alice takes both the 1 BTC and account X containing 100 PASC by revealing the SECRET at the moment the time-lock of X to Bob expires._
-* _With this time difference, if after 2 weeks Alice has not revealed SECRET, Bob can determine Alice is acting in bad faith (or has abandoned the contract) giving him 1 week to safely cancel the swap and reclaim his 1 BTC._ 
+* _A time-lock differential is necessary to avoid the scenario where Alice takes both the 1 BTC and the 100 PASC by revealing SECRET at exact moment X's time-lock to Bob expires._
+* _With this time difference in place, if after 2 weeks Alice has not revealed SECRET, Bob can determine Alice is acting in bad faith (or has abandoned the contract) thus giving him 1 week to safely cancel the swap and reclaim his 1 BTC._ 
 * _In this eventuality, Alice does not lose her PASC since she never revealed SECRET. She can safely reclaim her PASC after account X's time-lock to Bob expires in 3 weeks_.
+* _In practice, the HLTC's will use much shorter time-frames suitable for automated automic swap software.__
 
 ## Specification
 
@@ -116,8 +117,12 @@ end;
 
 ## Rationale
 
-There were various approaches for implementing Atomic Swap and HLTC, and this PIP suggests the most minimal-impact change. Only a minor change to consensus rules is required, not to any client libraries or signing logic. 
-To accomodate other approaches this PIP is post-fixed with A, allowing alternative proposals to supercede and/or compliment this approach.
+As there are many approaches for implementing atomic swaps and HLTCs in PascalCoin, this PIP is post-fixed with "A" to allow alternative approaches "B", "C" and so on. 
+However, PIP-0032A is by far the simplest and least impactful approach that naturally compliments the [in-protocol pasa exchange][2] features established in Version 2. 
+
+In many ways, this change completes that functinality to enable cross-chain PASA exchange. It is least impactful since it does not require changing signature logic for client-side libraries (such as JPpascalCoin/NPascalCoin/SBX/FlutterLib). 
+
+Due to the low cost vs the significant benefits, this proposal is recommended for V5 implementation.
 
 ## Backwards Compatibility