PascalCoin/PIP/PIP-0017.md

  PIP: PIP-0017
  Title: Anonymity via Transaction Mixing (phase-1)
  Type: Protocol
  Impact: Hard-Fork
  Author: Herman Schoenfeld <[email protected]>
  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0017)
  Status: Proposed
  Created: 2018-01-04

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, 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