PIPs: update status and rename old ones more concisely

PIP/PIP-0016.md

@@ -1,6 +1,6 @@
 <pre>
   PIP: PIP-0016
-  Title: Layer-2 protocol support
+  Title: DATA-OPERATION: Data transactions (Layer-2 protocol enveloping)
   Type: Protocol
   Impact: Hard-Fork
   Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>

PIP/PIP-0017.md

@@ -1,6 +1,6 @@
 <pre>
   PIP: PIP-0017
-  Title: Anonymity via Transaction Mixing (phase-1)
+  Title: MULTI-OPERATION: Enabling in-protocol coin shuffling and more
   Type: Protocol
   Impact: Hard-Fork
   Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
@@ -11,7 +11,7 @@
 
 ## Summary
 
-A new operation called MULTI-TRANSACTION is proposed that allows a transfer of PASC from N accounts to M accounts and a transfer of U PASA to U new keys. This will immediately provide "better-than-DASH-level" anonymity and serve as foundational component for subsequent full anonymity. It will also facilitate Layer-2 applications such as decentralized exchanges in a manner that other cryptocurrencies cannot achieve!
+A new operation called MULTI-OPERATION is proposed that allows a transfer of PASC from N accounts to M accounts and a transfer of U PASA to U new keys. This will immediately provide "better-than-DASH-level" anonymity and serve as foundational component for subsequent full anonymity. It will also facilitate Layer-2 applications such as decentralized exchanges in a manner that other cryptocurrencies cannot achieve!
 
 ## Motivation
 
@@ -25,13 +25,13 @@ Use a web-driven mixer UI similar similar to how Bitcoin Cash transactions are m
 
 As phase-2 of anonymity, the network protocol will be upgraded via soft-fork to support mixing directly between wallet-to-wallet, in a virtually seamless manner as sending a transaction now.
 
-**Chaining Multi-Transactions**
+**Chaining MULTI-OPERATIONs**
 
-Immediately and improved in phase-2, users will be able to chain multiple Multi-Transactions together delivering indecipherable complexity between transfers
+Immediately and improved in phase-2, users will be able to chain multiple MULTI-OPERATIONs together delivering indecipherable complexity between transfers
 
 **Decentralized Exchanging**
 
-This operation, in combination with PascalCoin Asset Tokens (to be added in future), will facilitate Layer-2 decentralized cryptocurrency exchange protocols. This is because a MULTI-TRANSACTION allows market makers and market makers to negotiate and orechestrate an exchange of PASC/PASA/Tokens between themselves in a trust-free and off-line manner. As a result, a MULTI-TRANSACTION operation will serve as a fundamental building block for an infinitely-scalable Layer-2 decentralised exchange protocol running over the PascalCoin network planned by Sphere 10 Software (company of Author).
+This operation, in combination with PascalCoin Asset Tokens (to be added in future), will facilitate Layer-2 decentralized cryptocurrency exchange protocols. This is because a MULTI-OPERATION allows market makers and market makers to negotiate and orechestrate an exchange of PASC/PASA/Tokens between themselves in a trust-free and off-line manner. As a result, a MULTI-OPERATION operation will serve as a fundamental building block for an infinitely-scalable Layer-2 decentralised exchange protocol running over the PascalCoin network planned by Sphere 10 Software (company of Author).
 
 **Monetized-API Mixing**
 
@@ -39,9 +39,9 @@ As a CPU-mining community arises from [PIP-0009][1], those node operators will b
 
 ## Specification
 
-A new operation called MULTI-TRANSACTION is proposed as follows:
+A new operation called MULTI-OPERATION is proposed as follows:
 
-### New Operation: MULTI-TRANSACTION
+### New Operation: MULTI-OPERATION
 
 - SenderCount: Word - number of sender accounts (N)
 - SenderAccount_1: DWord - first sender account
@@ -103,9 +103,9 @@ A new operation called MULTI-TRANSACTION is proposed as follows:
 
 - Ensure no duplicate sender or change key accounts
 ```
-Length( SELECT SenderAccount FROM MULTI-TRANSACTION ) = Length( SELECT DISTINCT SenderAccount FROM MULTI-TRANSACTION )
+Length( SELECT SenderAccount FROM MULTI-OPERATION ) = Length( SELECT DISTINCT SenderAccount FROM MULTI-OPERATION )
 
-Length( SELECT ChangeKeyAccount FROM MULTI-TRANSACTION ) = Length( SELECT DISTINCT ChangeKeyAccount FROM MULTI-TRANSACTION )
+Length( SELECT ChangeKeyAccount FROM MULTI-OPERATION ) = Length( SELECT DISTINCT ChangeKeyAccount FROM MULTI-OPERATION )
 ```
 **NOTE** The above protocol does allow a sender X and then change key of X, but only 1 of each.
 
@@ -116,7 +116,7 @@ where
    MIN_FEE = 0.0001 (current protocol)
 ```
 
-**NOTE**: ChangeAccountKey entries do **not** pay a fee directly. In practice, their fee portion is covered by a separate SenderAccount entry that pays the fee for both itself and the ChangeKeyAccount entry. Alternatively, a single user could decide to cover someone/everyone elses fee's. The Fee is merely the difference between SUM(SenderQuantity) - SUM(ReceiverQuantity) and must account for all the entries in the multi-transaction. 
+**NOTE**: ChangeAccountKey entries do **not** pay a fee directly. In practice, their fee portion is covered by a separate SenderAccount entry that pays the fee for both itself and the ChangeKeyAccount entry. Alternatively, a single user could decide to cover someone/everyone elses fee's. The Fee is merely the difference between SUM(SenderQuantity) - SUM(ReceiverQuantity) and must account for all the entries in the MULTI-OPERATION. 
 
 - Ensure at least 1 sender
 ```
@@ -157,7 +157,7 @@ for-all c in ChangeKeyAccounts
 
 - Ensure that all senders and key changers sign the entire message **except the signature portion**
 ```
-let signedPortion = select bytes from (SenderCount...Payload) portion of MULTI-TRANSACTION
+let signedPortion = select bytes from (SenderCount...Payload) portion of MULTI-OPERATION
 for i := 1 to SenderCount
     let sender := SafeBox[SenderAccount_i]
     ECDSA_VerifySignature(SenderSignature_i, signedPortion, sender.PublicKey) = True 
@@ -169,9 +169,9 @@ for i := 1 to ChangeKeyCount
 
 #### Segregated Signatures during OPHASH ###
 
-In order to allow a sender to know the OPHASH of the Multi-Transaction before the **next sender** signs, it's important that the signature portion of the Multi-Transaction be omitted from the RIPEMD160-portion of the OPHASH calculation
+In order to allow a sender to know the OPHASH of the MULTI-OPERATION before the **next sender** signs, it's important that the signature portion of the MULTI-OPERATION be omitted from the RIPEMD160-portion of the OPHASH calculation
 ```
-OPHASH(MultiTransaction) = RIPEMD160 ( select bytes (SenderCount...Payload)  from MultiTransaction ) 
+OPHASH(MultiOperation) = RIPEMD160 ( select bytes (SenderCount...Payload)  from MultiOperation ) 
 ```
 
 Otherwise it will not be possible for a Sender to determine the OPHASH until it finally reaches a block. This will break high-frequency mixing.

PIP/PIP-0024.md

@@ -5,7 +5,7 @@
   Impact: Hard-Fork
   Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
   Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0023)
-  Status: Proposed
+  Status: Active
   Created: 2018-07-23
 </pre>
 

PIP/PIP-0025.md

@@ -5,7 +5,7 @@
   Impact: None - GUI
   Author: Jason Knapp <i>&lt;[email protected]&gt;</i>
   Comments-URI:
-  Status: Draft
+  Status: Active
   Created: 2018/09-26
 </pre>
 

PIP/PIP-0027.md

@@ -5,7 +5,7 @@
   Impact: Hard-Fork
   Author: Herman Schoenfeld <[email protected]>
   Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0027)
-  Status: Proposed
+  Status: Active
   Created: 2019-02-11
 </pre>
 

PIP/PIP-0028.md

@@ -5,7 +5,7 @@
   Impact: None
   Author: Herman Schoenfeld <[email protected]>
   Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0028)
-  Status: Proposed
+  Status: Withdrawn
   Created: 2019-03-05
 </pre>
 

PIP/PIP-0029.md

@@ -7,7 +7,7 @@
   Copyright: Herman Schoenfeld, 2019 (All Rights Reserved)
   License: GNU Public License 
   Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0029)
-  Status: Proposed
+  Status: Active
   Created: 2019-03-29
 </pre>
 

PIP/PIP-0030.md

@@ -7,7 +7,7 @@
   Copyright: Herman Schoenfeld, 2019 (All Rights Reserved)
   License: GNU Public License 
   Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0030)
-  Status: Proposed
+  Status: Active
   Created: 2019-04-07
 </pre>
 

PIP/PIP-0031A.md

@@ -7,7 +7,7 @@
   Copyright: Herman Schoenfeld, <Other Authors> , 2019 (All Rights Reserved)
   License: GNU Public License 
   Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0031)
-  Status: Draft
+  Status: Withdrawn
   Created: 2019-04-15
 </pre>
 

PIP/PIP-0031B.md

@@ -1,4 +1,4 @@
-```
+```
   PIP: PIP-0031B
   Title: New GUI Wallet
   Type: User Interface
@@ -8,7 +8,7 @@
   Copyright: mosu_forge <[email protected]>, 2019 (All Rights Reserved)
   License: GNU Public License 
   Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0031b)
-  Status: Draft
+  Status: Accepted
   Created: 2019-04-22
 ```
 

PIP/PIP-0031C.md

@@ -7,7 +7,7 @@
   Copyright: Appditto, 2019 (All Rights Reserved)
   License: GNU Public License 
   Comments-URI: https://discord.gg/sJqcgtD (channel #pip-0031c)
-  Status: Draft
+  Status: Accepted
   Created: 2019-04-23
 </pre>
 

PIP/README.md

@@ -34,8 +34,12 @@ If they wish to continue, copy [this template](PIP-template.md) and ensure your
 | [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 |
 | [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   | Accepted |
-| [30](PIP-0030.md)     | SafeBoxRoot: Deletable SafeBox and Light-Nodes  | Herman Schoenfeld            | Protocol   | Accepted |
-| [31A](PIP-0031A.md)   | New Wallet: Multi-Platform & Multi-Paradigm   | Herman Schoenfeld            | Protocol   | 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                    | Herman Schoenfeld            | User Interface   | Accepted |
+| [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 |