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.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Similar content being viewed by others
Notes
- 1.
Matching transaction inputs to outputs after reordering is in general already an NP-complete problem (subset sum). However, most transactions will only have few inputs and outputs, which can make linking feasible in practice without this additional measure.
References
Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008)
Bech, M.L., Garratt, R.: Central bank cryptocurrencies (2017)
Mills, D., et al.: Distributed ledger technology in payments, clearing, and settlement. Board of Governors of the Federal Reserve System, Washington (2016). https://doi.org/10.17016/FEDS.2016.095
Wilkins, C.A.: Fintech and the financial ecosystem: Evolution or revolution? (2016). http://www.bankofcanada.ca/wp-content/uploads/2016/06/remarks-170616.pdf
Mas working with industry to apply distributed ledger technology in securities settlement and cross border payments (2017). http://www.mas.gov.sg/News-and-Publications/Media-Releases/2017/MAS-working-with-industry-to-apply-Distributed-Ledger-Technology.aspx
Koning, J.P.: Fedcoin: a central bank-issued cryptocurrency. R3 Report, 15 (2016)
Danezis, G., Meiklejohn, S.: Centrally banked cryptocurrencies. In: 23nd Annual Network and Distributed System Security Symposium, NDSS 2016, San Diego, California, USA, 21–24 February 2016
Ingves, S.: The e-krona and the payments of the future (2018). https://www.riksbank.se/globalassets/media/tal/engelska/ingves/2018/the-e-krona-and-the-payments-of-the-future.pdf
Billner, A.: Now there are plans for ‘e-krona’ in cash-shy sweden (2018). https://www.bloomberg.com/news/articles/2018-10-26/riksbank-to-develop-pilot-electronic-currency-amid-cash-decline
Maxwell, G.: Confidential transactions (2015). https://people.xiph.org/~greg/confidential_values.txt
Jedusor, T.E.: Mimblewimble. http://mimblewimble.org/mimblewimble.txt
Ben-Sasson, E., et al.: Zerocash: decentralized anonymous payments from bitcoin. In: 2014 IEEE Symposium on Security and Privacy (SP), pp. 459–474. IEEE (2014)
Garman, C., Green, M., Miers, I.: Accountable privacy for decentralized anonymous payments. In: Grossklags, J., Preneel, B. (eds.) FC 2016. LNCS, vol. 9603, pp. 81–98. Springer, Heidelberg (2017). https://doi.org/10.1007/978-3-662-54970-4_5
Camenisch, J., Hohenberger, S., Lysyanskaya, A.: Balancing accountability and privacy using E-cash (extended abstract). In: De Prisco, R., Yung, M. (eds.) SCN 2006. LNCS, vol. 4116, pp. 141–155. Springer, Heidelberg (2006). https://doi.org/10.1007/11832072_10
31 CFR 1010.330 - Reports relating to currency in excess of \$10,000 received in a trade or business (2012). https://www.law.cornell.edu/cfr/text/31/1010.330
Pedersen, T.P.: Non-interactive and information-theoretic secure verifiable secret sharing. In: Feigenbaum, J. (ed.) CRYPTO 1991. LNCS, vol. 576, pp. 129–140. Springer, Heidelberg (1992). https://doi.org/10.1007/3-540-46766-1_9
Fiat, A., Shamir, A.: How to prove yourself: practical solutions to identification and signature problems. In: Odlyzko, A.M. (ed.) CRYPTO 1986. LNCS, vol. 263, pp. 186–194. Springer, Heidelberg (1987). https://doi.org/10.1007/3-540-47721-7_12
Pointcheval, D., Stern, J.: Security proofs for signature schemes. In: Maurer, U. (ed.) EUROCRYPT 1996. LNCS, vol. 1070, pp. 387–398. Springer, Heidelberg (1996). https://doi.org/10.1007/3-540-68339-9_33
Samarati, P., Sweeney, L.: Protecting privacy when disclosing information: k-anonymity and its enforcement through generalization and suppression. Technical report, SRI International (1998)
Pointcheval, D., Sanders, O.: Short randomizable signatures. In: Sako, K. (ed.) CT-RSA 2016. LNCS, vol. 9610, pp. 111–126. Springer, Cham (2016). https://doi.org/10.1007/978-3-319-29485-8_7
Camenisch, J., Lysyanskaya, A.: A signature scheme with efficient protocols. In: Cimato, S., Persiano, G., Galdi, C. (eds.) SCN 2002. LNCS, vol. 2576, pp. 268–289. Springer, Heidelberg (2003). https://doi.org/10.1007/3-540-36413-7_20
Camenisch, J., Lysyanskaya, A.: Signature schemes and anonymous credentials from bilinear maps. In: Franklin, M. (ed.) CRYPTO 2004. LNCS, vol. 3152, pp. 56–72. Springer, Heidelberg (2004). https://doi.org/10.1007/978-3-540-28628-8_4
Aranha, D.F., Gouvêa, C.P.L.: RELIC is an Efficient LIbrary for Cryptography. https://github.com/relic-toolkit/relic
Bünz, B., Bootle, J., Boneh, D., Poelstra, A., Wuille, P., Maxwell, G.: Bulletproofs: Efficient range proofs for confidential transactions. Technical report, Cryptology ePrint Archive, Report 2017/1066 (2017). https://eprint.iacr.org/2017/1066
Castro, M., Liskov, B.: Practical byzantine fault tolerance. In: Proceedings of the Third Symposium on Operating Systems Design and Implementation, OSDI 1999, pp. 173–186. USENIX Association, Berkeley, CA, USA (1999)
Croman, K., et al.: On scaling decentralized blockchains. In: Clark, J., Meiklejohn, S., Ryan, P.Y.A., Wallach, D., Brenner, M., Rohloff, K. (eds.) FC 2016. LNCS, vol. 9604, pp. 106–125. Springer, Heidelberg (2016). https://doi.org/10.1007/978-3-662-53357-4_8
Zcash. https://z.cash/
Kappos, G., Yousaf, H., Maller, M., Meiklejohn, S.: An empirical analysis of anonymity in zcash. In: 27th USENIX Security Symposium (USENIX Security 18), pp. 463–477. USENIX Association, Baltimore, MD (2018)
Pedersen, T.P.: A threshold cryptosystem without a trusted party. In: Davies, D.W. (ed.) EUROCRYPT 1991. LNCS, vol. 547, pp. 522–526. Springer, Heidelberg (1991). https://doi.org/10.1007/3-540-46416-6_47
Desmedt, Y., Frankel, Y.: Threshold cryptosystems. In: Brassard, G. (ed.) CRYPTO 1989. LNCS, vol. 435, pp. 307–315. Springer, New York (1990). https://doi.org/10.1007/0-387-34805-0_28
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
A Transaction Details and Block Creation
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.Footnote 1
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]).
Rights and permissions
Copyright information
© 2019 International Financial Cryptography Association
About this paper
Cite this paper
Wüst, K., Kostiainen, K., Čapkun, V., Čapkun, S. (2019). PRCash: Fast, Private and Regulated Transactions for Digital Currencies. In: Goldberg, I., Moore, T. (eds) Financial Cryptography and Data Security. FC 2019. Lecture Notes in Computer Science(), vol 11598. Springer, Cham. https://doi.org/10.1007/978-3-030-32101-7_11
Download citation
DOI: https://doi.org/10.1007/978-3-030-32101-7_11
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-030-32100-0
Online ISBN: 978-3-030-32101-7
eBook Packages: Computer ScienceComputer Science (R0)