RING CONFIDENTIAL TRANSACTIONS

SHEN NOETHER- MONERO RESEARCH LABS

Abstract. This article introduces a method of hiding transaction
amounts in the strongly decentralized anonymous cryptocurrency
Monero. Similar to Bitcoin, Monero is a cryptocurrency which is
distributed through a proof of work mining process. The original Monero protocol was based on CryptoNote, which uses ring
signatures and one-time keys to hide the destination and origin
of transactions. Recently the technique of using a commitment
scheme to hide the amount of a transaction has been discussed
and implemented by Bitcoin Core Developer Gregory Maxwell. In
this article, a new type of ring signature, A Multi-layered Linkable
Spontaneous Anonymous Group signature is described which allows for hidden amounts, origins and destinations of transactions
with reasonable efficiency and verifiable, trustless coin generation.
The author would like to note that early drafts of this were publicized in the Monero Community and on the bitcoin research irc
channel. Blockchain hashed drafts are available in [Noe15].

Contents
1. Introduction

1.1. Spontaneous (Ad Hoc) Ring Signatures in CryptoCurrencies

1.2. Ring CT for Monero

1.3. Strongly Decentralized Anonymous Payment Schemes

1.4. Acknowledgements

6
1

RING CONFIDENTIAL TRANSACTIONS

2. Multilayered Linkable Spontaneous Ad-Hoc Group

Signatures

2.1. LWW signatures vs FS signatures

2.2. MLSAG Description

10

2.3. MLSAG Security Model

12

2.4. MLSAG Unforgeability

13

2.5. MLSAG Linkability

16

2.6. MLSAG Anonymity

17

3. Background on Confidential Transactions

20

3.1. Confidential Transactions in Bitcoin

20

3.2. Modification for Ring Signatures

20

4. Ring CT For Monero Protocol

23

4.1. Protocol Description

23

4.2. Conversion from Visible Denominations to Commitments 25

4.3. Transaction Fees

25

5. Aggregate Schnorr Range Proofs

26

5.1. Representing Amounts

29

6. Ring CT Demo Code

30

7. Conclusion

33

References

33

1. Introduction
1.1. Spontaneous (Ad Hoc) Ring Signatures in CryptoCurrencies. Recall that in Bitcoin each transaction is signed by the owner of

RING CONFIDENTIAL TRANSACTIONS

the coins being sent and these signatures verify that the owner is allowed to send the coins. This is entirely analogous to the signing of a
check from your bank.
CryptoNote [vS13] and Ring Coin [Bac13] advanced this idea by
using ring signatures which were originally described in [RST01] as
a digital signature that specifies a group of possible signers such that
the verifier cant tell which member actually produced the signature.
The idea therefore is to have the origin pubkey of a transaction hidden
in a group of pubkeys all of which contain the same amount of coins,
so that no one can tell which user actually sent the coins.
The original CryptoNote protocol as described in [vS13] implements
a slight modification of this to prevent double spends. Namely in [vS13]
a traceable ring signature, which is a slight modification of those
described in [FS07] is employed. This type of ring signature has the
benefit of not allowing the owner of a coin to sign two different ring signatures with the same pubkey without being noticed on the blockchain.
The obvious reason for this is to prevent double-spending which, in
Bitcoin, refers to spending a coin twice. Ring coin [Bac13, Bac15] uses
a more efficient linkable ring signature which is a slight modification of
the Linkable Spontaneous Anonymous Group signatures described in
[LWW04].
One benefit of using the above types of ring signatures over other
anonymizing techniques, such as CoinJoin [Max13] or using coin mixing
services, is that they allow for spontaneous mixing. With CoinJoin
or coin mixers, it is similarly possible to hide the originator of a given

RING CONFIDENTIAL TRANSACTIONS

transaction, however these techniques in practice need some sort of

centralized group manager, such as a centralized CoinJoin server, where
transactions are combined by a trusted party. In the case that the
trusted party is compromised, the anonymity of the transaction is also
compromised.
Some coins such as Dashcoin [DH14], attempt to negate this by using
a larger number of trusted mixers (in this case masternodes) but this
number is still much smaller than the users of the coin. In contrast,
with a spontaneous ring signature, transactions can be created by the
owner of a given pubkey (this is the spontaneous, or ad-hoc property)
without relying on any trusted server, and thus providing for safer
anonymity.
One possible attack against the original CryptoNote or ring-coin protocol [vS13, Bac13] is blockchain analysis based on the amounts sent in
a given transaction. For example, if an adversary knows that .9 coins
have been sent at a certain time, then they may be able to narrow down
the possibilities of the sender by looking for transactions containing .9
coins. This is somewhat negated by the use of the one-time keys used
in [vS13] since the sender can include a number of change addresses in
a transaction, thus obfuscating the amount which has been sent with
a type of knapsack mixing. However this technique has the downside that it can create a large amount of dust transactions on the
blockchain, i.e. transactions of small amounts that take up proportionately more space than their importance. Additionally, the receiver of
the coins may have to sweep all this dust when they want to send it,

RING CONFIDENTIAL TRANSACTIONS

possibly allowing for a smart adversary to keep track of which keys go

together in some manner. Furthermore, it is easy to establish an upper
and lower bound on the amounts sent.
Another downside to the original CryptoNote set-up is that it requires a given pair of (P, A) of pubkey P and amount A to be used
in a ring signature with other pubkeys having the same amount. For
less common amounts, this means there may be a smaller number of
potential pairs (P 0 , A0 ) available on the blockchain with A0 = A to ring
signature with. Thus, in the original CryptoNote protocol, the potential anonymity set is perhaps smaller than may be desired. Analysis of
the above weaknesses is covered in [AMT15].

1.2. Ring CT for Monero. An obvious way to negate the downsides

of the CryptNote protocol, as described in the previous section, would
be to implement hidden amounts for any transaction. In this paper, I
describe a modification to the Monero protocol, a proof-of-work cryptocurrency extending the original CryptoNote protocol, which allows
the amounts sent in a transaction to be hidden. This modification is
based on the Confidential Transactions [Max15] which are used on the
lightning side-chain in Bitcoin, except it allows for their use in ring
signatures. Therefore, the modification is given the obvious name of
Ring Confidential Transactions for Monero.
In order to preserve the property that coins cannot be double spent,
a generalization of the LSAGs of [LWW04] is described, a Multilayered Linkable Spontaneous Anonymous Group Signature (MLSAG)

RING CONFIDENTIAL TRANSACTIONS

which allows for combining Confidential Transactions with a ring signature in such a way that using multiple inputs and outputs is possible,
anonymity is preserved, and double-spending is prevented.
1.3. Strongly Decentralized Anonymous Payment Schemes. The
Ring CT protocol allows hidden amounts, origins, and destinations for
transactions which is somewhat similar to Zerocash [BSCG+ 14]. One
possible differentiator is that the use of proof of work for coin generation is possible with Ring CT as opposed to in ZeroCash, where it
seems all coins must be pregenerated by a trusted group.
Note that one of the biggest innovations in Bitcoin [Nak08], was the
decentralized distribution model allowing anyone willing to put their
computing power to work to participate in the generation of the currency. Some of the benefits of this type of proof-of-work include trustless incentives for securing the network and stronger decentralization
(for example, to protect against poison-pill type attacks).
One final obvious benefit of the proof-of-work coin generation is it
makes Ring CT immune to a powerful actor somehow acquiring all the
pieces of the master key used in coin generation. Since there is an
obvious large incentive (the ability to generate free money 1) to acquire
all pieces of the trusted generation key, this is fairly important.
1.4. Acknowledgements. I would like to thank Monero team for lots
of help and discussion in the creation of this paper and the Monero
and Bitcoin Community for support and discussion. With respect to
1The author previously had assumed this would allow the unmasking of transactions

as well, but the newer ZeroCash paper claims this is not possible.

RING CONFIDENTIAL TRANSACTIONS

disclosure, the author received several donations totalling between 2

and 3 bitcoins from the Monero community in gratitude for his work
on this research.
2. Multilayered Linkable Spontaneous Ad-Hoc Group
Signatures
In this section, I define the Multilayered Linkable Spontaneous Anonymous Group signatures (MLSAG) used by the the Ring CT protocol.
Note that I define these as a general signature, and not necessarily in
their use case for Ring Confidential Transactions. An MLSAG is essentially similar to the LSAGs described in [LWW04], but rather than
having a ring signature on a set of n keys, instead, an MLSAG is a ring
signature on a set of n key-vectors.
Definition 1. A key-vector is just a collection y = (y1 , ..., yr ) of
public keys with corresponding private keys x = (x1 , ..., xr ).
2.1. LWW signatures vs FS signatures. The ring signatures used
in Monero and the original CryptoNote protocol are derived from the
traceable ring signatures of [FS07]. The CryptoNote [vS13] ring signatures come with a key-image which means that a signer can only
sign one ring on the block-chain with a given public and private key
pair or else their transaction will be marked as invalid. Because of this,
one-time keys are used in CryptoNote, which further helps anonymity.
In [Bac15], Adam Back noticed that the Linkable Spontaneous Anonymous Group (LSAG) signatures of [LWW04] can be modified to give a
more efficient linkable ring signature producing the same effect as the

RING CONFIDENTIAL TRANSACTIONS

[FS07] ring signatures. This modification reduces the storage cost on

the blockchain essentially in half.
First I recall almost verbatim the modification given in [Bac15]:
Keygen: Find a number of public keys Pi , i = 0, 1, ..., n and a secret
index j such that xG = Pj where G is the ed25519 base-point and x is
the signers spend key. Let I = xHp (Pj ) where Hp is a hash function
returning a point

Let m be a given message.

SIGN: Let , si , i 6= j, i {1, ..., n} be random values in Zq (the

ed25519 base field).
Compute
Lj = G
Rj = Hp (Pj )
cj+1 = h (m, Lj , Rj )
where h is a hash function returning a value in Zq . Now, working
successively in j modulo n, define
Lj+1 = sj+1 G + cj+1 Pj+1
Rj+1 = sj+1 Hp (Pj+1 ) + cj+1 I
cj+2 = h (m, Lj+1 , Rj+1 )

Lj1 = sj1 G + cj1 Pj1

2In

practice Hp (P ) = Keccak(P ) G where G is the ed25519 basepoint, although

note that for the commitment scheme I will use toP oint(Keccak(P )), hashing successively until Keccak(P ) returns a multiple of the basepoint.

RING CONFIDENTIAL TRANSACTIONS

Rj1 = sj1 Hp (Pj1 ) + cj1 I

cj = h (m, Lj1 , Rj1 )
so that c1 , ..., cn are defined.
Let sj = cj xj mod l, (l being the ed25519 curve order) hence
= sj + cj xj mod l so that
Lj = G = sj G + cj xj G = sj G + cj Pj
Rj = Hp (Pj ) = sj Hp (Pj ) + cj I
and
cj+1 = h (m, Lj , Rj )
and thus, given a single ci value, the Pj values, the key image I, and all
the sj values, all the other ck , k 6= i can be recovered by an observer.
The signature therefore becomes:
= (I, c1 , s1 , ..., sn )
which represents a space savings over [vS13, 4.4] where the ring signature would instead look like:
= (I, c1 , ..., cn , s1 , ..., sn )
Verification proceeds as follows. An observer computes Li , Ri , and ci
for all i and checks that cn+1 = c1 . Then the verifier checks that
ci+1 = h (m, Li , Ri )

RING CONFIDENTIAL TRANSACTIONS

10

for all i mod n

LINK: Signatures with duplicate key images I are rejected.
Note that proofs of unforgeability, anonymity, and linkability hold
for the above protocol which are only insignificant modifications to the
proofs given in [LWW04]. I will give a more generalized version of these
proofs for the MLSAGs.

2.2. MLSAG Description. For the Ring CT protocol, which will

be described in section 4, I require a generalization of the Back LSAG
signatures described in the previous section which allows for key-vectors
(Definition 1) rather than just keys.
Suppose that each signer of a (generalized) ring containing n mem i=1,...,n
bers has exactly m keys Pij j=1,...,m . The intent of the MLSAG ring
signature is the following:
To prove that one of the n signers knows the secret keys to their
entire key vector.
To enforce that if the signer uses any one of their m signing keys
in another MLSAG signature, then the two rings are linked,
and the second such MLSAG signature (ordered by the Monero
block chain) is discarded.
The algorithm proceeds as follows: Let m be a given message. Let
be a secret index corresponding to the signer of the generalized ring.
For j = 1, ..., m, let Ij = xj H (Pj ), and for j = 1, ..., m, i = 1, ...,
, ...n

RING CONFIDENTIAL TRANSACTIONS

11

(where
means omit the index ) let sji be some random scalars (elements of Zq ). Now, in a manner analogous to subsection 2.1, define
Lj = j G
Rj = j H Pj

for random scalars j and j = 1, ..., m. Now, again analogously to

section 2.1, set:


m
c+1 = H m, L1 , R1 , ..., Lm
, R .
j
Lj+1 = sj+1 G + c+1 P+1

j
j
R+1
= sj+1 H P+1
+ c+1 Ij
and repeat this, incrementing i modulo n until we arrive at
j
Lj1 = sji1 G + ci1 Pi1

j
j
R1
= sji1 H Pi1
+ ci1 Ij


1
m
c = H m, L11 , R1
, ..., Lm
1 , R1 .
Finally, solve for each sj using j = sj + c xj mod `. The signature
1
m
1
m
is then given as (I1 , ..., Im , c1 , s11 , ..., sm
1 , s2 , ..., s2 , ..., sn , ..., sn ), so the

complexity is O (m (n + 1)) . Verification proceeds by regenerating all

the Lji , Rij starting from i = 1 as in section 2.1 (which is the special case
that m = 1) and verifying the hash cn+1 = c1 . If these are being used
in a blockchain setting such as Monero, signatures with key images Ij

RING CONFIDENTIAL TRANSACTIONS

12

which have already appeared are then rejected. One can easily show,
in a manner similar to [LWW04]:
The probability of a signer generating a valid signature without
knowing all m private keys belonging to their key vector for
index is negligible.
The probability of a signer not signing for any key of index
is negligible. (In other words, the key images in the signature
necessarily all come from index .)
If a signer signs two rings using at least one of the same public
keys, then the two rings are linked.
I expand on these points below with security proofs.
2.3. MLSAG Security Model. An MLSAG will satisfy the following
three properties of Unforgeability, Linkability, and Signer Ambiguity
which are very similar to the definitions given in [LWW04].
Definition 2. (Unforgeability) An MLSAG signature scheme is unforgeable if for any probabilistic polynomial time (PPT) algorithm A
with signing oracle SO producing valid signatures, given a list of n
public key vectors chosen by A, then A can only with negligible probability produce a valid signature when A does not know one of the
corresponding private key vectors.
Remark 3. In the following definition, note that I include rejecting
duplicate key images as part of the verification criteria for the MLSAG,
which gives a slightly different Linkability definition than the one in
[LWW04].

RING CONFIDENTIAL TRANSACTIONS

13

Definition 4. (Linkability) Let L be the set of all public keys in a given

setting (e.g. in a given blockchain). An MLSAG signature scheme on
L is key-image linked if the probability of a PPT adversary A creating
two signatures , 0 signed with respect to key-vectors y and y 0 each
containing the same public key yi = y 0i in L and each verifying without
being marked duplicate, is negligible.

Definition 5. (Signer Ambiguity ) An MLSAG signature scheme is

said to be signer ambiguous if given any verifying signature on keyvectors (y 1 , ..., y n ) and any set of t private keys, none of the same index,
nor of the secret index, then the probability of guessing the secret key
is less than

1
nt

1
Q(k)

2.4. MLSAG Unforgeability. This follows similarly to [LWW04, Theorem 1]. Let H1 and H2 random oracles, and SO be a signing oracle
which returns valid MLSAG signatures. Assume there is a probabilistic polynomial time (PPT) adversary A with the ability to forge an
MLSAG from a list of key vectors L with non-negligible probability
P r (A (L) (m, ) : V er (L, m, ) = T rue) >

1
Q1 (k)

where Q1 is a polynomial inputting a security parameter k and where

(m, ) is not one of the signatures returned by SO. Assume that A
makes no more than qH + nqS (with n the number of keys in L) queries
to the signing oracles H1 , H2 and SO respectively. The oracles H1
and H2 are assumed independent and random and are consistent given
duplicate queries. The signing oracle SO is also allowed to query H1

RING CONFIDENTIAL TRANSACTIONS

14

and H2 . Given A, I will show it is possible to create a PPT adversary

M which uses A to find the discrete logarithm of one of the keys in L.
If L is a set of key vectors {y1 , ..., yn } each of size r, (i.e. yi =
(y1i , ..., yri ) with y1 , ..., yr public keys) then a forged signature
= (c1 , s1 , ..., sn , y0 )
produced by A must satisfy
m
ci+1 = H m, L1i , Ri1 , ..., Lm
i , Ri

where the i are taken mod n, and the Lji , Rij are defined as in section
2.2. The new adversary M may call A to forge signatures a polynomial
number of times and will record each Turing script T whether or not
the forgery is successful.
Lemma 6. [LWW04, Lemma 1] Let M invoke A to obtain a transcript T . If T is successful, then M rewinds T to a header H and
re-simulates A to obtain transcript T 0 . If P r (T succeeds) =  , then
P r (T 0 succeeds) = .
Proof. Follows easily from the cited Theorem.

Theorem 7. The probability that an adversary A forges a verifying

MLSAG signature is negligible under the discrete logarithm assumption.
Proof. I follow the notation introduced above. Similarly to [LWW04,
Theorem 1], since the probability of guessing the output of a random
oracle is negligible, therefore, for each successful forgery A completes

RING CONFIDENTIAL TRANSACTIONS

15

with transcript T , there are mT queries to H1 matching the n queries

used to verify the signature. Thus let Xi1 , ..., Xim denote these queries
used in verification for the ith such forgery and let be the index
corresponding to the last such verification query for a given forgery


mT
1
T
Xim = H1 m, L11 , R1
, ..., Lm
1 , R1 .
(Intuitively, corresponds to what would be the secret index of the
forged signature, since it corresponds to the last call to the random
oracle for the given signature).
An attempted forgery produced by A is an (`, )-forgery if i1 = `
and is as above (so this forgery corresponds to queries ` through
`+). By assumption, there exists a pair (`, ) such that the probability
that the corresponding transcript T gives a successful forgery, `, (T ),
satisfies
`,

1
1
1
1

.
mT (qH + mT qS ) Q1 (k)
n (qH + nqS ) Q1 (k)

Now, rewinding T to just before the `th query, and again attempting
a forgery on the same set of keys, (and letting H1 compute new coin
flips for all of its succeeding queries) then by Lemma 6, it follows that
the probability that T 0 is also a successful forgery satisfies
`, (T 0 )

1
1

.
n (qH + nqS ) Q1 (k)

RING CONFIDENTIAL TRANSACTIONS

16

Therefore, the probability that both T and T 0 correspond to verifying

forgeries and 0 is non-negligible:
l, (T and T 0 ) (l, (T ))2 .
As new coin-flips have been computed for the random oracle outputs
of H1 , it follows that with overwhelming probability there is j such that
sj 6= s0j and c 6= c+1 . Thus we can solve for the private key of index
:
xj =

s0j sj
mod q
c c0

which contradicts the discrete logarithm assumption.

2.5. MLSAG Linkability.

Theorem 8. (Key-Image Linkability) The probability that a PPT adversary A can create two verifying (and unlinked in the given setting)
signatures , 0 signed with respect to key vectors y and y 0 respectively
such that there exists a public key y in both y and y 0 is negligible.
Proof. Suppose to the contrary that A has created two verifying signatures and 0 both signed with respect to key vectors y and y 0
respectively such that there exists a public key y in both y and y 0 . Let
y appear as element j of y, and as element j 0 element of y 0 . By Theorem
7, it holds with overwhelming probability that there exists indices
and 0 for the public keys in and 0 respectively such that
Lj = sj G + c yj


Rj = sj H yj + c Ij

RING CONFIDENTIAL TRANSACTIONS

17

and

j
j
Lj0
0 = s 0 G + c 0 y 0
 0
0
0
Rj 0 = sj0 H yj 0 + c0 Ij 0

with
logG Lj = logH (yj ) Rj
and
0

logG Lj0 = logH yj0  Rj 0

0

Letting x denote the private key of y, y = xG, then after solving the
above for Ij and Ij 0 it follows that Ij = xH (yj ) = xH (y) and similarly
Ij 0 = xH (y) . Thus the two signatures include Ij = Ij 0 , and therefore,
since duplicate key images are rejected, one of them must not verify. 
2.6. MLSAG Anonymity. To prove the anonymity of the above protocol in the random oracle model, let H1 , H2 be random oracles modeling discrete hash functions. Let A be an adversary against anonymity. I
construct an adversary M against the Decisional Diffie Helman (DDH)
assumption as follows. The DDH asumption says that given a tuple
(G, aG, bG, G), the probability of determining whether G = abG is
negligible.
Theorem 9. Ring CT protocol is signer-ambiguous under the Decisional Diffie-Helman assumption.
Proof. (Similar proof to [LWW04, Theorem 2]) Assume that the Decisional Diffie-Helman problem is hard in the cyclic group generated by

RING CONFIDENTIAL TRANSACTIONS

18

G and suppose there exists a PPT adversary A against signer ambiguity. Thus given a list L of n public key-vectors of length m, a set of
t private keys Dt = {x1 , ..., xt }, a valid signature on L signed by a
user with respect to a key-vector y such that the corresponding private
key-vector x = (x1 , ..., xm ) satisfies xj
/ Dt , then A can decide with
probability
P r (A ) >

1
1
+
n t Q (k)

for some polynomial Q (k). I construct a PPT adversary M which

takes as inputs a tuple (G, aG, bG, ci G) where i {0, 1} is randomly
chosen (and not a priori known to M), c1 = ab, and c0 is a random
scalar, and outputs i with probability
P r (M (G, aG, bG, ci G) i)

1
1
+
2 Q2 (k)

for some polynomial Q2 (k).

Consider an algorithm SIMNIZKP (similar to the one defined in
[FS07]) which takes as input scalars a, c , a private key vector x, a set
of public key-vectors y i , i = 1, ..., m, an index , and a message m and
acts on these as follows:
1. Generate random scalars s1 , ..., sm and, a random scalar c H.
2. For j indexing x, set
L1 = aG
R1 = cG
and for all other j
Lj = sj G + c yj

RING CONFIDENTIAL TRANSACTIONS

19

Rj = sj H yj + c xj H yj
3. Compute a random output from the random oracle


m
c+1 H m, L1 , R1 , ..., Lm
, R .
4. For each i, working mod m, compute
Lji = sji G + ci yj




Rij = sji H yij + ci xj H yij


m
ci+1 H m, L1i , Ri1 , ..., Lm
.
i + Ri
and note that at the last step when i = 1, then ci+1 is already
determined, to maintain consistency with the random oracle output.
Note that regardless of whether x is the actual private key corresponding to y, due to the fact that consistency is maintained by the
random oracles in subsequent calls, the above signature verifies. If x is
actually the private key-vector of y , then there is no difference between
SIMNIZKP and an actual signature.
Finally, given a tuple (G, aG, bG, ci G) where a, b are randomly selected scalars, with c1 = ab, c0 a random element, i {0, 1}, M takes
the following steps to solve the Decisional Diffie Helman Problem with
non-negligible probability. M grabs a random H from the random oracle and takes a private / public key-vector pair (x, y), and then
computes s such that a = s + x. Now M performs SIMNIZKP with
arbitrarily selected key-vectors {yi }i=1,...,n such that y = y , a a,
ci c some message m, and x x.

RING CONFIDENTIAL TRANSACTIONS

20

If it is the case that i = 1, then c = ab, then

logG aG = logbG cG = a
and due to the fact that A is assumed to be able to find with nonnegligible probability, then there is a non-negligible probability over

1
2

that A returns 1 (upon which M returns 1). If i = 0, then A returns

1 only with probability 21 , and so for some non-negligible probability
over 21 , M returns the same value as A, and thus solves the Decisional
Diffie-Helman problem for randomly chosen scalars with non-negligible
probability over 12 , which is a contradiction.

3. Background on Confidential Transactions

3.1. Confidential Transactions in Bitcoin. In [Max15], Greg Maxwell
describes Confidential Transactions which are a way to send Bitcoin
transactions with the amounts hidden. The basic idea is to use a Pedersen Commitment and the method is well described in the cited source.
In this paper I make a slight modification the the Confidential Transactions machinery in that rather than taking the commitments to sum
to zero, I instead sign for the commitment, to prove I know a private
key. This is described in more detail in the next section.

3.2. Modification for Ring Signatures. Let G be the ed25519 basepoint. Let3
H = toP oint (cn_f ast_hash (G))
3H

= M iniN ero.getHF orCT () in terms of the code at [Noe15]

RING CONFIDENTIAL TRANSACTIONS

21

Note that not every hash gives a point in the group of the basepoint (i.e.
H = G for some unknown ) (which is contrary to what happens in
secp256k1, the curve used by Bitcoin). However, it seems that choosing the basepoint itself works (I previously used H(123456G) which
seemed more secure to me, but the basepoint is certainly a more natural choice). Choosing H = G for some unknown is necessary so
that all the usual elliptic curve math holds.
Under the discrete logarithm assumption on ed25519, the probability
of an adversary discovering is negligible. Define C (a, x) = xG + aH,
the commitment to the value a with mask x. Note that as long as
logG H is unknown, and if a 6= 0, then logG C (a, x) is unknown. On the
other hand, if a = 0, then logG C (a, x) = x, so it is possible to sign
with sk-pk keypair (x, C (0, x)) .
In [Max15], there are input commitments, output commitments, and
the network checks that
X

Inputs =

Outputs.

However, this does not suffice in Monero: Since a given transaction

contains multiple possible inputs Pi , i = 1, ..., n, only one of which
belong to the sender, (see [vS13, 4.4]), then if we are able to check
the above equality, it must be possible for the network to see which Pi
belongs to the sender of the transaction. This is undesirable, since it
removes the anonymity provided by the ring signatures. Thus instead,
commitments for the inputs and outputs are created as follows (suppose
first that there is only one input)

RING CONFIDENTIAL TRANSACTIONS

22

Cin = xc G + aH
Cout1 = y1 G + b1 H
Cout2 = y2 G + b2 H
such that xc = y1 + y2 + z, xc y1 y2 = z, yi are mask values, z > 0
and a = b1 +b2 . Here xc is a special private key the amount key known
only to the sender, and to the person who sent them their coins, and
must be different than their usual private key. In this case,
Cin

2
X

Couti

i=1

= xc G + aH y1 G b1 H y2 G b2 H
= zG.
Thus, the above summation becomes a commitment to 0, with sk =
z, and pk = zG, rather than an actual equation summing to zero.
Note that z is not computable to the originator of xc s coins, unless
they know both of the y1 , y2 , but even this can be simply mitigated
by including an additional change address (the usual case is that the
second commitment, with y2 as mask, is sent to yourself as change).
Since it is undesirable to show which input belongs to the sender, a
ring signature consisting of all the input commitments Ci , i = 1, ..., s, ..., n
(where s is the secret index of the commitment of the sender), adding
the corresponding pubkey (so commitments and pubkeys are paired
P
(Ci , Pi ) only being allowed to be spent together) and subtracting Cout

RING CONFIDENTIAL TRANSACTIONS

23

is created:
(
P1 + C1,in

)
X

Cj,out , ..., Ps + Cs,in

Cj,out , ..., Pn + Cn,in

Cj,out

This is a ring signature which can be signed since we know one of the
private keys (namely z + x0 with z as above and x0 G = Ps ). In fact,
since we know, for each i, both the private key for Pi and the private
P
key for Pi + Ci,in j Cj,out , we can perform a signature as in section
2.2. This precise details are described in Definition 10.
As noted in [Max15], it is important to prove that the output amounts4
b1 , ...bn all lie in a range of positive values, e.g. (0, 216 ). This can be
accomplished essentially the same way as in [Max15] and is described
in more detail in section 5.
Finally, note that in the above, I have not made any mention of
the tag-linkability property which is used in Monero and Cryptonote
to prevent double-spends. The tag-linkability property here will result
from combining the above discussion with the MLSAG signatures as
described in Definition 10.

4. Ring CT For Monero Protocol

4.1. Protocol Description.

Definition 10. (Tag-Linkable Ring-CT with Multiple Inputs and Onetime Keys)
4Since

input commitments could potentially be just inherited from the previous

transaction, it suffices to consider the output amounts.

RING CONFIDENTIAL TRANSACTIONS

24

Let {(P1 , C1 ) , ..., (Pm , Cm )} be a collection of addresses / commitments with corresponding secret keys xj , j = 1, ..., m.
Find q + 1 collections {(Pi1 , Ci1 ) , ..., (Pim , Cim )} , i = 1, ..., q + 1
which are not already tag linked in the sense of [FS07, page 6].
P
j
Decide on a set of output addresses (Qi , Ci,out ) such that m
j=1 C
P
i Ci,out is a commitment to zero.
Let
((
R :=

1

P11 , C1 , ..., (P1m , C1m ) ,

P1j

m
X

j=1

m
X

!)
C1j

Ci,out

...,
(
1
1
m
m
Pq+1
, Cq+1
, ..., Pq+1
, Cq+1
,

j
Pq+1
+

j=1

!))
j
Cq+1

Ci,out

be the generalized ring which we wish to sign. Note that the

last column is a Ring-CT ring in the sense of section 4.
Compute the MLSAG signature on R.

In this case, by Theorem 7, Pj , j = 1, ..., m cannot be the signer of

any additional non-linked Ring Signatures in the given superset P of
all such pairs P = {(P, C)} after signing .

Remark 11. Space complexity of the above protocol. Note that the
size of the signature on R according to definition 10 is actually
smaller, for m > 1, than a current CryptoNote [vS13] ring signature
based transaction which includes multiple inputs. This is because of
the size improvements, given by [LWW04], to each column. Note also,

RING CONFIDENTIAL TRANSACTIONS

25

it is probably not necessary to include the key-image of the commitment entry of the above signature. Further size optimizations are likely
possible.
4.2. Conversion from Visible Denominations to Commitments.
As Monero currently uses Blockchain visible scalars to represent amounts,
it is important that there is a way to convert from visible amounts to
commitments while preserving anonymity. In fact, this is not difficult.
Given a pair (P, a) where P is a public key and a represents an amount,
this may be used as the input to a transaction as (P, aH), and it must
be checked by the verifier that the input amount a multiplied by the
masking point H, indeed gives aH. Thus at the first step, the input
amounts will not be hidden, but the outputs of this transaction can be
hidden, and all the necessary relations outlined in section 4 hold. Note
that a range proof is not necessary for such an input.
Remark 12. The obvious benefit of this method of converting from
visible amounts to commitments is that the amount of coins generated
by the mining process is trustlessly verifiable. This is an advantage of
the Ring CT protocol over payment schemes such as [BSCG+ 14] which
rely on a trusted setup phase.
4.3. Transaction Fees. As Monero is strongly decentralized (i.e. proof
of work) it is necessary to pay miners a transaction fee for each transaction. This helps with the network security to prevent blockchain
bloat. These fees must be paid "unmasked" i.e. just as bH, rather
than xG + bH, and for some standardized amount b so that the miner

RING CONFIDENTIAL TRANSACTIONS

26

can verify that b H = bH and thus there is enough money for the
transaction fee while still having the equations in terms of H so the
necessary relations of section 4 hold.

5. Aggregate Schnorr Range Proofs

In [Max15], the confidential transactions without ring signatures uses
a type of ring signature based on [AOS02] called a Borromean ring
signature, which helps to prove a committed value lies within a certain
range. In this article, I will outline an alternative method, inspired
by [Her05], which has the same space savings, but perhaps simpler
security proofs. The motivation for this is as follows: Suppose that a
given transaction has input commitments
Cin = ain G + 10H
and output commitments
Cout,1 = aout,1 G + 5H, Cout,2 = aout,2 G + 5H
this scenario is valid as it is possible to sign for
Cin Cout,1 Cout,2 = (ain aout,1 aout,2 ) G
However, note that (without range proofs) it would be possible to alternatively set output commitments
Cout,1 = aout,1 G H, Cout,2 = aout,2 G + 11H

RING CONFIDENTIAL TRANSACTIONS

27

as 1 is a very large number modulo the curve group order, free money
has been created. It is therefore necessary to prove that the Cout,i are
commitments to values which are positive and lie in a restricted range
[0, 2n ] for some n. To do this, one decomposes each output value into
binary:
b = b0 20 + b1 21 + b2 22 + + bn 2n
j
and computes commitments Cout,i
to bj 2j and such that

1
2
n
Cout,i
+ Cout,i
+ + Cout,i
= Cout,i

Finally, using secret key bj , one computes a ring signature on

j
j
, Cout,i
2j H)
(Cout,i

j
for all j and provides the Cout,i
to the verifying parties (in this case,

the miners).
For space savings, one can either use a Borromean ring signature (as
in [Max15]) to combine all of these simple ring signatures, or a type of
aggregate ring signature defined as follows:

5.0.1. Aggregate Schnorr Non-linkable Ring Signature (ASNL) Generation. Let (xji , P1j , P2j ) be a set of keys, j = 1, ..., n with xji the secret
key of Pij
For each j, let i0 := i + 1 mod 2, set j a random scalar, and
compute Lji = j G.

RING CONFIDENTIAL TRANSACTIONS

28

Set cji0 = Hs (Lji ), where Hs is a cryptographic hash function

returning a scalar, and after choosing sji0 random, compute
Lji0 = si0 G + ci0 H.
Set ci = Hs (Lji0 ) and compute
sji = cji xi mod `
Return (Lj1 , sj2 ) for all j and s =

sj1 .

5.0.2. Aggregate Schnorr Non-linkable Ring Signature (ASNL) Verification. Start with (P1j , P2j , Lj1 , sj2 ) for j = 1, ..., n and s.
For all j, compute cj2 = Hs (Lj1 ), Lj2 = sj2 G + cj2 H, and cj1 =
Hs (Lj2 ).
P
If nj=1 Lj1 = sG + (cj1 + + cjn )H then return 0 for a valid
signature. Otherwise return 1.
Theorem 13. The Aggregate Schnorr Non-linkable ring signature is
unforgeable under the discrete logarithm assumption.
Proof. I sketch a proof in the case n = 2. The general case is similar.
Suppose that an adversary A is able to forge an ASNL signature on


(x1i , P11 , P21 ), (x2i , P12 , P22 )

with non-negligible probability while knowing at most one of the xji

(suppose without loss of generality that A knows x1i ). For any given
such forgery:
{s, (P1j , P2j , Lj1 , sj2 )}, j = 1, 2,

RING CONFIDENTIAL TRANSACTIONS

29

I solve the discrete logarithm of P12 with non-negligible probability.

Following the verification algorithm, let cj1 = Hs sj2 G + Hs (Lj1 )H . It
must then be true that


L11 + L21 = sG + c11 P11 + c21 P12 .
Supposing that L11 = aG and L21 = bG with a, b known to A, then
aG + bG sG c11 P11 = c21 P12
so, as c21 is determined by the verification protocol, it must be the case
that A knows the private key of P12 ,
x21 :=

a + b s c11 x11
c21

mod `

This contradicts the discrete logarithm assumption for the given group.

5.1. Representing Amounts. Amounts in the Ring CT protocol be
represented in essentially the same manner as in [Max15].
5.1.1. Passing Amounts to Receiver. Now, given any output amount,
b = b0 20 + b1 21 + bn 2n , a sender computes a new private /public key
pair and corresponding shared ECDH secret ss and makes the following
information available in their transaction:
Cj = aj G + (bj 2j )H where ai are some random numbers for
j = 0, ..., n.


The data (Li1 , sj2 ), s .
ECDH public key and a + ss mod ` where a = a0 + + an .

RING CONFIDENTIAL TRANSACTIONS

30

The receiver then:

Computes their shared secret ss and computes a from a +
ss mod `.
Computes C =

Ci , computes C aG = bH, and finds b

by comparing to all bH in the given range [0, 2n ]. (In practice

this will be a quick 500 kilobyte lookup with n = 14 as in the
previous section. If on the other hand 232 were to be chosen as
the upper limit value, as in [Max15], the search would become
computationally intensive).

6. Ring CT Demo Code

In the repository at [Noe15] I have created a simple demonstration
of the Ring Confidential Transactions protocol utilizing the MLSAG
signatures of section 2 and the ASNL signatures of section 5:
H_ct = RingCT.getHForCT()
print("H", H_ct)
sr, Pr = PaperWallet.skpkGen() #receivers private/ public
se, pe, ss = ecdh.ecdhgen(Pr) #compute shared secret ss
digits = 14 #in practice it will be 14
print("inputs")
Cia, L1a, s2a, sa, ska = RingCT.genRangeProof(10000, digits)
print("outputs")
Cib, L1b, s2b, sb, skb = RingCT.genRangeProof(7000, digits)
Cic, L1c, s2c, sc, skc = RingCT.genRangeProof(3000, digits)
print("verifying range proofs of outputs")

RING CONFIDENTIAL TRANSACTIONS

31

RingCT.verRangeProof(Cib, L1b, s2b, sb)

RingCT.verRangeProof(Cic, L1c, s2c, sc)
x, P1 = PaperWallet.skpkGen()
P2 = PaperWallet.pkGen()
C2 = PaperWallet.pkGen()
#some random commitment grabbed from the blockchain
ind = 0
Ca = RingCT.sumCi(Cia)
Cb = RingCT.sumCi(Cib)
Cc = RingCT.sumCi(Cic)
sk = [x, MiniNero.sc_sub_keys(ska, MiniNero.sc_add_keys(skb, skc))]
pk = [[P1, P2], [MiniNero.subKeys(Ca, MiniNero.addKeys(Cb, Cc)), \
MiniNero.subKeys(C2, MiniNero.addKeys(Cb, Cc)) ] ]
II, cc, ssVal = MLSAG.MLSAG_Sign(pk, sk, ind)
print("Sig verified?", MLSAG.MLSAG_Ver(pk, II, cc, ssVal) )
print("Finding received amount corresponding to Cib")
RingCT.ComputeReceivedAmount(pe, sr, MiniNero.addScalars(ss, skb), Cib)
print("Finding received amount corresponding to Cic")
RingCT.ComputeReceivedAmount(pe, sr, MiniNero.addScalars(ss, skc), Cic)

Here is an example transaction with input 10, 000 and outputs 3, 000
and 7, 000.
(H, 61fe7f0f5a607a33427d01dd1fded5ffa03fae2e9df9ebccf2e0a2f5bd77a204)
inputs
(b, b in binary, 10000, [0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 1, 0, 0, 1])

RING CONFIDENTIAL TRANSACTIONS

32

Generating Aggregate Schnorr Non-linkable Ring Signature

outputs
(b, b in binary, 7000, [0, 0, 0, 1, 1, 0, 1, 0, 1, 1, 0, 1, 1, 0])
Generating Aggregate Schnorr Non-linkable Ring Signature
(b, b in binary, 3000, [0, 0, 0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 0, 0])
Generating Aggregate Schnorr Non-linkable Ring Signature
verifying range proofs of outputs
Verifying Aggregate Schnorr Non-linkable Ring Signature
Verified
Verifying Aggregate Schnorr Non-linkable Ring Signature
Verified
(Generating MLSAG sig of dimensions , 2, x , 2)
(verifying MLSAG sig of dimensions , 2, x , 2)
(c,
[80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42,
a9b7342ba7bf2f102505ca19dab734fde638916c0a29f5b30e49833ab51393ea,
80a3cfd06dd2862307cd75c2a1566f20cd743dbb0b9feb22d79dcbecb9023f42])
(sig verifies?, True)
(Sig verified?, True)
Finding received amount corresponding to Cib
(received , 7000,
a488ec68732fb551841c2c6dcc7ffac895d98ec7e9378275ed20ea12805fc18e)
Finding received amount corresponding to Cic
(received ,3000,
1b46626858e130a0f3884c74c9fdeabc4d812c519103ea16a35a3f82a3d0ed6d)

RING CONFIDENTIAL TRANSACTIONS

33

7. Conclusion
The Ring Confidential Transactions protocol provides a strongly decentralized cryptocurrency (i.e. there is no privileged party) which has
provable security estimates regarding the hiding of amounts, origins
and destinations. In addition, coin generation in the Ring Confidential Transactions protocol is trustless and verifiably secure. These five
factors are a necessity of a cash-like crypto-currency such as Monero.

References
[AMT15]

Surae Noether Adam Mackenzie and Monero Core Team. Improving

obfuscation in the cryptonote protocol, jan 2015.

[AOS02]

Masayuki Abe, Miyako Ohkubo, and Koutarou Suzuki. 1-out-of-n signatures from a variety of keys. Advances in Cryptology?Asiacrypt 2002,
pages 415432, 2002.

[Bac13]

Adam Back. Bitcoins with homomorphic value (validatable but

encrypted). https://bitcointalk.org/index.php?topic=305791.
0, 2013. [Online; accessed 1-May-2015].

[Bac15]

Adam Back. Ring signature efficiency. https://bitcointalk.org/

index.php?topic=972541.msg10619684#msg10619684,

2015. [On-

line; accessed 1-May-2015].

[BSCG+ 14] Eli Ben Sasson, Alessandro Chiesa, Christina Garman, Matthew
Green, Ian Miers, Eran Tromer, and Madars Virza. Zerocash: Decentralized anonymous payments from bitcoin. In Security and Privacy
(SP), 2014 IEEE Symposium on, pages 459474. IEEE, 2014.
[DH14]

Evan Duffield and Kyle Hagan. Darkcoin: Peertopeer cryptocurrency

with anonymous blockchain transactions and an improved proofofwork
system. 2014.

RING CONFIDENTIAL TRANSACTIONS

[FS07]

34

Eiichiro Fujisaki and Koutarou Suzuki. Traceable ring signature. In

Public Key CryptographyPKC 2007, pages 181200. Springer, 2007.

[Her05]

Javier Herranz. Aggregate signatures. http://www.iiia.csic.es/

~jherranz/papers/Nijmegen_seminar_aggregate.pdf, oct 2005.

[LWW04]

Joseph K Liu, Victor K Wei, and Duncan S Wong. Linkable spontaneous anonymous group signature for ad hoc groups. In Information
Security and Privacy, pages 325335. Springer, 2004.

[Max13]

Greg Maxwell. Coinjoin: Bitcoin privacy for the real world, august
2013. Bitcoin Forum. https://bitcointalk.org/index.php?topic=
279249.0, 2013. [Online; accessed 1-July-2015].

[Max15]

Greg Maxwell. Confidential Transactions. https://people.xiph.

org/~greg/confidential_values.txt, 2015. [Online; accessed 1June-2015].

[Nak08]

Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system.

Consulted, 1(2012):28, 2008.

[Noe15]

Shen

Noether.

Mininero.

https://github.com/ShenNoether/

MiniNero, 2015.
[RST01]

Ronald L Rivest, Adi Shamir, and Yael Tauman. How to leak a secret. In Advances in Cryptology???ASIACRYPT 2001, pages 552565.
Springer, 2001.

[vS13]

Nicolas van Saberhagen. Cryptonote v 2. 0. HYPERLINK https: //

cryptonote. org/ whitepaper. pdf , 2013.