Browse Source

PIP-0017: added PASA exchanging into MULTI-TRANSACTION

Herman Schoenfeld 7 years ago
parent
commit
cebece2b05
1 changed files with 70 additions and 15 deletions
  1. 70 15
      PIP/PIP-0017.md

+ 70 - 15
PIP/PIP-0017.md

@@ -11,7 +11,7 @@
 
 ## 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. 
+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!
 
 ## Motivation
 
@@ -27,7 +27,11 @@ As phase-2 of anonymity, the network protocol will be upgraded via soft-fork to
 
 **Chaining Multi-Transactions**
 
-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-Transactions 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).
 
 **Monetized-API Mixing**
 
@@ -49,9 +53,9 @@ A new operation called MULTI-TRANSACTION is proposed as follows:
     .
 
 - SenderAccount_N : DWord - N'th sender account
-- SenderQuantity_N : DWord - amount N'th sender is sending
+- SenderQuantity_N : QWord - 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)
+- RecipientCount: DWord - number of recipient accounts (M)
 - RecipientAccount_1: DWord - first recipient account
 - RecipientQuantity_1 : QWord - amount first recipient is receiving
 
@@ -61,22 +65,58 @@ A new operation called MULTI-TRANSACTION is proposed as follows:
 
 - RecipientAccount_M : DWord - M'th recipient
 - RecipientQuantity_M : QWord - amount M'th recipient is receiving
-- SenderFee: network fee payable to miners **per sender**
+- 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 of first sender
+- SenderSignature_1: signature blob of first sender
+
+    .
+    .
+    .
+
+- SenderSignature_N: signature blob of N'th sender
+- ChangeKeySignature_1: signature blob of first sender
 
     .
     .
     .
 
-- SenderSignature_N: signature of N'th sender
+- ChangeKeySignature_N: signature blob of N'th sender
 
 **Consensus Rules**
-- Ensure fee per sender is non-zero
+
+- Ensure no duplicate sender or change key accounts
 ```
-SenderFee > 0
+Length( SELECT SenderAccount FROM MULTI-TRANSACTION ) = Length( SELECT DISTINCT SenderAccount FROM MULTI-TRANSACTION )
+
+Length( SELECT ChangeKeyAccount FROM MULTI-TRANSACTION ) = Length( SELECT DISTINCT ChangeKeyAccount FROM MULTI-TRANSACTION )
 ```
+**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**: accounts that change keys do **not** pay a fee. In practice, a user wanting to include a ChangeKeyAccount operation should also pro single user can include a SenderAccount to pay for the fee of both SenderAccount and ChangeKeyAcount.
 - Ensure at least 1 sender
 ```
 SenderCount > 0
@@ -90,12 +130,12 @@ 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
+    SafeBox.Accounts[s.Account].Balance >= s.Quantity + UnitFee
 ```
 
 - Ensure the amount being spent balances the amount being received
 ```
-SUM( select Quantity from Senders ) = SUM( select Quantity from Recipients ) + Count( Senders ) * SenderFee
+SUM( select Quantity from Senders ) = SUM( select Quantity from Recipients ) + Fee
 ```
 
 - Ensure the sender N_OPERATION values are correct 
@@ -104,11 +144,26 @@ 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**
+- 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) of Multi-Transaction
-for-all s in Senders    
-    ECDSA_VerifySignature(s.Signature, signedPortion, SafeBox[s.Account].PublicKey) = True 
+let signedPortion = select bytes from (SenderCount...Payload) portion of MULTI-TRANSACTION
+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 ###