PIP-0041 Pay To Key: in-protocol PASA distribution

PIP/PIP-0041.md

@@ -0,0 +1,73 @@
+<pre>
+  PIP: PIP-0041
+  Title: Pay To Key 
+  Type: Protocol
+  Impact: Hard-Fork
+  Author: Herman Schoenfeld <[email protected]>
+  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0041)
+  Status: Draft
+  Created: 2020-10-26
+</pre>
+
+## Summary
+
+This PIP proposes solution to a fundamental problem in PascalCoin; how first-time users get their first account.
+
+## 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.
+
+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. 
+
+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 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).
+
+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.
+
+## Specification
+
+### 1. Core Changes
+
+#### 1.1 BuyAccount Operation Changes
+
+A. New transaction sub-type called "buy floating account".
+B. 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.1 The **first** PASA in the SafeBox with type "Floating" is selected as "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**).
+
+#### 1.2 JSON API
+
+A. New method called “Pay to Key” 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)
+
+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.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.
+
+## 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).
+
+## Backwards Compatibility
+
+This PIP is not backwards compatible and requires a hard-fork activation. It also requires [PIP-0027 E-PASA][1] and [PIP-0035 Block Policy][2] activation.
+
+## Links
+
+1. [E-PASA: Infinite Address-Space (via Layer-2)][1]
+2. [Block Policy: Layer-1 Governance][2]
+
+[1]: https://github.com/PascalCoin/PascalCoin/blob/master/PIP/PIP-0027.md
+[2]: https://github.com/PascalCoin/PascalCoin/blob/master/PIP/PIP-0035.md
+

PIP/README.md

@@ -27,26 +27,27 @@ If they wish to continue, copy [this template](PIP-template.md) and ensure your
 | [18](PIP-0018.md)     | 10% funding allocation for Lazarus/FPC        | Herman Schoenfeld              | Process        | Proposed |
 | [19](PIP-0019.md)     | Balance recovered from lost accounts to be sent to developers fund   | Dr. Muhammad Amer   | Protocol        | Draft |
 | [20](PIP-0020.md)     | 6-month PascalCoin Foundation Budget Appropriations   | Herman Schoenfeld      | Process        | Withdrawn |
-| [21](PIP-0021.md)     | Agreement For Funding                         | Herman Schoenfeld              | Process        | Active |
-| [22](PIP-0022.md)     | Continuous Integration                        | Benjamin Ansbach               | Process        | Draft |
-| [23](PIP-0023.md)     | JSON RPC PASCURRENCY format                   | Benjamin Ansbach               | Backend, Documentation | Draft |
-| [24](PIP-0024.md)     | Account Data                                  | Herman Schoenfeld              | Protocol       | Draft |
-| [26](PIP-0026.md)     | URI Scheme Proposal                           | Ugochukwu Mmaduekwe            | Front-End       | Draft |
-| [27](PIP-0027.md)     | E-PASA: Infinite Address-Space (via Layer-2)  | Herman Schoenfeld              | Protocol, Front-End    | Accepted |
+| [21](PIP-0021.md)     | Agreement For Funding                         | Herman Schoenfeld              | Process        | Cancelled |
+| [22](PIP-0022.md)     | Continuous Integration                        | Benjamin Ansbach               | Process        | Accepted |
+| [23](PIP-0023.md)     | JSON RPC PASCURRENCY format                   | Benjamin Ansbach               | Backend, Documentation | Active |
+| [24](PIP-0024.md)     | Account Data                                  | Herman Schoenfeld              | Protocol       | Active |
+| [26](PIP-0026.md)     | URI Scheme Proposal                           | Ugochukwu Mmaduekwe            | Front-End       | Rejected |
+| [27](PIP-0027.md)     | E-PASA: Infinite Address-Space (via Layer-2)  | Herman Schoenfeld              | Protocol, Front-End    | Proposed |
 | [28](PIP-0028.md)     | E-OP: Layer-2 operation encoding standard for smart-contracts | Herman Schoenfeld            | Front-End       | Withdrawn |
 | [29](PIP-0029.md)     | Account Seals: Cryptographically Secure Account Histories  | Herman Schoenfeld            | Protocol   | Active |
 | [30](PIP-0030.md)     | SafeBoxRoot: Deletable SafeBox and Light-Nodes| Herman Schoenfeld              | Protocol   | Active |
 | [31A](PIP-0031A.md)   | New Wallet: Multi-Platform & Multi-Paradigm   | Herman Schoenfeld              | User Interface   | Withdrawn |
-| [31B](PIP-0031B.md)   | New GUI Wallet                                | mosu_forge                     | User Interface  | Accepted |
-| [31C](PIP-0031C.md)   | New Wallet: Multi-Platform                    | Appditto                       | User Interface   | Accepted |
+| [31B](PIP-0031B.md)   | New GUI Wallet                                | mosu_forge                     | User Interface  | Cancelled |
+| [31C](PIP-0031C.md)   | New Wallet: Multi-Platform                    | Appditto                       | User Interface   | Active |
 | [31D](https://github.com/davidbolet/PascWallet)   | New Wallet: Multi-Platform & Multi-Paradigm  |  David Bolet       | User Interface   | Rejected |
-| [32A](PIP-0032A.md)   | Atomic Swaps via Hash-Locked Accounts         | Herman Schoenfeld              | Protocol   | Proposed |
+| [32A](PIP-0032A.md)   | Atomic Swaps via Hash-Locked Accounts         | Herman Schoenfeld              | Protocol   | Active |
 | [33](PIP-0033.md)     | DATA operation RPC implementation             | Benjamin Ansbach               | Backend    | Proposed |
-| [34A](PIP-0034A.md)   | Website UI/UX Redesigns                       | Appditto                       | Website    | Proposed |
-| [35](PIP-0035.md)     | Block Policy: Layer-1 Governance (Velocity Cash) | Herman Schoenfeld           | Protocol   | Draft    |
+| [34A](PIP-0034A.md)   | Website UI/UX Redesigns                       | Appditto                       | Website    | Cancelled |
+| [35](PIP-0035.md)     | Block Policy: Layer-1 Governance (Velocity Cash) | Herman Schoenfeld           | Protocol   | Proposed |
 | [36](PIP-0036.md)     | RandomHash2: Enhanced GPU & ASIC Resistant Hash Algorithm | Herman Schoenfeld  | Protocol   | Accepted    |
 | [37](PIP-0037.md)     | Distinguish account updates between active/passive mode | Albert Molina | Protocol | Accepted |
 | [38](PIP-0038.md)     | P2P Chat and Communication | Preben Björn Biermann Madsen | Protocol | Draft |
-| [39](PIP-0039.md)     | Temporary Voting Procedure | Gynther and the Interrim Dao-Team | Process | Draft |
-| [40](PIP-0040.md)     | Pascal Governance | Gynther and the Interrim Dao-Team | Process | Draft |
+| [39](PIP-0039.md)     | Temporary Voting Procedure | Gynther and the Interrim Dao-Team | Process | Cancelled |
+| [40](PIP-0040.md)     | Pascal Governance | Gynther and the Interrim Dao-Team | Process | Cancelled |
+| [41](PIP-0041.md) | Pay To Key | Herman Schoenfeld | Protocol | Draft |