Fix: correct typos in PIPs

PIP/PIP-0001.md

@@ -4,7 +4,7 @@
   Type: Process
   Impact: None
   Author: Herman Schoenfeld &lt;<i>[email protected]</i>&gt;
-  Comments-URI: https://github.com/PascalCoin/PascalCoin/issues/44
+  Comments-URI: <a href ="https://github.com/PascalCoin/PascalCoin/issues/44">https://github.com/PascalCoin/PascalCoin/issues/44</a>
   Status: Draft
   Created: 2017-07-24 
 </pre>
@@ -53,7 +53,7 @@ A PIP submission should be written in mark-down (GitHub flavor) and consist of t
  - <b>Reference Implementation</b> -- The reference implementation must be provided before PIP is Completed.
  - <b>Links</b> -- References and links to relevant material.
 
-PIP editors can use [this online editor](https://jbt.github.io/markdown-editor/) for editing and/or previewing their PIP submission.
+PIP editors can begin by downloading the [PIP Template][2] and editing via an [online editor][1].
 
 ### Header 
 
@@ -107,3 +107,9 @@ A PIP may have multiple types.
 | GUI           | changes to wallet GUI                             |
 | Mobile        | changes to mobile GUI or implementation           |
 | Other         | changes to any other aspect of how PascalCoin is implemented. For examples, changes to log format or how persistence-layer would fall other here. |
+
+1. [Online Markdown Editor][1]
+2. [Template PIP][2]
+
+[1]: https://jbt.github.io/markdown-editor/
+[2]: https://github.com/PascalCoin/PascalCoin/blob/master/PIP/PIP-template.md

PIP/PIP-0002.md

@@ -3,34 +3,33 @@
   Title: In-protocol PASA Exchange
   Type: Protocol
   Impact: Hard-Fork - Protcol, API, GUI
-  Author: Albert Molina <i>&lt;[email protected]&gt;</i>, Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
+  Author: Albert Molina <i>&lt;[email protected]&gt;</i>
   Comments-URI: N/A
   Status: Active
   Created: 2017-03-01  
 </pre>
 
-***PIP Editor Note:** This PIP was created retrospectively based of the [Whitepaper V2](https://github.com/PascalCoin/PascalCoin/blob/master/PascalCoinWhitePaperV2.pdf) on 2017-08-15.*
+***PIP Editor Note:** This PIP was created retrospectively based of the [Whitepaper V2][1] on 2017-08-15.*
 
 ## Summary
 
-This PIP proposes protocol updates to allow users to sell, settle and exchange PascalCoin accounts (PASA) in a decentralised manner without dependence on 3rd parties.
+This PIP proposes in-protocol sale, purchase, settlment and exchange of PascalCoin accounts (PASA) in a totally decentralised manner.
 
  ## Motivation
 
-In PascalCoin, every time a block updates the SafeBox new accounts are appended at the end of the SafeBox. These accounts are awarded to the miner as a “secondary reward” alongside the usual block reward.  These newly generated accounts are then distributed to ordinary users via market mechanisms. Actual ownership exchange of an account occurs by updating the key associated to that  account, via a blockchain operation.  The bearer of the private key which corresponds to an accounts public key is the authorized owner of that account.  Since the introduction of PascalCoin, this distribution workflow has proven an impediment to adoption due to:
+In PascalCoin, every time a block updates the SafeBox new accounts are appended at the end of the SafeBox. These accounts are awarded to the miner as a “secondary reward” alongside the usual block reward.  These newly generated accounts are then distributed to ordinary users via market mechanisms. Actual ownership exchange of an account occurs by updating the key associated to that account via a blockchain operation.  The bearer of the private key, which corresponds to an accounts public key, is the authorized owner of that account.  Since the introduction of PascalCoin, this distribution workflow has proven an impediment to adoption due to:
 
-* Exchange-PASA Problem: Most users acquire their PASC from exchanges, not through mining. Typically, after a user buys PASC on an exchange they then attempt to withdraw from that exchange into their wallet only to find out they need a PASA. Since PASA assets are not traded on established exchanges, users resort to OTC markets in chat rooms/forums prone to human error and fraud. Exchanges are reticent to trade PASA due to their indivisible and non-fungible properties. PASA assets mirror numismatic gold markets more than bullion.  As a result, PASA are better suited for auction-style markets (such as PascWallet.com), placing them beyond the reach of exchange users at this point in time. 
-
-* Miner Hoarding: Due to the competitiveness of mining, most mining is now pooled collectively into mining pools. Typically, individual pool workers are awarded their yield in proportion to their hashing power contributions. In the case of PASA, this has proven burdensome for pool operators since PASA are indivisible and non-fungible assets. The additional effort required by pool operators to fairly distribute PASA has actually prevented distribution entirely and resulted in significant hoarding. Protocol V2 now provides an effective in-protocol means to distribute PASA. PascalCoin Protocol v2 addresses this shortcoming by implementing decentralised account sale, settlement and exchange operations within the protocol-itself. In combination with PASA exchanges such as PascWallet.com and GetPasa.com, the account distribution problems of Version 1 are resolved. 
+* Exchange-PASA Problem: Most users acquire their PASC from exchanges, not through mining. Typically, after a user buys PASC on an exchange they then attempt to withdraw from that exchange into their wallet only to find out they need a PASA. Since PASA assets are not traded on established exchanges, users resort to OTC markets in chat rooms/forums prone to human error and fraud. Exchanges are reticent to trade PASA due to their indivisible and non-fungible properties. PASA assets mirror numismatic gold markets more than bullion. As a result, PASA are better suited for auction-style markets (such as [PascWallet.com](pascwallet.com)), placing them beyond the reach of exchange users at this point in time. 
 
+* Miner Hoarding: Due to the competitiveness of mining, most mining is now pooled collectively into mining pools. Typically, individual pool workers are awarded their yield in proportion to their hashing power contributions. In the case of PASA, this has proven burdensome for pool operators since PASA are indivisible and non-fungible assets. The additional effort required by pool operators to fairly distribute PASA has actually prevented distribution entirely and resulted in significant hoarding.  
 
  ## Specification
 
 This PIP proposes the following new operations
 
-* [List Account For Sale] (#list-account-for-sale)
-* [Delist Account] (#delist-account)
-* [Buy Account] (#buy-account)
+* [List Account For Sale](#list-account-for-sale)
+* [Delist Account](#delist-account)
+* [Buy Account](#buy-account)
 
 and amends the following operations
 
@@ -38,9 +37,9 @@ and amends the following operations
 
 ### List Account For Sale
 
-The purpose of this new operation is to allow an owner of an account to designate an account “For Sale”  in much the same way an owner of a house may place a “FOR SALE” sign outside their house. Accounts can be marked for public sale or for private sale. For a public sale, anyone can purchase the account by executing a corresponding Buy Account operation containing the correct funding. The first user to execute a valid Buy Account​ operation will become the owner of that account. If multiple Buy Account​ operations arrive simultaneously, the miner selects one and discards the rest. Any excess funds remaining after a Buy Account​ operation are credited to the purchased account. If a Buy Account​ operation fails for any reason, those funds are never debited from the purchases account. For a private sale, the seller designates the buyer’s public key within the listing and includes a timeout period to allow the buyer to settle the purchase. The buyer may settle the purchase by executing a single Buy Account ​operation, within the timeout period, with the correct funds.
+The purpose of this new operation is to allow an owner of an account to designate an account “For Sale”  in much the same way an owner of a house may place a “FOR SALE” sign outside their house. Accounts can be marked for public sale or for private sale. For a public sale, anyone can purchase the account by executing a corresponding Buy Account operation containing the correct funding. The first user to execute a valid Buy Account​ operation will become the owner of that account. If multiple Buy Account​ operations arrive simultaneously, the miner selects one and discards the rest. Any excess funds remaining after a Buy Account​ operation are credited to the purchased account. If a Buy Account​ operation fails for any reason, those funds are never debited from the purchases account. For a private sale, the seller designates the buyers public key within the listing and includes a timeout period to allow the buyer to settle the purchase. The buyer may settle the purchase by executing a single Buy Account ​operation, within the timeout period, with the correct funds.
 
-Optionally, the buyer may send one (or many)  standard Transactions​ into the account until the funding is met, at which point the purchase is settled.  The properties for this operation type include:
+Optionally, the buyer may send one (or many) standard Transactions​ into the account until the funding is met, at which point the purchase is settled.  The properties for this operation type include:
 * The account number to be sold
 * The sale price 
 * The sellers account number receiving payment
@@ -80,16 +79,17 @@ Users can optionally settle a private account sale by issuing standard transacti
 
 ### Accounting Rules
 The following accounting rules govern how all the interacting account’s balances are mutated pre and post account purchase/settlement.
+
 ```
 Let A = account balance pre-settlement (of account being purchased)
-Let B = buyer’s account balance pre-settlement  (the account funding the purchase)
-Let C = seller’s account balance pre-settlement (the account receiving the funds)
+Let B = buyers account balance pre-settlement  (the account funding the purchase)
+Let C = sellers account balance pre-settlement (the account receiving the funds)
 Let T = funding amount (the PASC used to purchase account)
 Let P = listed sale price of account
-* Funding required to settle purchase  = P - A
-* Account balance post-settlement = A + T - P
-* Buyer’s account balance post-settlement = B - T
-* Seller’s account balance post-settlement = C + P
+Funding required to settle purchase  = P - A
+Account balance post-settlement = A + T - P
+Buyers account balance post-settlement = B - T
+Sellers account balance post-settlement = C + P
 ```
 
 ## Rationale
@@ -106,4 +106,6 @@ None provided. This PIP has been implemented in V2.
 
 ## Links
 
-1. (PascalCoin Whitepaper V2)[https://github.com/PascalCoin/PascalCoin/blob/master/PascalCoinWhitePaperV2.pdf]
+1. [PascalCoin White Paper V2][1]
+
+[1]: https://github.com/PascalCoin/PascalCoin/blob/master/PascalCoinWhitePaperV2.pdf

PIP/PIP-0003.md

@@ -13,24 +13,25 @@
 
 ## Summary
 
-This PIP proposes a fundamental change to the SafeBox allowing PascalCoin to achieve practically infinite running-time on finite and constant storage. This PIP allows nodes to discard blocks after the height of 100 whilst retaining the (SPV) cryptographic security of the full blockchain. This way, PascalCoin need only store the flow of transactions rather than the history -- a fundamental breakthrough in Blockchain technology.
+This PIP proposes a fundamental change to the SafeBox allowing PascalCoin to achieve practically infinite running-time on finite and constant storage. This PIP proposes nodes discard blocks after the height of 100 whilst retaining the (SPV) cryptographic security of the full blockchain. This way, PascalCoin need only store the flow of transactions rather than the history -- a fundamental breakthrough in Blockchain technology.
  
 ## Motivation
 
-In PascalCoin V1, new nodes are required to syncronize from the genesis block in order to determine the most-work-chain. Without the full block history, nodes can never independently determine the most-work-chain. Over time, this will lead to centralisation as storage requirements for nodes approch data-center specifications. This problem exists for all other cryptocurrencies (at the time of this writing). Over a protracted period of time, these cryptocurrencies storage requirements will become impractically large and lead to the death of those coins. With this PIP, **the PascalCoin network can run for centuries at arbitrarily-high throughput and yet still require less storage than Bitcoin does today!**
+In PascalCoin V1, new nodes are required to syncronize from the genesis block in order to determine the most-work-chain. Without the full block history, nodes can never independently determine the most-work-chain. Over time, this will lead to centralisation as the storage requirements for nodes approach that of data-centers. This problem exists for all other cryptocurrencies (at the time of this writing) as over a protracted period of time, these cryptocurrencies will become impractically large for ordinary computers to store resulting in their eventual death. With this PIP, **the PascalCoin network can run for centuries at arbitrarily-high throughput and yet still require less storage than Bitcoin does today!**
 
 ## Specification
 
 * The SafeBox will retain the block header in every Account Segment sub-structure. 
-* New blocks will be appended to the top of the chain and blocks with height greater than 100 deleted from the bottom. 
+* New blocks will be appended to the top of the chain and blocks with height greater than 100 will be deleted from the bottom. 
 * On every 100th block, a copy of the SafeBox will be made and referred to as a 'Checkpoint'.
 * When a new nodes syncronize, they downloads the latest known Checkpoint and then the blocks minted after. 
-* Checkpoints are fully and independently verified by the node as follows:
-  1. Hashing all the Block Headers again and verifying they link transitively as a chain
+* Checkpoints are fully and independently verified by nodes as follows:
+  1. All the Block Headers are hashed again and that they all link transitively via chain is checked.
   2. Let TotalWork = sum of Compact Target for every block header
-  3. Verifying that the TotalWork of the SafeBox is the largest known in the network.
+  3. Verify that the TotalWork of the SafeBox is the largest known in the network.
+  4. If the SafeBox is structurally invalid or there exists another SafeBox with higher TotalWork, then it is discarded and the advertisting nodes blacklisted.
 
-**Note**: A sybil-attack using a forged SafeBox is an unsufficient condition to overwrite the honest SafeBox since nodes will always choose the SafeBox with the highest total work. Thus in order to forge a SafeBox the attacker must re-mine all the past blocks (and then some) faster than the honest SafeBox continues to grow which is virtually a physical impossibility.
+**Note**: A sybil-attack using a forged SafeBox is an unsufficient condition to overwrite the honest SafeBox since nodes will always choose the SafeBox with the highest total work. In order for a forged SafeBox to overwrite the hoenst network's SafeBox, the attacker must re-mine all the past blocks (and then some) faster than the honest SafeBox continues to grow --virtually a physical impossibility.
 
 Full technical specification can be found in [Whitepaper V2][1].
  

PIP/PIP-template.md

@@ -2,7 +2,7 @@
   PIP: *reserved for PIP editor*
   Title: Title for your PIP
   Type: Protocol | Backend | Front-End | Informational | Process
-  Impact: [Hard-Fork|Soft-Fork] - [Protcol | API | GUI | Mobile | Other]
+  Impact: [Hard-Fork|Soft-Fork|None] - [Protcol | API | GUI | Mobile | Other]
   Author: Firstname Lastname <i>&lt;[email protected]&gt;</i>
   Comments-URI: *reserved for PIP editor*
   Status: Draft