PascalCoin/PIP/PIP-0017.md

  PIP: PIP-0017
  Title: MULTI-OP: atomic batch operations 
  Type: Protocol
  Impact: Hard-Fork
  Author: Herman Schoenfeld <[email protected]>
  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0017)
  Status: Active
  Created: 2018-01-04

Summary

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

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

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

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-OPERATION is proposed as follows:

New Operation: MULTI-OPERATION

• 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 : QWord - amount N'th sender is sending

• SenderNOperation_N: DWord - the new N_OPERATION value of N'th senders account

• RecipientCount: DWord - 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

• Fee: QWORD - network fee payable to the miner

• ChangeKeyCount : DWord - the number of accounts that will be changing key (U)

• ChangeKeyAccount_1 : DWord - the first account that will have key changed

• ChangeKeyAccountNOperation_1 : DWord - resulting NOperation of ChangeKeyAccount_1

  . . .

• ChangeKeyAccount_U : DWord - the U'th account that will have key changed

• ChangeKeyAccountNOperation_U : DWord - resulting NOperation of ChangeKeyAccount_U

• NewKey_1 - the new key associated to ChangeKeyAccount_1

  . . .

• NewKey_U - the new key associated to ChangeKeyAccount_U

• Payload: operation payload

• SenderSignature_1: signature blob of first sender

  . . .

• SenderSignature_N: signature blob of N'th sender

• ChangeKeySignature_1: signature blob of first sender

  . . .

• ChangeKeySignature_N: signature blob of N'th sender

Consensus Rules

• Ensure no duplicate sender or change key accounts

  Length( SELECT SenderAccount FROM MULTI-OPERATION ) = Length( SELECT DISTINCT SenderAccount FROM MULTI-OPERATION )
  
  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.

• Ensure fee covers all operations

  Fee >= (SenderCount + RecipientCount + ChangeKeyCount) * MIN_FEE   
  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-OPERATION.

• Ensure at least 1 sender

  SenderCount > 0
  

• Ensure at least 1 recipient

  RecipientCount > 0
  

• Ensure all senders have enough to send

  for-all s in Senders 
  SafeBox.Accounts[s.Account].Balance >= s.Quantity
  

• Ensure the amount being spent balances the amount being received

  SUM( select Quantity from Senders ) = SUM( select Quantity from Recipients ) + Fee
  

• Ensure the sender N_OPERATION values are correct

  for-all s in Senders
  s.NOperation = SafeBox.Accounts[s.Account].NOperation + 1
  

• Ensure the change key N_OPERATION values are correct

  for-all c in ChangeKeyAccounts
  var expectedNOperation = SafeBox.Accounts[c.Account].NOperation + 1
  if Senders.Contains(c.Account)
     expectedNOperation = expectedNOperation + 1
      
  c.NOperation = expectedNOperation
  

• 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-OPERATION
  for i := 1 to SenderCount
  let sender := SafeBox[SenderAccount_i]
  ECDSA_VerifySignature(SenderSignature_i, signedPortion, sender.PublicKey) = True 
  
  for i := 1 to ChangeKeyCount
  let changer = SafeBox[ChangeKeyAccount_i]
  ECDSA_VerifySignature(ChangeKeySignature_i, signedPortion, changer.PublicKey) = True     
  

Segregated Signatures during OPHASH

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(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.

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