|
|
@@ -0,0 +1,109 @@
|
|
|
+<pre>
|
|
|
+ PIP: 2
|
|
|
+ Title: In-protocol PASA Exchange
|
|
|
+ Type: Protocol
|
|
|
+ Impact: Hard-Fork - Protcol, API, GUI
|
|
|
+ Author: Albert Molina <i><[email protected]></i>, Herman Schoenfeld <i><[email protected]></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]
|
Herman Schoenfeld