PIP-0017: Anonymity via Transaction Mixing (phase-1)

PIP/PIP-0017.md

@@ -0,0 +1,135 @@
+<pre>
+  PIP: PIP-0017
+  Title: Anonymity via Transaction Mixing (phase-1)
+  Type: Protocol
+  Impact: Hard-Fork
+  Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
+  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0017)
+  Status: Proposed
+  Created: 2018-01-04
+</pre>
+
+## Summary
+
+A new operation called MULTI-TRANSACTION is proposed that allows a transfer of funds from N accounts to M accounts within in a single operation. This will immediately provide DASH-level anonymity and serve as foundational component for subsequent full anonymity. 
+
+## Motivation
+
+Currently, PascalCoin transactions occur between publically visible accounts. Of all the cryptocurrencies, PascalCoin is the least anonymous. Anonymity is intrinsically connected to fungibility, a crucial aspect of any currency. Without fungibility, adoption will be stunted. This proposal immediately delivers DASH-level anonymity into the protocol, and will allow users to perform:
+
+**Client-Server Mixing**
+
+Use a web-driven mixer UI similar similar to how Bitcoin Cash transactions are mixed today (but not Bitcoin Core, due to high fees).
+
+**Network-protocol Mixing**
+
+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**
+
+Immediately and improved in phase-2, users will be able to chain multiple Multi-Transactions together delivering indecipherable complexity between transfers.
+
+**Monetized-API Mixing**
+
+As a CPU-mining community arises from [PIP-0009][1], those node operators will be able to earn extra income by running a **Layer-2 node** (similar to a Masternode in DASH), that can participate in totally secure phase-2 anon, among various other Layer-2 applications such as smart-contract and marketplace platforms.
+
+## Specification
+
+A new operation called MULTI-TRANSACTION is proposed as follows:
+
+### New Operation: MULTI-TRANSACTION
+
+- SenderCount: Word - number of sender accounts (N)
+- SenderAccount_1: DWord - first sender account
+- SenderQuantity_1: QWord - amount first sender is sending
+- SenderNOperation: DWord - the new N_OPERATION value of first senders account
+
+    .
+    .
+    .
+
+- SenderAccount_N : DWord - N'th sender account
+- SenderQuantity_N : DWord - amount N'th sender is sending
+- SenderNOperation_N: DWord - the new N_OPERATION value of N'th senders account 
+- RecipientCount: Word - number of recipient accounts (M)
+- RecipientAccount_1: DWord - first recipient account
+- RecipientQuantity_1 : QWord - amount first recipient is receiving
+
+    .
+    .
+    .
+
+- RecipientAccount_M : DWord - M'th recipient
+- RecipientQuantity_M : QWord - amount M'th recipient is receiving
+- SenderFee: network fee payable to miners **per sender**
+- Payload: operation payload
+- SenderSignature_1: signature of first sender
+
+    .
+    .
+    .
+
+- SenderSignature_N: signature of N'th sender
+
+**Consensus Rules**
+- Ensure fee per sender is non-zero
+```
+SenderFee > 0
+```
+
+- Ensure at least 1 sender
+```
+SenderCount > 0
+```
+
+- Ensure at least 1 recipient
+```
+RecipientCount > 0
+```
+
+- Ensure all senders have enough to send and pay fee
+```
+for-all s in Senders 
+    SafeBox.Accounts[s.Account].Balance >= s.Quantity + SenderFee
+```
+
+- Ensure the amount being spent balances the amount being received
+```
+SUM( select Quantity from Senders ) = SUM( select Quantity from Recipients ) + Count( Senders ) * SenderFee
+```
+
+- Ensure the sender N_OPERATION values are correct 
+```
+for-all s in Senders
+    s.NOperation = SafeBox.Accounts[s.Account].NOperation + 1
+```
+
+- Ensure that all senders sign the entire message **except the signature portion**
+```
+let signedPortion = select bytes from (SenderCount...Payload) of Multi-Transaction
+for-all s in Senders    
+    ECDSA_VerifySignature(s.Signature, signedPortion, SafeBox[s.Account].PublicKey) = True 
+```
+
+#### 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
+```
+OPHASH(MultiTransaction) = RIPEMD160 ( select bytes (SenderCount...Payload)  from MultiTransaction ) 
+```
+
+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.
+
+## Rationale
+
+Other methods of anonymity are in development and will either rely or benefit from this proposal. As a result, implementing this PIP delivers an overwhelming gain for virtually zero costs. 
+
+## Backwards Compatibility
+
+This change is not backwards compatible and requires a hard-fork activation.
+
+## Links
+
+1. [PIP-009: RandomHash: GPU & ASIC Resistant Hash Algorithm][1]
+
+[1]: https://github.com/PascalCoin/PascalCoin/blob/master/PIP/PIP-0009.md

PIP/README.md

@@ -23,5 +23,6 @@ If they wish to continue, copy [this template](PIP-template.md) and ensure your
 | [14](PIP-0014.md)     | New operation to certify accounts for extended recovery period   | Dr. Muhammad Amer       | Protocol       | Proposed |
 | [15](PIP-0015.md)     | Fast Block Propagation                   | Herman Schoenfeld              | Protocol       | Proposed |
 | [16](PIP-0016.md)     | Layer-2 protocol support                 | Herman Schoenfeld              | Protocol       | Proposed |
+| [17](PIP-0017.md)     | Anonymity via Transaction Mixing (phase-1)   | Herman Schoenfeld              | Protocol       | Proposed |