PIP-0041.md 6.1 KB
PIP: PIP-0041 Title: Pay To Key: in-protocol PASA distribution Type: Protocol Impact: Hard-Fork Author: Herman Schoenfeld Comments-URI: https://discord.gg/sJqcgtD (channel #pip-0041) Status: Draft Created: 2020-10-26
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 not 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) 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 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]. Here the users public key is encoded in base-58 within square brackets pre-fixed with an @ symbol.
A transaction 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.
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
1. Core Changes
1.1 BuyAccount Operation Changes
A. New transaction sub-type called "buy floating account".
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.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 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” is offered that works as follows:
A.1 Arguments are Account, Public Key, Quantity
A.2 Builds a "Buy Floating Account" operation as per (1.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 the parsed Base58Key as buyers key, keeping other arguments unchanged then finish
B.3 Continue as a normal SendTransaction
GUI Changes
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 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
This PIP is not backwards compatible and requires a hard-fork activation. It also requires PIP-0027 E-PASA and PIP-0035 Block Policy activation.