Added: retrospective V2 PIPs & cleanup

PIP/PIP-0001.md

@@ -44,14 +44,14 @@ The current PIP Maintainer is Herman Schoenfeld who can be contacted at herman@s
 ## PIP Format and Structure
 A PIP submission should be written in mark-down (GitHub flavor) and consist of the following structure:
 
- - <b>Header</b> -- Metadata description of the PIP (see below) 
- - <b>Summary</b> -- Short (~200 word) description of the technical issue being addressed
+ - <b>Header</b> -- Metadata description of the PIP (see below).
+ - <b>Summary</b> -- Short (~200 word) description of the technical issue being addressed.
  - <b>Motivation</b> -- Clear explanation of why current protocol is inadequate to address the problem the PIP solves. 
- - <b>Specification</b> -- Full technical description of the proposed new feature, clear enough for i
+ - <b>Specification</b> -- Full technical description of the proposed new feature, clear enough for implementation.
  - <b>Rationale</b> -- Discussion why was the specification was chosen over alternate designs. Evidence supporting the specification should be provided here, as well as community concerns and consensus.
  - <b>Backwards Compatibility</b> -- Any backwards incompatibilities should be described here, as well as work-arounds/solutions for these incompatibilities.
  - <b>Reference Implementation</b> -- The reference implementation must be provided before PIP is Completed.
- - <b>Links</b> -- references and links to relevant material
+ - <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/PIP-0002.md

@@ -0,0 +1,109 @@
+<pre>
+  PIP: 2
+  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>
+  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.*
+
+## 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.
+
+ ## 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:
+
+* 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. 
+
+
+ ## Specification
+
+This PIP proposes the following new operations
+
+* [List Account For Sale] (#list-account-for-sale)
+* [Delist Account] (#delist-account)
+* [Buy Account] (#buy-account)
+
+and amends the following operations
+
+* [Transaction](#transaction) (this is the standard operation used to transfer PASC)
+
+### 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.
+
+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
+* Flag indicating whether private or public sale
+* Timeout period (private sale only)
+  * This value is a block number which the purchase must be completed before or on. 
+  * During this period, the account is frozen and only able to receive funds, in order to protect the buyer.  
+  * After this period, the account owner can delist this account and consume funds.  
+* Buyers public key (private sale only)
+* Seller’s signature
+
+### Delist Account 
+
+This new operation allows an account previously listed for sale to be delisted. If an account is listed for public sale and is settled prior to the execution of a Delist Account​ operation, then the Delist Account​ operation is discarded. If an account is marked for private sale then it cannot be delisted during the timeout period,  only after the timeout period. If an account’s timeout period has elapsed and purchaser has not settled the purchase, the account will continue to be listed for sale until either it is purchased or delisted.  The properties of this operation type include:
+
+* The account number to be delisted
+* Seller’s signature
+
+### Buy Account 
+
+This new operation allows a user to purchase and settle an account listed for public or private sale. For a public sale, the operation must include the funding equal to or greater than the listing sale price. If the funding is less than the listing price, the operation is considered invalid and discarded. If the funding is greater than the listing price, the excess funding will be credited to the purchased account after settlement. This operation contains the following properties:
+
+* Buyer’s account number that will fund the purchase
+* Account number being purchased
+* Funding
+  * Must be equal to or greater than the selling price, not less. 
+  * Funds already present in the account are deducted from the sale price.
+  * Excess funds are credited to purchased account
+* New public key for account 
+  * For a private sale, this must match the public key in the listing, otherwise will be discarded
+* Buyer’s signature
+
+
+### Transaction
+
+Users can optionally settle a private account sale by issuing standard transactions into the account being purchased. The existing Transaction​ operation type is modified as follows. If a transaction is crediting an account listed for private sale and the resulting balance is greater than or equal to the sale price, the account is purchased as if a Buy Account ​operation were executed. The account’s resulting public key will change as per the buyer’s key specified in the listing irrespective of the origin of the transaction. Also, an amount equalling the sale price specified in the listing is transferred to the seller’s account specified in the listing. This update allows new users with no account but with coins in an exchange to withdraw their funds into an an account they’ve negotiated for.
+
+### 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 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
+```
+
+## Rationale
+
+The reason in-protocol operations were chosen is to provide 100% decentralisation in this exchange. Other solutions would invariably require dependence on 3rd parties, a losing proposition in cryptocurrency design.
+
+## Backwards Compatibility
+
+Changes are not backwards compatible and must be introduced via a planned hard-fork.
+ 
+## Reference Implementation
+
+None provided. This PIP has been implemented in V2.
+
+## Links
+
+1. (PascalCoin Whitepaper V2)[https://github.com/PascalCoin/PascalCoin/blob/master/PascalCoinWhitePaperV2.pdf]

PIP/PIP-0003.md

@@ -0,0 +1,53 @@
+<pre>
+  PIP: 3
+  Title: Infinite Scaling via Deletable Blockchain
+  Type: Protocol 
+  Impact: Hard-Fork
+  Author: Herman Schoenfeld <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][1] on 2017-08-15.*
+
+## 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.
+ 
+## 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!**
+
+## 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. 
+* 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
+  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.
+
+**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.
+
+Full technical specification can be found in [Whitepaper V2][1].
+ 
+## Rationale
+
+PascalCoin V1 was released with the promise of "deletable blockchain" yet the original implementation only delivered "prunable blockchain". With this PIP, PascalCoin now delivers on it's original promise.
+
+## Backwards Compatibility
+
+Changes are not backwards compatible and will require a hard-fork.
+ 
+## Reference Implementation
+
+None provided. This PIP has been implemented in V2.
+ 
+## Links
+
+1. [PascalCoin White Paper V2][1]
+
+[1]: https://github.com/PascalCoin/PascalCoin/blob/master/PascalCoinWhitePaperV2.pdf

PIP/PIP-template.md

@@ -0,0 +1,38 @@
+<pre>
+  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]
+  Author: Firstname Lastname <i>&lt;[email protected]&gt;</i>
+  Comments-URI: *reserved for PIP editor*
+  Status: Draft
+  Created: YYYY-MM-DD
+</pre>
+
+## Summary
+
+Short (~200 word) description of the technical issue being addressed
+ 
+## Motivation
+
+Clear explanation of why current protocol is inadequate to address the problem the PIP solves. 
+
+## Specification
+
+Full technical description of the proposed new feature, clear enough for implementation.
+ 
+## Rationale
+
+Discussion why was the specification was chosen over alternate designs. Evidence supporting the specification should be provided here, as well as community concerns and consensus.
+
+## Backwards Compatibility
+
+Any backwards incompatibilities should be described here, as well as work-arounds/solutions for these incompatibilities.
+ 
+## Reference Implementation
+
+The reference implementation must be provided before PIP is Completed.
+ 
+## Links
+
+References and links to relevant material

PIP/README.md

@@ -1,10 +1,13 @@
 # PascalCoin Improvement Proposals (PIP)
 
 People wishing to submit PIPs, first should discuss their idea on the [PascalCoin Slack](http://pascalcoin.org/slack-self-invite/). 
-If they wish to continue, edit your PIP in accordance to the [standard](PIP-0001.md) and submit to the PIP Maintainer for publication here.
+If they wish to continue, copy [this template](PIP-template.md) and ensure your PIP is in accordance to the [standard](PIP-0001.md). Submit to the PIP Maintainer for publication here.
 
 ## All PIPs
 
 | Number                | Title                                    | Owner               | Type           | Status          |
-| :-------------------: | :---------------------------------------:| :-----------------: | :------------: | :-------------: |
+| :-------------------: | :--------------------------------------- | :-----------------  | :------------  | :-------------  |
 | [1](PIP-0001.md)      | PIP Purpose and Guidelines               | Herman Schoenfeld   | Process        | Draft           |
+| [2](PIP-0002.md)      | In-protocol PASA Exchange                | Albert Molina       | Protocol       | Active          |
+| [3](PIP-0003.md)      | Infinite Scaling via Deletable Blockchain| Herman Schoenfeld   | Protocol       | Active          |
+