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