RingCT 2.0: A Compact Accumulator-Based (Linkable Ring Signature) Protocol for Blockchain Cryptocurrency Monero

Abstract

In this work, we initially study the necessary properties and security requirements of Ring Confidential Transaction (RingCT) protocol deployed in the popular anonymous cryptocurrency Monero. Firstly, we formalize the syntax of RingCT protocol and present several formal security definitions according to its application in Monero. Based on our observations on the underlying (linkable) ring signature and commitment schemes, we then put forward a new efficient RingCT protocol (RingCT 2.0), which is built upon the well-known Pedersen commitment, accumulator with one-way domain and signature of knowledge (which altogether perform the functions of a linkable ring signature). Besides, we show that it satisfies the security requirements if the underlying building blocks are secure in the random oracle model. In comparison with the original RingCT protocol, our RingCT 2.0 protocol presents a significant space saving, namely, the transaction size is independent of the number of groups of input accounts included in the generalized ring while the original RingCT suffers a linear growth with the number of groups, which would allow each block to process more transactions.

1 Introduction

1.1 Monero: A Blockchain-Based Cryptocurrency

A cryptocurrency is a digital asset designed to work as a medium of exchange using cryptography to secure the transactions and to control the creation of additional units of the currency. Bitcoin became the first decentralized cryptocurrency in 2009. Since then, numerous cryptocurrencies have been created. Bitcoin and its derivatives use decentralized control as opposed to centralized electronic money or centralized banking systems. The decentralized control is related to the use of blockchain transaction database in the role of a distributed ledger.

Major advantages of cryptocurrency include decentralized control and anonymous payment, when compared to the traditional credit card or debit card system. However, the anonymity provided by bitcoin has been questioned in the sense it offers pseudonymity instead of offering a true anonymity. For instance, there is a research that identifyies ownership relationships between Bitcoin addresses and IP addresses [20]. Bitcoin proxy or even other users may still compute the actual identity of a bitcoin’s owner. Although there are various improvements to enhance the anonymity of bitcoin (e.g. [31]), they are far from practical and satisfactory.

One of the first attempt to provide anonymity in cryptocurrency is Dash (released in 2014), which anonymizes the transaction process by mixing coins. Nevertheless, it does not formally provide cryptographic anonymity. Another attempt to provide anonymity in cryptocurrency is ZCash [8] (released in 2016), which uses zero-knowledge succinct non-interactive argument of knowledge (zk-SNARKs) [9]. They provide anonymity with a formal security proof. They used zk-SNARKs to prove the knowledge of pre-image of hash functions in which the proof generation process is rather expensive. Therefore, the efficiency is much worse than the normal bitcoin transaction (for the sender side, it takes a few minutes to perform a spent computation).

Monero is an open-source cryptocurrency created in April 2014 that focuses on privacy, decentralisation and scalability. The current market value of Monero is already over US$750M¹, which is one of the largest cryptocurrencies. Unlike many cryptocurrencies that are derivatives of Bitcoin, Monero is based on the CryptoNote protocol and possesses significant algorithmic differences relating to blockchain obfuscation. Monero daemon is mainly based on the original CryptoNote protocol, which deploys “one-time ring signatures” as the cored crypto-primitive to provide anonymity. Monero further improves the protocol by using a variant of linkable ring signature [22], which is called Ring Confidential Transactions (RingCT) [24].

On 10 January 2017, RingCT has been put into Monero transactions, starting at block #1220516. RingCT transactions are enabled by default at this stage, but it is still possible to send a transaction without RingCT until the next hard fork in September 2017. In the first month after implementation, it has been reported that approximately 50–60% of transactions used the optional RingCT feature.²

Upon the enhancement of privacy, a major trade-off is the increase of size for the transaction, due to the size of the linkable ring signature in the RingCT protocol. Although RingCT has already shortened the size of the ring signature by 50% when compared to the original CryptoNote protocol, it is still linear with the number of public keys included in the ring.

1.2 Ring Signature and Linkable Ring Signature

A ring signature scheme (e.g., [1, 26, 33]) allows a member of a group to sign messages on behalf of the group without revealing his identities, i.e. signer anonymity. In addition, it is not possible to decide whether two signatures have been issued by the same group member. Different from a group signature scheme (e.g., [6, 10, 12]), the group formation is spontaneous and there is no group manager to revoke the identity of the signer. That is, under the assumption that each user is already associated with a public key of some standard signature scheme, a user can form a group by simply collecting the public keys of all the group members including his/her own. These diversion group members can be totally unaware of being conscripted into the group.

Ring signature provides perfect (or unconditional) anonymity. However, it may be too strong in some scenario. For example, in the case of anonymous e-voting, it is necessary to detect if someone has submitted his vote more than once so that the second casting should not be counted. Similar concerns should be applied into anonymous e-cash system. A double-spent payment should be discarded. In both scenarios, a linkable-anonymity is necessary, instead of the strongest form, unconditional anonymity. Linkable ring signature [22] provides a perfect characteristic of linkable anonymity: verifier knows nothing about the signer, except that s/he is one of the users in the group (represented by the list of public keys/identities). Yet given any two linkable signatures, the verifier knows that whether they are generated by the same signer (even though the verifier still does not know who the actual signer is).

1.3 Our Contributions

The contributions of this paper are twofold. First, we give a rigorous security definition and requirement of RingCT protocol. We note that in the original paper of RingCT [24], there is no rigorous security definition but just a direct instantiation of the protocol. A rigorous security definition would definitely help future researchers to develop better improvement of RingCT. Second, we target to reduce the size of the RingCT protocol. Our new RingCT protocol (we call it RingCT 2.0) is based on the well-known Pedersen commitment, accumulator with one-way domain and signature of knowledge related to the accumulator. The accumulator and the signature of knowledge together perform the functions of a linkable ring signature. In particular, the size of signature in our protocol is independent to the number of groups of input accounts in a transaction. We argue that it can significantly shorten the size of each block, when compared to the original protocol (which is linear with the number of groups of accounts included in the generalized ring for the anonymizing purpose) especially when the number of groups grows larger. More importantly, our construction fits perfectly into the framework of the RingCT definition, which makes it suitable to be deployed in Monero.

2 Related Works

Linkable ring signature was first proposed by Liu et al. [22] in 2004 (they named it as Linkable Spontaneous Anonymous Group Signature which is actually linkable ring signature). There are many variants in different types of cryptosystems with different features. We summarize their features in Table 1.

Table 1. Comparison of linkable ring signatures

As we can see from the table, there are only a few constant size linkable ring signature existed in the literature. In our discussion, we focus on public key only because both identity-based and certificate-based cryptosystems are not suitable for blockchain paradigm as they require a Private Key Generator (PKG) to issue user keys, which contradicts to the decentralized concept of blockchain. Among them, [29] requires the Certificate Authority (CA) to generate the user key. [2] is an improvement over [29] but it still requires an interaction between the user and the CA during the user key generation process. Neither of them is suitable for blockchain.

We note that not all linkable ring signature schemes are suitable for Monero. There are some requirements that should be satisfied in order to be compatible with RingCT. We will discuss more on this in Sect. 4.

3 Preliminaries

In this section, we first give some notations used in the rest of this paper. We use [n] to denote the set of integers $\{1, 2, \ldots , n\}$ for some positive integer $n\in \mathbb {N}$. For a randomized algorithm $\mathrm {A}(\cdot )$, we write $y=\mathrm {A}(x; r)$ to denote the unique output of $\mathrm {A}$ on input x and randomness r, and denote by $y\leftarrow \mathrm {A}(x)$ the process of picking randomness r at random and setting $y=A(x;r)$. Also, we write $x\leftarrow S$ for sampling an element uniformly at random from a set S, and use $negl(\lambda )$ to denote some negligible function in a security parameter $\lambda$.

3.1 Mathematical Assumptions

Bilinear Pairings. Let $\mathbb {G}_1$ and $\mathbb {G}_2$ be two cyclic groups of prime order p, and g be a generator of $\mathbb {G}_1$. A function $e: \mathbb {G}_1\times \mathbb {G}_1\rightarrow \mathbb {G}_2$ is a bilinear map if the following properties hold:

• Bilinearity: $e(A^x, B^y)=e(A, B)^{xy}$ for all $A, B\in \mathbb {G}_1$ and $x, y\in \mathbb {Z}_p$;

• Non-degeneracy: $e(g, g)\ne 1$, where 1 is the identity of $\mathbb {G}_2$;

• Efficient computability: there exists an algorithm that can efficiently compute e(A, B) for all $A, B\in \mathbb {G}_1$.

Decisional Diffie-Hellman (DDH) Assumption. Let $\mathbb {G}$ be a group where $|\mathbb {G}|=q$ and $g\in \mathbb {G}$ such that $\langle g \rangle ={\mathbb {G}}$. There exists no probabilistic polynomial time (PPT) algorithm that can distinguish the distributions $(g, g^a,g^b,g^{ab})$ and $(g, g^a, g^b, g^c)$ with non-negligible probability over 1/2 in time polynomial in q, where a, b, c are chosen uniformly at random from ${\mathbb {Z}}_q$.

k-Strong Diffie-Hellman (${\varvec{k}}$-SDH) Assumption. There exists no PPT algorithm which, on input a $k+1$-tuple $(g_0, g_0^{\alpha }, g_0^{\alpha ^2}, \ldots , g_0^{\alpha ^{k}})\in \mathbb {G}^{k+1}$, returns a pair $(w, y)\in \mathbb {G}\times \mathbb {Z}_p^*$, where $\mathbb {G}=\langle g_0\rangle$ and p is the order of $\mathbb {G}$, such that $w^{\alpha +y}=g_0$, with non-negligible probability and in time polynomial in $\lambda$.

3.2 Building Blocks

In this section, we briefly recall the basic primitives used to construct our RingCT protocol, which include accumulator with one-way domain, signature of knowledge and homomorphic commitment scheme.

Accumulators with One-Way Domain. As defined in [5, 14], an accumulator accumulates multiple values into one single value such that, for each value accumulated, there is a witness proving that it has indeed been accumulated. Formally, let $\mathcal {F}=\{F_{\lambda }\}$ be a sequence of families of functions and $\mathcal {X}=\{X_{\lambda }\}$ a sequence of families of finite sets, such that $F_{\lambda }=\{f: U_f\times X_f\rightarrow U_f\}$ and $X_{\lambda }\subseteq X_f$ for all $\lambda \in {\mathbb {N}}$, we call the pair $(\mathcal {F}, \mathcal {X})$ an accumulator family with one-way domain if the following conditions hold:

• quasi-commutativity: for all $\lambda \in {\mathbb {N}}, f\in F_\lambda , u\in U_f$ and $x_1, x_2\in X_\lambda$, it holds that $f(f(u, x_1), x_2)=f(f(u, x_2), x_1)$. $\{X_\lambda \}$ is always referred to as the domain of this accumulator. For any $X=\{x_1, x_2, \cdots , x_n\}\subset X_\lambda$, we further refer to $f(\cdots f(u, x_1)\cdots x_n)$ as the accumulated value of X over u, which will be denoted by f(u, X) thanks to this quasi-commutative property.

• collision-resistance: for all $\lambda \in {\mathbb {N}}$ and efficient adversaries $\mathcal {A}$, it holds that

  $$\begin{aligned} \Pr \,\left[ \begin{array}{l} X\subset X_\lambda \wedge (x\in X_f\backslash X)\\ (w\in U_f) \wedge (f(w, x)=f(u, X)) \end{array} : \begin{array}{l} f\leftarrow F_\lambda ; u \leftarrow U_f;\\ (x, w, X)\leftarrow \mathcal {A}(f, U_f, u) \end{array} \right] \le negl(\lambda ). \end{aligned}$$

• one-way domain: let $\{Y_\lambda \}, \{R_\lambda \}$ be two sequences of families of sets associated with $\{X_\lambda \}$, such that each $R_\lambda$ is an efficiently verifiable, samplable relation over $Y_\lambda \times X_\lambda$ and it is infeasible to efficiently compute a witness $y'\in Y_\lambda$ for an x sampled from $X_\lambda$. That is,

  $$\begin{aligned} \Pr \,[(y', x)\in R_\lambda : (y, x)\leftarrow \textsf {Samp}(1^\lambda ); y'\leftarrow \mathcal {A}(1^\lambda , x)]\le negl(\lambda ), \end{aligned}$$

  where Samp denotes the efficient sampling algorithm over $R_\lambda$.

• efficient generation: there exists an efficient algorithm denoted by ACC.Gen that on input a security parameter $\lambda$ outputs a description $\textsf {desc}$ of a random element of $F_\lambda$, possibly including some auxiliary information.

• efficient evaluation: for $\lambda \in {\mathbb {N}}, f\in F_\lambda , u\in U_f$ and $X\subset X_\lambda$, $w\in U_f$ is called a witness for the fact that $x\in X$ has been accumulated within $v\doteq f(u, X)\in U_f$ iff $f(w, x)=v$. There exists two algorithms denoted by ACC.Eval and ACC.Wit that on input (desc, X) and (desc, x, X) can efficiently evaluate the accumulated value f(u, X) and the witness for x in f(u, X), respectively.

For sake of simplicity, we will denote by $\textsf {ACC}=(\textsf {ACC.Gen}, \textsf {ACC.Eval}, \textsf {ACC.Wit})$ such an accumulator with one-way domain in the following.

Signature of Knowledge. Every three-move Proof of Knowledge protocols (PoKs) that is Honest-Verifier Zero-Knowledge (HVZK) can be transformed into a signature scheme by setting the challenge to the hash value of the commitment concatenated with the message to be signed [16]. Signature schemes generated as such are provably secure [25] against existential forgery under adaptively chosen message attack in the random oracle model [7]. They are sometimes referred to as Signatures of Knowledge, SoK for short [10]. As an example, we denote by $\mathrm {SoK}\{(x):y=g^x\}(\textit{m})$, where $\textit{m}$ is the message, the signature scheme derived from the zero-knowledge proof of the discrete logarithm of y using the above technique. Before presenting the formal definition of SoK, we first let R be a fixed NP-hard relation with the corresponding language $\mathtt {L}=\{y: \exists ~x ~s.t~ (x, y)\in \mathtt {R}\}$. Recall that a relation is called hard if it is infeasible for any efficient algorithm, given some instance y, to compute a valid witness such that $(x, y)\in \texttt {R}$. In general, signature of knowledge protocol for R over message space $\mathcal {M}$ comprises of a triple of poly-time algorithms (Gen, Sign, Verf) with the following syntax:

• Gen($1^{\lambda }$): on input a security parameter $\lambda$, the algorithm outputs public parameters $\textsf {par}$, which will be implicitly taken as part input of the following algorithms. Also, we assume that $\lambda$ is efficiently recoverable from $\textsf {par}$.

• Sign(m, x, y): on input a message $m\in \mathcal {M}$ and a valid pair $(x, y)\in \mathtt {R}$, the algorithm outputs an SoK $\pi$.

• Verf($m, \pi$, y): on input a message m, an SoK $\pi$ and a statement y, the algorithm outputs 0/1 indicating the in/validity of the SoK.

Definition 1

(SimExt Security of SoK [11]). An SoK protocol $\textsf {SoK}=(\textsf {Gen},$ $\textsf {Sign}, \textsf {Verf})$ for hard relation R is called SimExt-secure if it satisfies the correct, simulatable and extractable properties as defined below.

Correctness.:

For any message $m\in \mathcal {M}$ and valid pair $(x, y)\in \texttt {R}$, it holds that

$$\begin{aligned} \Pr \,[\textsf {Verf}(m, \pi , y)=1: \textsf {par}\leftarrow \textsf {Gen}(1^\lambda ); \pi \leftarrow \textsf {Sign}(m, x, y)]\ge 1-negl(\lambda ), \end{aligned}$$

where if the probability is exactly 1 we call SoK perfectly correct.

Simulatability.:

There exists a poly-time simulator $\textsf {Sim}=(\textsf {SimGen}, \textsf {SimSign})$ such that for any PPT adversary $\mathcal {A}$, it holds that

where Sim receives an input (m, x, y), checks the validity of y and returns $\pi \leftarrow \textsf {SimSign}(m, x, y)$ if $(x,y)\in \texttt {R}$. In addition, td is the additional trapdoor information used by Sim to simulate signatures without knowing a witness.

Extraction.:

In addition to Sim, there exists an efficient extractor Ext such that for any PPT adversary $\mathcal {A}$, it holds that

$$\begin{aligned} \Pr \,\left[ \begin{array}{c} (x, y)\in \texttt {R}\vee (m, y)\in Q \\ \vee ~ \textsf {Verf}(m, y, \pi )=0 \end{array} : \begin{array}{l} (\textsf {par}, td)\leftarrow \textsf {SimGen}(1^\lambda );\\ (m, y, \pi )\leftarrow \mathcal {A}^{\textsf {Sim}(td, \cdot , \cdot , \cdot )}(\textsf {par})\\ x\leftarrow \textsf {Ext}(\textsf {par}, td, m, y, \pi ).\\ \end{array} \right] \ge 1-negl(\lambda ). \end{aligned}$$

where Q denotes the set of all queries (m, y) that $\mathcal {A}$ has made to Sim.

Homomorphic Commitment Schemes. Informally, a (non-interactive) commitment scheme includes two phases: in commit phase, a sender chooses a value and constructs a commitment to it; later in the reveal phase the sender may open the commitment and reveal the value. After that, the receiver can verify that it is exactly the value that was committed at first. More formally, a commitment scheme consists of a pair of poly-time algorithms $(\textsf {CKGen}, \textsf {Com})$: on input a security parameter $\lambda$, CKGen$(1^\lambda )$ outputs a public commitment key ctk, which specifies a message space $\mathcal {M}_{ctk}$ and a commitment space $\mathcal {C}_{ctk}$; on input a message $m\in \mathcal {M}_{ctk}$, $\textsf {Com}(ctk, m)$ generates a commitment $c\leftarrow \textsf {Com}(ctk, m)$ to m, where ctk is often omitted when it is clear from the context. Normally, a commitment scheme should satisfy the hiding and binding properties, as defined below.

Definition 2

(Security of HCom [19]). A non-interactive scheme $\textsf {HCom}=(\textsf {CKGen}, \textsf {Com})$ is called a secure homomorphic commitment scheme if it satisfies the following properties.

 

Hiding:

This property means that the commitment does not reveal the committed value. More precisely, HCom is called hiding if for all PPT adversaries $\mathcal {A}$, it holds that

$$\begin{aligned} \left| \Pr \,\left[ \mathcal {A}(c)=b: \begin{array}{l} ctk\leftarrow \textsf {CKGen}(1^\lambda ); (m_0, m_1)\leftarrow \mathcal {A}(ctk); \\ b\leftarrow \{0, 1\}; c\leftarrow \textsf {Com}(ctk, m_b) \end{array} \right] -\frac{1}{2}\right| \le negl(\lambda ), \end{aligned}$$

where $m_0, m_1\in \mathcal {M}_{ctk}$ and HCom is called perfectly hiding if the probability of $\mathcal {A}$ guessing b is exactly 1/2.

Binding.:

This property means that a commitment cannot be opened to two different values. More precisely, HCom is called binding if for all PPT adversaries $\mathcal {A}$, it holds that

$$\begin{aligned} \Pr \,\left[ \begin{array}{c} m_0\ne m_1 ~\wedge \\ \textsf {Com}(m_0; r_0)=\textsf {Com}(m_1; r_1) \end{array} : \begin{array}{l} ctk\leftarrow \textsf {CKGen}(1^\lambda ); \\ (m_0, r_0, m_1, r_1)\leftarrow \mathcal {A}(ctk) \end{array} \right] \le negl(\lambda ), \end{aligned}$$

where $m_0, m_1\in \mathcal {M}_{ctk}$ and $r_0, r_1$ are random coins of Com. HCom is called perfectly binding if the probability is exactly 0. Moreover, we call HCom strongly binding if the probability holds even for the condition $(m_0, r_0)\ne (m_1, r_1)$ rather than $m_0\ne m_1$.

Homomorphic.:

For this property, we assume that for each well-formed ctk, the commitment space $\mathcal {C}_{ck}$ is a multiplicative group of order q and both the messages and random coins are from ${\mathbb {Z}}_q$. This property says that for all $\lambda \in {\mathbb {N}}$, $ctk\leftarrow \textsf {CKGen}(1^\lambda )$, $m_0, m_1\in {\mathbb {Z}}_q$ and $r_0, r_1\in {\mathbb {Z}}_q$, it holds that

$$\begin{aligned} \textsf {Com}(m_0; r_0)\cdot \textsf {Com}(m_1; r_1)=\textsf {Com}(m_0 + m_1; r_0 + r_1). \end{aligned}$$

4 RingCT Protocol for Monero

In this section, we formalize ring confidential transaction (RingCT) protocol for Monero. Recall that Monero is based on CryptoNote, where each user may have a number of distinct accounts. Each account consists of a one-time address and a coin, and it is always associated with an account key used to authorize its spending. In each transaction, a user can spend many of her/his accounts with the corresponding keys. The goal of ring confidential transaction (RingCT) protocol is to protect the anonymity of spenders as well as the privacy of transactions.

Informally, a RingCT protocol mainly comprises of two phases: the generation and the verification of ring confidential transactions, which are operated by the spender and recipients respectively. When a user would like to spend m of her/his accounts, w.l.o.g., denoted by $A_s=\{(pk_{s}^{(k)}, cn_{s}^{(k)})\}_{k\in [m]}$ where $pk_{s}^{(k)}$ is the user’s k-th account address and $cn_{s}^{(k)}$ is the coin w.r.t. this account, s/he first chooses t output accounts $\{(pk_{out, j}, cn_{out, j})\}_{j\in [t]}$ for all output addresses $R=\{pk_{out, j}\}_{j\in [t]}$ accordingly, such that the sum of balances of her/his input accounts equals to that of output accounts, and then additionally selects $n-1$ groups of input accounts with each containing m different accounts to anonymously spend $A_s$ for some payments (i.e., creating a ring confidential transaction). Whenever receiving this transaction from the P2P blockchain network, the miners check the validity of the transaction with public information along with it and add it to a (new) block if valid.

By a thorough analysis of the protocol in [24], we find that the RingCT protocol essentially involves ring signatures and commitments (that are used to hide account balance). To be compatible within the protocol, these two cryptographic primitives should satisfy the following properties simultaneously:

• Public keys generated by the key generation algorithm of ring signature should be homomorphic.

• Commitments should be homomorphic with respect to (w.r.t.) the same operation as public keys.

• Commitments to zero are well-formed public keys, each corresponding secret key of which can be derived from the randomness of commitments.

To further capture the essential properties and securities required by the ring confidential transaction protocol for Monero, we initiate the formalization of RingCT protocol and its security models, the details of which are shown in the following subsections.

4.1 Technical Description

In general, a RingCT protocol consists of a tuple of poly-time algorithms (Setup, KeyGen, Mint, Spend, Verify), the syntax of which are described as follows:

• $pp\leftarrow \textsf {Setup}(1^\lambda )$: the Setup algorithm takes a security parameter $\lambda \in {\mathbb {N}}$, and outputs the public system parameters pp. All algorithms below have implicitly pp as part of their inputs.

• $(sk, pk)\leftarrow \textsf {KeyGen}(pp)$: the key generation algorithm takes as input pp and outputs a public and secret key pair (pk, sk). In the context of Monero, pk is always set as a one-time address, which together with a coin constitutes an account.

• $(cn, ck)\leftarrow \textsf {Mint}(pk, a)$: the Mint algorithm takes as input an amount a and a valid address pk s.t. $(pk, sk)\leftarrow \textsf {KeyGen}(pp)$, and outputs a coin cn for pk as well as the associated coin key ck³. The coin cn together with address pk forms an account $act\doteq (pk, cn)$, the corresponding secret key of which is $ask\doteq (sk, ck)$ that is required for authorizing its spending.

• $(tx, \pi , {S})\leftarrow \textsf {Spend}(\mathtt {m}, K_s, A_s, {A}, {R})$: on input a group $A_s$ of accounts together with the corresponding account secret keys $K_s$, an arbitrary set A of groups of input accounts containing $A_s$, a set R of out addresses and some transaction string $\mathtt {m}\in \{0, 1\}^*$, the algorithm outputs a transaction tx (containing $\mathtt {m},~{A}$ and ${A}_{R}$ which denotes the set of output accounts w.r.t. R), a proof $\pi$ and a set S of serial numbers.

• $1/0\leftarrow \textsf {Verify}(tx, \pi , S)$: on input the transaction tx containing $\mathtt {m}, A$ and $A_R$, proof $\pi$ and serial numbers S, the algorithm verifies whether a set of accounts with serial numbers S is spent properly for the transaction tx towards addresses R, and outputs 1 or 0, meaning a valid or invalid spending respectively.

4.2 Security Definitions

A RingCT protocol should at least satisfy the properties formalized below.

Definition 3

(Perfect Correctness). This property requires that a user can spend any group of her accounts w.r.t. an arbitrary set of groups of input accounts, each group containing the same number of accounts as the group she intends to spend. Specifically, a RingCT protocol $\varPi =(\textsf {Setup}, \textsf {KeyGen}, \textsf {Mint}, \textsf {Spend},$ $\textsf {Verify})$ is called perfectly correct if for all PPT adversaries $\mathcal {A}$, it holds that

$$\begin{aligned} \Pr \,\left[ \textsf {Verify}(tx, \pi , S)=1: \begin{array}{l} pp\leftarrow \textsf {Setup}(1^\lambda );~(\mathtt {m}, A, R)\leftarrow \mathcal {A}(pp, A_s, K_s) \\ \text {where}~ (A_s, K_s)=\big \{\big ((pk,cn), (sk, ck)\big )\big \}~ s.t. ~\\ (pk, sk)\leftarrow \textsf {KeyGen}(pp),(cn, ck)\leftarrow \textsf {Mint}(pk, a); \\ (tx, \pi , S)\leftarrow \textsf {Spend}(\mathtt {m}, K_s, A_s, A, R).\\ \end{array} \right] =1. \end{aligned}$$

Definition 4

(Balance). This property requires that any malicious user cannot (1) spend any account without her control and (2) spend her own/controllable accounts with a larger output amount. Specifically, a RingCT protocol $\varPi =(\textsf {Setup}, \textsf {KeyGen},$ $\textsf {Mint}, \textsf {Spend}, \textsf {Verify})$ is called balanced w.r.t. insider corruption if for all PPT adversaries $\mathcal {A}$, it holds that

$$\begin{aligned} \Pr \,\left[ \mathcal {A} ~ \text {Wins}: \begin{array}{l} pp\leftarrow \textsf {Setup}(1^{\lambda }); ~(\{act'_i\}_{i=1}^{\mu }, \{\mathcal {S}_i\}_{i=1}^{\nu })\\ \leftarrow \mathcal {A}^{\texttt {AddGen}, \texttt {ActGen}, \texttt {Spend},\texttt {Corrupt}}(pp)\\ \end{array} \right] \le negl(\lambda ), \end{aligned}$$

where all oracles AddGen, ActGen, Spend and Corrupt are defined as below:

• AddGen(i): on input a query number i, picks randomness $\tau _i$, runs algorithm $(sk_i, pk_i)\leftarrow \textsf {KeyGen}(pp; \tau _i)$ and returns address $pk_i$.

• ActGen($i, a_i$): on input address index i and an amount $a_i$, runs algorithm $(cn_i, ck_i)\leftarrow \textsf {Mint}(pk_i, a_i)$, then adds i and account $act_i=(pk_i, cn_i)$ to initially empty lists $\mathcal {I}$ and $\mathcal {G}$ respectively, and outputs $(act_i, ck_i)$ for address $pk_i$, where $pk_i$ is assumed to have been generated by AddGen. The associated secret key with account $act_i$ is $ask_i\doteq (sk_i, ck_i)$. The oracle also uses $ask_i$ to determine the serial number $s_i$ of $act_i$ and adds it to initially empty list $\mathcal {S}$.

• Spend($\mathtt {m}, A_s, A, R$): takes in transaction string $\mathtt {m}$, input accounts A containing $A_s$ and output addresses R, runs $(tx, \pi , S)\leftarrow \textsf {Spend}(\mathtt {m}, K_s, A_s, A, R)$ and returns $(tx, \pi , S)$ after adding it to list $\mathcal {T}$, where $A_s \subset \mathcal {G}$ and we assume that at least one account/address in $A_s$ has not been corrupted so far.

• Corrupt(i): on input query number $i\in \mathcal {I}$, uses account key $ask_i$ to determine the serial number $s_i$ of account $act_i$ with address $pk_i$, then adds $s_i$ and $(s_i, a_i)$ to lists $\mathcal {C}$ and $\mathcal {B}$ respectively, where $a_i$ is the balance of the account with address $pk_i$, and finally returns $\tau _i$.

At last, $\mathcal {A}$ outputs all her spends with some new accounts $(act'_1, act'_2, \cdots , act'_\mu ,$ $\mathcal {S}_1, \mathcal {S}_2,\cdots , \mathcal {S}_\nu )$ such that $\mathcal {S}_i=(tx_i, \pi _i, S_i)$, where all spends are payed to, w.l.o.g., the challenger with account address $pk_c$⁴, i.e., $tx_i=(\mathtt {m}_i, A_i, A_{\{pk_c\}})$, and $A_i\subset \mathcal {G}\cup \{act'_i\}_{i=1}^{\mu }$ for all $i\in [\nu ]$. We call $\mathcal {A}$ wins in the experiment if her outputs satisfy the following conditions:

• 1. $\textsf {Verify}(tx_i, \pi _i, S_i)=1$ for all $i\in [\nu ]$.

• 2. $\mathcal {S}_i \notin \mathcal {T} \wedge S_i\subset \mathcal {S}$ for all $i\in [\nu ]$, and $S_j\cap S_k=\emptyset$ for any different $j, k\in [\nu ]$.

• 3. Let $S_i=\{s_{i,j}\}$ and $E=\bigcup \limits _{i=1}^{\nu }\{a_{i,j}: (s_{i,j}, a_{i,j})\in \mathcal {B} \wedge s_{i,j}\in S_i \cap \mathcal {C}\}$, it holds that $\sum _{a_{i,j}\in E}a_{i,j} < \sum _{i=1}^{\nu }a_{out, i}$, where $a_{out, i}$ denotes the balance of output account in $\mathcal {S}_i$.

Definition 5

(Anonymity). This property requires that two proofs of spending with the same transaction string $\mathtt {m}$, input accounts A, output addresses R and distinct spent accounts $A_{s_0}, A_{s_1}\in A$ are (computationally) indistinguishable, meaning that the spender’s accounts are successfully hidden among all the honestly generated accounts. Specifically, a RingCT protocol $\varPi =(\textsf {Setup}, \textsf {KeyGen}, \textsf {Mint},$ $\textsf {Spend}, \textsf {Verify})$ is called anonymous if for all PPT adversaries $\mathcal {A}=(\mathcal {A}_1, \mathcal {A}_2)$, it holds that

$$\begin{aligned} \left| \Pr \,\left[ b'=b: \begin{array}{l} pp\leftarrow \textsf {Setup}(1^{\lambda }); ~(\mathtt {m}, A_{s_0}, A_{s_1}, A, R)\leftarrow \\ \mathcal {A}_1^{\texttt {AddGen}, \texttt {ActGen}, \texttt {Spend},\texttt {Corrupt}}(pp); ~b\leftarrow \{0, 1\},\\ (tx^*, \pi ^*, S^*)\leftarrow \textsf {Spend}(\mathtt {m}, K_{s_b}, A_{s_b}, A, R);\\ b'\leftarrow \mathcal {A}_2^{\texttt {Spend},\texttt {Corrupt}}(pp, (tx^*, \pi ^*, S^*)) \end{array} \right] -\frac{1}{2}\right| \le negl(\lambda ), \end{aligned}$$

where all oracles are defined as before, $A_{s_i}\in A$ and $A_{s_i}\subset \mathcal {G}$ for $i\in \{0, 1\}$. In addition, the following restrictions should be satisfied:

• For all $i\in \{0, 1\}$, any account in $A_{s_i}$ has not been corrupted.

• Any query in the form of $(\cdot , A_{s}, \cdot , \cdot )$ s.t. $A_s\cap A_{s_i}\ne \emptyset$ has not been issued to Spend oracle.

Definition 6

(Non-Slanderability). This property requires that a malicious user cannot slander any honest user after observing an honestly generated spending. That is, it is infeasible for any malicious user to produce a valid spending that share at least one serial number with a previously generated honest spending. Specifically, a RingCT protocol $\varPi =(\textsf {Setup}, \textsf {KeyGen}, \textsf {Mint}, \textsf {Spend}, \textsf {Verify})$ is called non-slanderable if for all PPT adversaries $\mathcal {A}$, it holds that

$$\begin{aligned} \Pr \,\left[ \mathcal {A} ~ \text {Wins}: \begin{array}{l} pp\leftarrow \textsf {Setup}(1^{\lambda }); ~\big ((\hat{tx}, \hat{\pi }, \hat{S}), (tx^*, \pi ^*, S^*)\big )\\ \leftarrow \mathcal {A}^{\texttt {AddGen}, \texttt {ActGen}, \texttt {Spend},\texttt {Corrupt}}(pp)\\ \end{array} \right] \le negl(\lambda ), \end{aligned}$$

where all oracles are defined as before, and $(\hat{tx}, \hat{\pi }, \hat{S})$ is one output of the oracle Spend for some $(\mathtt {m}, A_s, A, R)$. We call $\mathcal {A}$ succeeds if the output satisfies the following conditions: (1) $\textsf {Verify}(tx^*, \pi ^*, S^*)=1$; (2) $(tx^*, \pi ^*, S^*)\notin \mathcal {T}$; (3) $\hat{S}\cap \mathcal {C}=\emptyset$ but $\hat{S}\cap S^*\ne \emptyset$.

We note that our non-slanderability definition already covers linkability property of a linkable ring signature. Thus we do not need to explicitly define linkability.

5 Our RingCT 2.0 Protocol

In this section, we present a new RingCT protocol under our formalized syntax. Specifically, our protocol is constructed based on a generic accumulator with one-way domain ACC, a signature of knowledge SoK and the well-known Pedersen commitment. Proceeding to present the details, we first give an intuition of our protocol. Without loss of generality, we denote all, say, n groups of input accounts by $A=\{(pk_{in, i}^{(k)}, cn_{in, i}^{(k)})\}_{i\in [n], k\in [m]}$ (including the group of m accounts the user intends to spend) and set the spender’s group as the s-th group, i.e., $A_s=\{(pk_{in, s}^{(k)}, cn_{in, s}^{(k)})\}_{k\in [m]}$. Conceptually, our idea is to arrange the account groups key into a matrix in which each group corresponds to a column. To shorten the size of transaction, the public keys in the same row is accumulated into one value. Then, the spender proves that he is using one account of each row in the spending. To ensure that the spender is using the account of the same column, the accumulated elements in protocol are formed as $pk_{in, i}^{(k)}\cdot u^s$ instead of $pk_{in, i}^{(k)}$, as shown in the matrix below.

To further guarantee the total balance in each transaction is conserved, the spender computes extra public keys $\widetilde{pk}_{i}$ based on the input accounts and the output accounts. Looking ahead, knowledge of the secret key that corresponds to $\widetilde{pk}_{i}$ implies that the balance in accounts $A_i$ is equal to the balance of the output accounts.

$$\begin{aligned} \begin{pmatrix} pk_{in,1}^{(1)}\cdot u^1 &{}\cdots &{} pk_{in,s}^{(1)}\cdot u^{s} &{} \cdots &{} pk_{in,n}^{(1)}\cdot u^{n}\\ \vdots &{} \ddots &{}\vdots &{} \ddots &{} \vdots \\ pk_{in,1}^{(k)}\cdot u^1 &{}\cdots &{} pk_{in,s}^{(k)}\cdot u^{s} &{} \cdots &{} pk_{in,n}^{(k)}\cdot u^{n} \\ \vdots &{} \ddots &{}\vdots &{} \ddots &{} \vdots \\ pk_{in,1}^{(m)}\cdot u^1 &{}\cdots &{} pk_{in,s}^{(m)}\cdot u^{s} &{} \cdots &{} pk_{in,n}^{(m)}\cdot u^{n} \\ \boxed {\widetilde{pk}_{1}\cdot u^{1}} &{}\cdots &{} \boxed {\widetilde{pk}_{s}\cdot u^{s}} &{} \cdots &{} \boxed {\widetilde{pk}_{n}\cdot u^{n}}\\ \end{pmatrix} \begin{array}{c} \Rightarrow \\ \vdots \\ \Rightarrow \\ \vdots \\ \Rightarrow \\ \Rightarrow \end{array} \begin{pmatrix} v_1\\ \vdots \\ v_k\\ \vdots \\ v_m\\ v_{m+1} \end{pmatrix} \end{aligned}$$

5.1 Protocol Description

Let $\textsf {ACC}=(\textsf {ACC.Gen}, \textsf {ACC.Eval}, \textsf {ACC.Wit})$ be an accumulator with one-way domain and $\textsf {SoK}=(\textsf {Gen}, \textsf {Sign}, \textsf {Verf})$ be a signature of knowledge as defined in Sect. 3.2. Based on these primitives and the Pedersen commitment, our RingCT protocol $\textsf {RCT}=(\textsf {Setup}, \textsf {KeyGen}, \textsf {Mint}, \textsf {Spend}, \textsf {Verify})$ is designed as follows:

$\textsf {Setup}(1^\lambda )$: on input a security parameter $\lambda$, the algorithm prepares a collision-resistant accumulator f with one-way domain ${\mathbb {G}}_{q}$, together with its description $\textsf {desc}$, by calling ACC.Gen($1^\lambda$), and generates par by running Gen$(1^\lambda )$. Then it randomly picks generators $h_0,$ $h_1, u\in \mathbb {G}_q$, chooses a random hash function H, and outputs the system parameters pp = $\big (1^\lambda ,\textsf {desc}, \textsf {par}, h_0, h_1, u, H\big )$.

KeyGen(pp): on input pp, the algorithm generates a key pair $(sk, pk):=(x, y=h_0^{x})\in {\mathbb {Z}}_q\times {\mathbb {G}}_q$ by executing the sampling algorithm of the one-way relation associated with the domain of f. In the context of Monero, the public key pk is always set as a one-time address, which combining with a coin constitutes a user’s account.

Mint(pk, a): on input address pk and an amount $a\in {\mathbb {Z}}_q$, the algorithm mints a coin for pk: chooses $r\in {\mathbb {Z}}_{q}$ uniformly at random, computes commitment $c=h_{0}^{r}h_{1}^{a}$, where r is called a secret hiding factor and a is the balance of account pk, and then returns $(cn, ck)=(c, (r, a))$. The coin cn together with pk forms the account $act\doteq (pk, cn)$, to which the corresponding secret key is $ask\doteq (sk, ck)$.

$\textsf {Spend}(\mathtt {m}, K_s, A_s, A, R)$: on input a set of secret keys $K_s$ associated with the group of input accounts $A_s$, some transaction string $\mathtt {m}\in \{0, 1\}^*$, an arbitrary set A of groups of input accounts containing $A_s$, and a set R of output addresses, the algorithm produces an SoK $\pi$ and the corresponding serial numbers S w.r.t. $A_s$ as follows. Without loss of generality, we denote all, say, n groups (including the group the user intends to spend) of input accounts by $A=\{(pk_{in, i}^{(k)}, cn_{in, i}^{(k)})\}_{i\in [n], k\in [m]}$ and set the spender’s group as the s-th group, i.e., $A_s=\{(pk_{in, s}^{(k)}, cn_{in, s}^{(k)})\}_{k\in [m]}$, the corresponding secret keys of which are $K_s=\{ask_s^{(k)}=(sk_{in, s}^{(k)}, (r_{in, s}^{(k)}, a_{in, s}^{(k)}))\}_{k\in [m]}$, and denote the intended output addresses by $R=\{pk_{out, j}\}_{j\in [t]}$.

• 1. Set $a_{out, j}\in {\mathbb {Z}}_q$ for all output address $pk_{out, j}\in R$, such that the input and output balances satisfy $\sum \limits _{k=1}^{m}a_{in, s}^{(k)}=\sum \limits _{j=1}^t a_{out, j}$, then pick uniformly at random $r_{out, j}\in {\mathbb {Z}}_q$ and mint coin $cn_{out, j}=c_{out, j}=h_{0}^{r_{out, j}}h_{1}^{a_{out, j}}$. After that, add output account $act_{out, j}=(pk_{out, j}, cn_{out, j})$ to $A_R$, and privately send the coin key $ck_{out, j}=(r_{our, j}, a_{out, j})$ to the user holding address $pk_{out, j}$.

• 2. Compute $\widetilde{sk}_s=\sum \limits _{k=1}^{m}sk_{in, s}^{(k)}+\sum \limits _{k=1}^{m}r_{in, s}^{(k)}-\sum \limits _{j=1}^t r_{out, j}$ and $\widetilde{pk}_i=\prod \limits _{k=1}^{m}pk_{in, i}^{(k)}\cdot \prod \limits _{k=1}^{m}cn_{in, i}^{(k)}/\prod \limits _{j=1}^t cn_{out, j}$ for each $i\in [n]$. Clearly, it holds that $\widetilde{pk}_s=h_{0}^{\widetilde{sk}_s}$, which follows from the fact that $\sum \limits _{k=1}^{m}a_{in, s}^{(k)}=\sum \limits _{j=1}^t a_{out, j}$. For convenience, we denote $\widetilde{pk}_i$ and $\widetilde{sk}_s$ by $y_i^{(m+1)}$ and $x_s^{(m+1)}$ respectively hereafter, i.e., $\widetilde{pk}_i\doteq y_i^{(m+1)}$ and $\widetilde{sk}_s\doteq x_s^{(m+1)}$.

• 3. Generate a proof $\pi$ that the group of coins $A_s$ was spent properly for a transaction tx, which consists of $\mathtt {m}$, input accounts A and output accounts $A_R=\{act_{out,j}\}$, as follows. For clarity, we denote $sk_{in,s}^{(k)}=x_s^{(k)}$ for all ${k\in [m]}$ and $pk_{in, i}^{(k)}=y_i^{(k)}$ for all $i\in [n]$ and $k\in [m]$. Recall that $\widetilde{pk}_i\doteq y_i^{(m+1)}$ for all $i\in [n]$ and $\widetilde{sk}_s\doteq x_s^{(m+1)}$.

  • (a) For each $k\in [m+1]$, compute the accumulated value $v_k=\textsf {ACC.Eval}(\textsf {desc},$ $\{y_i^{(k)}\cdot u^i\})$ and the witness $w_s^{(k)}=\textsf {ACC.Wit}(\textsf {desc}, \{y_i^{(k)}\cdot u^i|i\ne s\})$ for the fact that $y_s^{(k)}\cdot u^s$ has been accumulated within $v_k$ (i.e., computing the witness $w_s^{(k)}$ s.t. $f(w_s^{(k)}, ~y_s^{(k)}\cdot u^s)=v_k$). Then compute $s_k=H(y_s^{(k)})^{x_s^{(k)}}$ for all $k\in [m]$. For simplicity, we denote $z_s^{(k)}=y_s^{(k)}\cdot u^s$ hereafter.

  • (b) Use Sign to produce a signature of knowledge $\pi$ on tx as:

    $$\begin{aligned} { { \text {SoK}\left\{ (\{w_k, z_k, x_k\}_{k=1}^{m+1}, \gamma ):\!\! \begin{array}{c} f(w_{m+1}, z_{m+1})=v_{m+1} \wedge z_{m+1} =h_0^{x_{m+1}}u^\gamma \wedge \\ f(w_1, z_1)=v_1 \wedge z_1 =h_0^{x_1}u^\gamma \wedge s_1 = H(y_s^{(1)})^{x_1} \wedge \\ \vdots \\ f(w_m, z_m)=v_m \wedge z_m =h_0^{x_m}u^\gamma \wedge s_m = H(y_s^{(m)})^{x_m} \\ \end{array} \right\} (tx) }} \end{aligned}$$

  • (c) Eventually, return $(tx, \pi , S),$ where $S=\{s_1, s_2, \ldots , s_{m}\}$. We note that the serial number $s_k$ is uniquely determined by the address key $sk_{in,s}^{(k)}$ for every $k\in [m]$, and thus they can be used to prevent double-spending.

$\textsf {Verify}(tx, \pi , S)$: receiving a transaction tx containing $\mathtt {m}, A ~\text {and}~ A_R$, the associated SoK $\pi$ for tx and the serial numbers $S=\{s_i\}$, the recipient verifies that a set of accounts with serial numbers $\{s_i\}$ from input accounts A was spent for a transaction tx (towards output addresses R) with string $\mathtt {m}$, as follows:

• 1. Use $A=\{(pk_{in, i}^{(k)}, cn_{in, i}^{(k)})\}_{i\in [n], k\in [m]}$ and $A_R=\{(pk_{out, j}, cn_{out, j})\}_{j\in [t]}$ (contained in tx) to compute $\widetilde{pk}_i=\prod \limits _{k=1}^{m}pk_{in, i}^{(k)}\cdot \prod \limits _{k=1}^{m}cn_{in, i}^{(k)}/\prod \limits _{j=1}^t cn_{out, j}$ for all $i\in [n]$, and then compute the accumulated values $v_k=\textsf {ACC.Eval}(\textsf {desc},\{pk_{in, i}^{(k)}\cdot u^{i}\})$ for all $k\in [m]$ and $v_{m+1}=\textsf {ACC.Eval}(\textsf {desc},\{\widetilde{pk}_i\cdot u^{i}\})$.

• 2. Take as input accumulated values $(v_1, \cdots , v_{m+1})$, serial numbers $S=(s_1, \cdots ,$ $s_m)$, transaction tx and $\pi$ to verify whether it is a valid spending by checking $\textsf {Verf}(tx, (v_1, \cdots , v_{m+1},$ $s_1, \cdots , s_m), \pi )\mathop {=}\limits ^{?}1$. If true, accept this transaction, otherwise reject it.

The correctness of this protocol follows directly from that of the underlying signature of knowledge protocol SoK. We do not give more details here.

5.2 Security Analysis

In this part, the securities of our RingCT protocol are collectively analyzed under the formalized security models, which are indicated as the following theorems.

Theorem 1

Assuming the discrete logarithm (DL) problem in ${\mathbb {G}}_q$ is hard, ACC is an accumulator with one-way domain and SoK is a SimExt-secure signature of knowledge, then the proposed RingCT protocol RCT is balanced w.r.t. insider corruption.

Theorem 2

Let $\textsf {HCom}_P$ be the Pedersen commitment, ACC be an accumulator with one-way domain and SoK a SimExt-secure signature of knowledge, then the proposed RingCT protocol RCT is anonymous under the DDH assumption.

Theorem 3

Assuming the DL problem in ${\mathbb {G}}_q$ is hard, ACC is an accumulator with one-way domain and SoK is a SimExt-secure signature of knowledge, then the proposed RingCT protocol RCT is non-slanderable w.r.t. insider corruption.

Proofs for Theorems 1, 2 and 3 can be found in the full version of this paper [27].

5.3 Instantiations

Our RingCT protocol is constructed based on a well-known homomorphic commitment, i.e., the Pedersen commitment, a generic accumulator with one-way domain ACC and a signature of knowledge SoK for a specific language related to ACC. Next we give an instantiation of ACC and SoK, and briefly recall the Pedersen commitment for completeness.

Accumulator with One-Way Domain. A specific (universal) accumulator for DDH groups presented in [5] is well suited to our protocol, the algorithms of which are described as follows:

• ACC.Gen($1^\lambda$): generate cyclic groups $\mathbb {G}_1=\langle g_0\rangle$ and $\mathbb {G}_2$ of prime order p, equipped with a bilinear pairing $e: \mathbb {G}_1\times \mathbb {G}_1\rightarrow \mathbb {G}_2$, and an accumulating function $\textsf {g}\circ \textsf {f}: \mathbb {Z}_p^*\times \mathbb {Z}_p^*\rightarrow \mathbb {G}_1$, where $\textsf {f}$ is defined as $\textsf {f}: \mathbb {Z}_p^*\times \mathbb {Z}_p^*\rightarrow \mathbb {Z}_p^*$ such that $\textsf {f}: (u, x)\mapsto u(x+\alpha )$ for some auxiliary information $\alpha$ randomly chosen from $\mathbb {Z}_p^*$ (for simplicity, u is always set as the identity element of $\mathbb {Z}_p^*$) and $\textsf {g}$ is defined as $\textsf {g}: \mathbb {Z}_p^*\rightarrow \mathbb {G}_1$ such that $\textsf {g}: x \mapsto g_0^x$. The domain of accumulatable elements is $\mathbb {G}_q=\langle h\rangle$, which is a cyclic group of prime order q such that $\mathbb {G}_q \subset \mathbb {Z}_p^{*}$. At last, output the description $\textsf {desc}=(\mathbb {G}_1, \mathbb {G}_2, \mathbb {G}_q, e, g_0, g_0^{\alpha }, g_0^{\alpha ^2}, \cdots , g_0^{\alpha ^n}, \textsf {g}\circ \textsf {f})$, where n is the maximum number of elements to be accumulated.

• ACC.Eval(desc, X): compute the accumulated value $\textsf {g}\circ \textsf {f}(1, X)$ for X by evaluating $\prod _{i=0}^{n}(g_0^{\alpha ^i})^{u_i}$ with public information $\{g_0^{\alpha ^i}\}_{i\in [n]}$, where $u_i$ is the coefficient of the polynomial $\prod _{x\in X}(x+\alpha )=\prod _{i=0}^{n}(u_i\alpha ^i)$.

• ACC.Wit(desc, $x_s, X$): the relation $\varOmega$ w.r.t. this accumulator is defined as $\varOmega (w, x,$ $v)=1~iff ~e(w, g_0^x g_0^{\alpha })=e(v, g_0)$, a witness $w_s$ for the element $x_s\in X:=\{x_1, x_2, \cdots , x_n\}$ s.t. $s\in [n]$ is computed as $w_s=\textsf {g}\circ \textsf {f}(1, X\backslash \{x_s\})=\prod _{i=0}^{n-1}(g_0^{\alpha ^i})^{u_i}$ with public information $\{g_0^{\alpha ^i}\}_{i\in [n-1]}$, where $u_i$ is the coefficient of the polynomial $\prod _{i=1, i\ne s}^{n}(x_i +\alpha )=\prod _{i=0}^{n-1}(u_i\alpha ^i)$.

Regarding this accumulator, the domain of accumulatable elements is $\mathbb {G}_q=\langle h\rangle$, the one-way relation for which is defined as $\texttt {R}_q \doteq \{(y,x)\in \mathbb {Z}_q\times \mathbb {G}_q: x=h^y\}$. Moreover, the relation $\texttt {R}_q$ is efficiently verifiable, efficiently samplable and one-way, as defined before.

Theorem 4

[5]. Under the n-SDH assumption in group ${\mathbb {G}}_1$, the above accumulator ACC is a secure universal accumulator. Moreover, under the DL assumption in group ${\mathbb {G}}_q$, it is an accumulator with one-way domain.

As to the associated SoK with this concrete ACC, it can be easily obtained by applying the Fiat-Shamir paradigm [15] to the associated interactive zero-knowledge protocol given in [5].

Pedersen Commitment. As shown in [19], the Pedersen commitment is naturally a homomorphic commitment scheme. Its key generation algorithm CKGen and commit algorithm Com are described respectively as:

• CKGen$(1^\lambda )$: on input a security parameter $1^\lambda$, outputs the commitment key $ctk=({\mathbb {G}}_q, q, g, h)$, where ${\mathbb {G}}_q$ is a cyclic group of prime order q and g, h are random generators of ${\mathbb {G}}_q$.

• Com(ctk, m): to commit to a message $m\in {\mathbb {Z}}_q$, the algorithm randomly picks $r\in {\mathbb {Z}}_q$ and computes $c=g^m h^r$.

As well known, this commitment scheme is perfectly hiding and computationally strongly binding under the discrete logarithm assumption in ${\mathbb {G}}_q$.

6 Efficiency Analysis

In this section, we give a brief comparison of the efficiency of our RingCT protocol with that of [24]. In particular, the anonymity of our protocol relies heavily on the underlying accumulator with one-way domain, which compacts a group of input accounts to a shorter value, while the RingCT protocol given in [24] is directly constructed on the basis of a linkable ring signature. As shown in [24], the size of signature in their protocol increases linearly with the number n of group accounts. More concretely, it is almost $\mathcal {O}(n(m+1))$ where m is the number of accounts contained in each group. In contrast, the communication complexity of our protocol is $\mathcal {O}(m)$, which is independent of the number of groups. Clearly, the proposed protocol presents a significant space/bandwidth saving.

7 Conclusion

In this work, we first formalize the syntax of RingCT protocol and present some rigorous security definitions by capturing the necessary security requirements for its application in Monero, which is the core part for Monero. Next, we propose a new RingCT protocol (RingCT 2.0) based on a specific homomorphic commitment, accumulator with one-way domain and the related signature of knowledge. The size of the RingCT 2.0 protocol is independent to the number of groups of input accounts included in the generalized ring while the original RingCT protocol suffers from the linear growing size with the number of groups. We believe the significant space complexity improvement in RingCT 2.0 will improve the overall efficiency of Monero.