PRCash: Fast, Private and Regulated Transactions for Digital Currencies

Abstract

Fiat currency implemented as a blockchain can enable multiple benefits such as reduced cost compared to expensive handling of cash and better transparency for increased public trust. However, such deployments have conflicting requirements including fast payments, strong user privacy and regulatory oversight. None of the existing blockchain transaction techniques supports all of these three requirements. In this paper we design a new blockchain currency, called PRCash, that addresses the above challenge. The primary technical contribution of our work is a novel regulation mechanism for transactions that use cryptographic commitments. We enable regulation of spending limits using zero-knowledge proofs. PRCash is the first blockchain currency that provides fast payments, good level of user privacy and regulatory control at the same time.

A Transaction Details and Block Creation

In this Appendix, we provide the details of the modifications made to Mimblewimble [11] transactions, prove that knowledge of the blinding factors can be used for payment authorization, and we give an overview of how transactions can be mixed and blocks can be created.

1.1 A.1 Transaction Creation

To prevent the transaction tracking of Mimblewimble [11] transactions, mentioned in Sect. 3, we modify the transaction creation such that the payer finalizes the transaction. To increase payment anonymity further, we also include another output ($r_\varDelta$) that does not have a value attached. This additional output is submitted to the validators as a scalar such that multiple transactions can be merged. Inclusion of such additional output makes it impossible to later match transaction inputs to corresponding outputs.¹

Our transaction creation protocol, that includes the regulation proofs explained above, works as follows:

• (i) The recipient, Bob, creates k value outputs $\mathsf {Out}_i = g^{r_i'} h^{v_i'}$ ($1 \le i \le k$), for the payment value $v_T = \sum _{i=1}^k v'_i$. For each of the value outputs, he also creates a range proof to prove that the value is in a valid range (i.e., that no overflow occurs where money is created out of nothing). He additionally attaches a regulation proof to each output as described above in Sect. 3.4. He then creates an excess output $\mathsf {Ex}_0 = g^{r_0'}$ that has no value attached, proves knowledge of $r_0'$ by proving knowledge of the discrete log of $\mathsf {Ex}_0$ to base g (DLProof($\mathsf {Ex}_0$)) and sends his outputs (including range proofs, proof of knowledge of $r_0'$ and regulation proofs), $v_T$ and $r' = r'_0 + \sum _{i=1}^k r'_i$ to Alice. The additional excess output $\mathsf {Ex}_0$ is required to ensure that only Bob can spend his newly created outputs. Otherwise Alice would know the sum of the blinding factors of his outputs and could thus spend them.

• (ii) If Alice agrees with the transaction value $v_T$, with her inputs $\mathsf {In}_i = g^{r_i} h^{v_i}$ ($1 \le i \le n$), s.t. $v = \sum _{i=1}^n v_i$ and $r = \sum _{i=1}^n r_i$, she creates m change outputs $\mathsf {Out}_i = g^{r_i'} h^{v_i'}$ ($k < i\le k+m$), s.t. $v - \sum _{i=k+1}^{k+m} v_i' = v_T$ and range proofs and regulation proofs for these outputs. She then computes a delta output $r_\varDelta = r - \sum _{i=k+1}^{k+m} r_i' - r'$ and combines all of her inputs, Bob’s and her outputs (including all proofs) and $r_\varDelta$ into a complete transaction. Alice’ inputs are outputs of previous transactions that can be money issuing transactions as described in Appendix A.4.

• (iii) Finally, Alice sends the complete transaction to one or more validators, encrypted under their public keys. The number of validators depends on the used transaction validation strategy (see Sect. 5).

The validators then verify the transaction as described in Sect. 3.5.

1.2 A.2 Mixing and Consensus

The validators collect a set of verified transactions and in the end of the round mix them by using two merging properties of our transactions. The first merging option is to combine two valid transactions together which creates another valid transaction. Combining several transactions into one large transaction breaks the direct correlation between inputs and outputs in the original transactions. The more transactions are combined in one round, the harder it is for third parties to link inputs and outputs based on published, combined transactions. Since the order of inputs and outputs is irrelevant for the correctness of a transaction, they can be reordered arbitrarily (e.g. ordered in binary order). Additionally, by only publishing the sum of the delta outputs instead of the individual values, deciding which set of transaction outputs belong to which set of inputs becomes impossible.

The second merging option is compacting. If an output of one transaction appears as an input in another transaction, the matching input-output pair can be simply be removed, resulting in a smaller but still valid transaction. Compacting makes transaction linking more difficult and improves storage efficiency. Once the validator has verified and merged (mixed) all received transactions in the current round, the remaining inputs and outputs can be simply sorted as a list for publishing.

The validators then need to achieve consensus over the content of the next block depending and we assume that they run a Byzantine fault tolerant consensus protocol to protect against double spending. Validators can cache unspent transaction outputs from all previous blocks to speed up verification of new transactions (needed for double-spending protection). After achieving consensus over a block, validators can remove all inputs of the block from their cached set and add all new outputs to it.

1.3 A.3 Block Structure

Each block consists of a first part signed by the validators and a second part containing auxiliary information. The first signed part contains the sum of all delta outputs, all excess outputs including the zero-knowledge proofs of their exponents, and the hash of the previous block. Additionally, if the block contains an issuance or a deletion transaction, the signed part also contains the explicit amounts of money that are added or removed. As auxiliary information, the block contains a list of inputs and a list of outputs including their range proofs.

The signed part of the block only contains the excess outputs and the sum of the delta outputs of all transactions ($\mathsf {Ex}_0$, $\mathsf {Ex}_1$ and $r_\varDelta + r_\varDelta '$ in the example). The transaction inputs and transaction outputs with a value do not need to be included in the signed part, but they still need to be published including the range proofs of the outputs, so that other parties can verify the correctness of the blockchain.

This block structure allows compression of the blockchain by compacting transactions across blocks. Outputs of previous transactions that are used as inputs in the new block can be removed from storage without losing the ability to verify the complete chain. All that is required for the verification is the set of unspent transaction outputs, excess and delta outputs of all blocks, and the values of issuance and deletion transactions. All of this combined can be interpreted as one large transaction that, if valid, implies the validity of the whole blockchain. This makes the storage required to verify the full chain very small and slowly growing for third parties that do not want to store all transactions.

1.4 A.4 Issuance

Our currency provides an explicit mechanism for the issuer to increase, or decrease, the amount of currency in circulation. This can be done with a special transaction type that requires a signature from the issuer.

Specifically, the issuer can publish an issuance transaction with an explicitly stated amount v. The issuer creates k transaction outputs $\mathsf {Out}_i = g^{r_i'} h^{v_i'}$ ($1 \le i \le k$), such that $v = \sum _{i=1}^k v'_i$, and which all have a range proof attached. The issuer then additionally creates an excess output $\mathsf {Ex}_0 = g^{r_0'}$, s.t. $r_0' + \sum _{i=1}^{k} r_i' = 0$ and proves knowledge of $r_0'$. The transaction is valid, if $h^v$ is equal to the sum of the outputs. The outputs created by such an issuing transaction could, e.g., be transferred to commercial banks who can then further distribute the newly created money. The issued amount v is published in plaintext to the next block with the issuance transaction.

The role of the issuer can easily be distributed among multiple parties by requiring signatures from multiple parties for issuance transactions. This may be particularly interesting for private deployments, where there is no central bank that can be assumed to be trusted.

1.5 A.5 Distributing Regulation

The role of the regulator can be distributed between multiple parties without changes to the rest of the system by using a threshold cryptosystem. In such a scheme, a set of n parties would be responsible for regulation, of which at least a threshold number k must cooperate to decrypt an encrypted identity. To set up the system, the regulator parties would run a key generation protocol that creates a public key and distributes shares of the corresponding secret key to the parties. The created public key is then used as the regulator public key in our system.

Since we use Elgamal encryption in our system, which can be used for threshold encryption (e.g. [29]), the process of encrypting identities and creating proofs does not differ from the system described in Sect. 3.4. In order to decrypt the ciphertexts without reconstructing the shared secret key, the regulator parties then again need to run a decryption protocol (e.g. [30]).