\author{Shen Noether, Adam Mackenzie- Monero Research Labs}
\begin{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. Some extensions of the protocol are provided, such as Aggregate Schnorr Range Proofs, and Ring Multisignature. 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 \cite{Snoe}.
\end{abstract}
\maketitle
\tableofcontents
\section{Introduction}
\subsection{Spontaneous (Ad Hoc) Ring Signatures in CryptoCurrencies}
Recall that in Bitcoin each transaction is signed by the owner of
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 \cite{CN} and Ring Coin
\cite{B2} advanced this idea by using ``ring signatures'' which were originally described
in \cite{RST} as a ``digital signature that specifies a group of
possible signers such that the verifier can't 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 \cite{CN}
implements a slight modification of this to prevent double spends.
Namely in \cite{CN} a ``traceable ring signature,'' which is a slight modification of those described in
\cite{FS} 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 \cite{B2,B} uses a more efficient linkable
ring signature which is a slight modification of the Linkable Spontaneous
Anonymous Group signatures described in \cite{LWW}.
One benefit of using the above types of ring signatures over other anonymizing techniques, such as CoinJoin \cite{GMc} 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 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 \cite{DASH}, 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 \cite{CN,B2}
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 \cite{CN}
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, 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 $\left(P,A\right)$ 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
$\left(P^{\prime},A^{\prime}\right)$ available on the blockchain
with $A^{\prime}=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 \cite{mrl4}.
\subsection{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 \cite{GM} 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 LSAG's of \cite{LWW} is described, a Multilayered Linkable
Spontaneous Anonymous Group Signature (MLSAG) 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. The author notes that an essentially similar protocol was proposed by Connor Frenkenecht about a month after the second drafts of this were originally publicized.
The Ring CT protocol allows hidden amounts, origins, and destinations
for transactions which is somewhat similar to Zerocash \cite{Z}.
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 \cite{SN}, 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 \footnote{The author previously had assumed this would allow the unmasking of transactions as well, but the newer ZeroCash paper claims this is not possible.}) to acquire all pieces of the trusted generation
key, this is fairly important.
\subsection{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 disclosure, the author received several donations totalling between 2 and 3 bitcoins from the Monero community in gratitude for his work on this research.
\section{Multilayered Linkable
Spontaneous Anonymous Group Signatures}
\label{MLSAGsection}
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 LSAG's described in \cite{LWW}, 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.
\begin{defn}
\label{def:A-key-vector-is}A \textbf{key-vector} is just a collection
$\overline{y}=\left(y_{1},...,y_{r}\right)$ of public keys with corresponding
\subsection{\label{sub:BackLSAG}LWW signatures vs FS signatures}
The ring signatures used in Monero and the original CryptoNote protocol are
derived from the traceable ring signatures of \cite{FS}. The CryptoNote \cite{CN}
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 \cite{B}, Adam Back noticed that the Linkable Spontaneous Anonymous
Group (LSAG) signatures of \cite{LWW} can be modified to give a more efficient
linkable ring signature producing the same effect as the \cite{FS}
ring signatures. This modification reduces the storage cost on the
blockchain essentially in half.
First I recall almost verbatim the modification given in \cite{B}:
\textbf{Keygen}: Find a number of public keys $P_{i},i=0,1,...,n$
and a secret index $j$ such that $xG=P_{j}$ where $G$ is the ed25519
base-point and $x$ is the signers spend key. Let $I=xH_p\left(P_{j}\right)$
where $H_p$ is a hash function returning a point \footnote{In practice $H_p(P)= Keccak(P)\cdot G$ where $G$ is the ed25519 basepoint, although note that for the commitment scheme I will use $toPoint(Keccak(P))$, hashing successively until $Keccak(P)$ returns a multiple of the basepoint.}
Let $\mathfrak{m}$ be a given message.
\textbf{SIGN}: Let $\alpha,s_{i},\ i\neq j,\ i\in\left\{1,...,n\right\}$
be random values in $\mathbb{Z}_{q}$ (the ed25519 base field).
Compute
\[
L_{j}=\alpha G
\]
\[
R_{j}=\alpha H_p\left(P_{j}\right)
\]
\[
c_{j+1}=h\left(\mathfrak{m},L_{j},R_{j}\right)
\]
where $h$ is a hash function returning a value in $\mathbb{Z}_{q}$.
Now, working successively in $j$ modulo $n$, define
\[
L_{j+1}=s_{j+1}G+c_{j+1}P_{j+1}
\]
\[
R_{j+1}=s_{j+1}H_p\left(P_{j+1}\right)+c_{j+1}\cdot I
Note that not every hash gives a point in the group of the basepoint (i.e. $H=\psi G$ for some unknown $\psi$) (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 =\gamma G$ for some unknown $\gamma$ is necessary so that all the usual elliptic curve math holds.
Under the discrete
logarithm assumption on ed25519, the probability of an adversary discovering $\gamma$
is negligible.
Define $C\left(a,x\right)=xG+aH$, the commitment to the value $a$
with mask $x$. Note that as long as $log_{G}H$ is unknown, and if
$a\neq0$, then $log_{G}C\left(a,x\right)$ is unknown. On the other
hand, if $a=0$, then $log_{G}C\left(a,x\right)=x$, so it is possible
to sign with sk-pk keypair $\left(x,C\left(0,x\right)\right).$
In \cite{GM}, there are input commitments, output commitments, and
the network checks that
\[
\sum Inputs=\sum Outputs.
\]
However, this does not suffice in Monero: Since a given transaction
contains multiple possible inputs $P_{i},i=1,...,n$, only one of
which belong to the sender, (see \cite[4.4]{CN}), then if we are
able to check the above equality, it must be possible for the network
to see which $P_{i}$ 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)
\[
C_{in}=x_{c}G+aH
\]
\[
C_{out-1}=y_{1}G+b_{1}H
\]
\[
C_{out-2}=y_{2}G+b_{2}H
\]
such that $x_{c}=y_{1}+y_{2}+z$, $x_{c}-y_{1}-y_{2}=z$, $y_{i}$
are mask values, $z>0$ and $a=b_{1}+b_{2}.$ Here $x_{c}$ 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,
\[
C_{in}-\sum_{i=1}^{2}C_{out-i}
\]
\[
=x_{c}G+aH-y_{1}G-b_{1}H-y_{2}G-b_{2}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 $x_{c}$'s coins,
unless they know both of the $y_{1},y_{2}$, but even this can be simply mitigated by including an additional change address (the usual case is that the second commitment, with $y_2$ 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 $C_{i},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
$\left(C_{i},P_{i}\right)$ only being allowed to be spent together)
This is a ring signature which can be signed since we know one of
the private keys (namely $z+x^{\prime}$ with $z$%
\begin{comment}
note you can't use $x_{s}=s$, or else once the output amount is unvelied,
the ring sig is caput - check this, since there are masks...
\end{comment}
as above and $x^{\prime}G=P_{s}$). In fact, since we know, for each $i$, both the private key for $P_{i}$ and the private key for $P_{i}+C_{i,in}-\sum_{j}C_{j,out}$,
we can perform a signature as in section \ref{sub:MLSAG-Description}. This precise details are described in Definition \ref{RCTProtocol}.
As noted in \cite{GM}, it is important to prove that the output amounts\footnote{Since input commitments could potentially be just inherited from the
previous transaction, it suffices to consider the output amounts.}
$b_{1},...b_{n}$ all lie in a range of positive values, e.g. $(0,2^{16}).$
This can be accomplished essentially the same way as in \cite{GM} and is described in more detail in section \ref{AgSchnorr}.
\begin{comment}
\begin{itemize}
\item Write each output amount $b_i$ as
\[
b_i = \delta_{ij}
\]
\item Prove first $C_{out-i}^{\left(j\right)}\in\left\{0,2^{j}\right\}$
for all $j\in\left\{0,1,...,16\right\} .$ This is done as in \cite{GM}:
for example, $C_{out-i}^{0}=y_{i}^{0}G+b_{i}^{0}H$ where $b_{i}^{0}\in\left\{0,1\right\}$.
\item By homomorphicity of the commitments, $b_{i}=\sum_{j}\delta_{ji}2^{j}$,
where $\delta_{ji}$ is the $j^{th}$ digit in the binary expansion
of $b_{i}$.
\end{itemize}
Thus in total, by the above, the sum of inputs into a transaction
equals the outputs, yet the specific input (and it's index!) is hidden.
In addition, the outputs are positive values.
\end{comment}
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 \ref{RCTProtocol}.
\section{\label{sec:Ring-CT-ForMonero}Ring CT For Monero Protocol}
\subsection{Protocol Description}
\begin{defn}
\label{RCTProtocol}(Tag-Linkable Ring-CT with
Multiple Inputs and One-time Keys) \end{defn}
\begin{itemize}
\item Let $\left\{\left(P_{\pi}^{1},C_{\pi}^{1}\right),...,\left(P_{\pi}^{m},C_{\pi}^{m}\right)\right\}$
be a collection of addresses / commitments with corresponding secret
be the generalized ring which we wish to sign. Note that the last
column is a Ring-CT ring in the sense of section \ref{sec:Ring-CT-ForMonero}.
\item Compute the MLSAG signature $\Sigma$ on $\mathfrak{R}.$
\end{itemize}
In this case, by Theorem \ref{thm:Unforgeability}, $P_{\pi}^{j},j=1,...,m$ cannot be the signer of any
additional non-linked Ring Signatures in the given superset $\mathcal{P}$
of all such pairs $\mathcal{P}=\left\{\left(P,C\right)\right\}$
after signing $\Sigma$.
\begin{rem}
Space complexity of the above protocol. Note that the size of the
signature $\Sigma$ on $\mathfrak{R}$ according to definition \ref{RCTProtocol}
is actually smaller, for $m>1$, than a current CryptoNote \cite{CN}
ring signature based transaction which includes multiple inputs. This
is because of the size improvements, given by \cite{LWW}, to each
column. Note also, it is probably not necessary to include the key-image
of the commitment entry of the above signature. Further size optimizations
are likely possible.\end{rem}
\subsection{Conversion from Visible Denominations to Commitments}
\label{conversion}
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 \ref{sec:Ring-CT-ForMonero} hold. Note that a range proof is not necessary for such an input.
\begin{rem}
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 \cite{Z} which rely on a trusted setup phase.
\end{rem}
\subsection{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 can verify that $b\cdot 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 \ref{sec:Ring-CT-ForMonero} hold.
\subsection{Ring Multisignature}
Note that a simple version of a $t$ of $m$ of $n$ ring- multisignature can be done with the MLSAG signatures. This allows a group of $m$ participants to create a multi-signature such that $t$ out of $m$ must sign for the signature to be accepted as valid, and in addition, it is signer ambiguous which $m$ keys are the participants out of the $n$ keys.
\begin{itemize}
\item The $n$ participants in the multisignature create a shared secret $x_e$ and public key $P_e$ and share multisig key-images
\[
I_j = x_e H(P_e | P_j)
\]
with $P_j$ the public key of the participant.
\item Any participant of the multisignature selects $n-m$ additional public keys on the block-chain and creates an MLSAG signature with the first row the total $n$ keys, and the second row having each entry the shared key $P_e$.
\item Each signer transmitting part of the multisignature provides the initial $I_j,\ j=1,...,m$ so that the signature is accepted after $t$ verifying signatures have been transmitted on the blockchain, each corresponding to one of the key images $I_j$.
\end{itemize}
\section{Aggregate Schnorr Range Proofs}
\label{AgSchnorr}
In \cite{GM}, the confidential transactions without ring signatures uses a type of ring signature based on \cite{abe} 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 \cite{herranz}, 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
\[
C_{in} = a_{in} G + 10 H
\]
and output commitments
\[
C_{out,1} = a_{out,1} G + 5 H,\ C_{out,2} = a_{out,2} G + 5 H
\]
this scenario is valid as it is possible to sign for
However, note that (without range proofs) it would be possible to alternatively set output commitments
\[
C_{out,1} = a_{out,1} G - H,\ C_{out,2} = a_{out,2} G + 11 H
\]
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 $C_{out,i}$ are commitments to values which are positive and lie in a restricted range $[0,2^n]$ for some $n$.
To do this, one decomposes each output value into binary:
Finally, using secret key $b_j$, one computes a ring signature on
\[
(C_{out,i}^j, C_{out,i}^j - 2^j H)
\]
for all $j$ and provides the $C_{out,i}^j$ to the verifying parties (in this case, the miners).
For space savings, one can either use a Borromean ring signature (as in \cite{GM}) to combine all of these simple ring signatures, or a type of aggregate ring signature defined as follows:
\subsubsection{ Aggregate Schnorr Non-linkable Ring Signature (ASNL) Generation}
Let $(x_i^j, P_1^j, P_2^j)$ be a set of keys, $j=1,...,n$ with $x_i^j$ the secret key of $P_i^j$
\begin{itemize}
\item For each $j$, let $i^\prime := i+1\ mod\ 2$, set $\alpha_j$ a random scalar, and compute $L_i^j =\alpha_j G$.
\item Set $c_{i^\prime}^j= H_s(L_i^j)$, where $H_s$ is a cryptographic hash function returning a scalar, and after choosing $s_{i^\prime}^j$ random, compute
\[
L_{i^\prime}^j = s_{i^\prime} G + c_{i^\prime} H.
\]
\item Set $c_i = H_s(L_{i^\prime}^j)$ and compute
\[
s_i^j = \alpha - c_i^j x_i \ mod\ \ell
\]
\item Return $(L_1^j, s_2^j)$ for all $j$ and $s =\sum_j s_1^j$.
\end{itemize}
\subsubsection{ Aggregate Schnorr Non-linkable Ring Signature (ASNL) Verification}
Start with $(P_1^j, P_2^j, L_1^j, s_2^j)$ for $j=1,...,n$ and $s$.
\begin{itemize}
\item For all $j$, compute $c_2^j = H_s (L_1^j)$, $L_2^j = s_2^j G + c_2^j H$, and $c_1^j = H_s(L_2^j)$.
\item If $\sum_{j=1}^n L_1^j = s G +(c_1^j +\cdots+ c_n^j) H$ then return $0$ for a valid signature. Otherwise return $-1$.
\end{itemize}
\begin{thm}
The Aggregate Schnorr Non-linkable ring signature is unforgeable under the discrete logarithm assumption.
\end{thm}
\begin{proof}
I sketch a proof in the case $n=2$. The general case is similar. Suppose that an adversary $\mathcal{A}$ is able to forge an ASNL signature on
with non-negligible probability while knowing at most one of the $x_i^j$ (suppose without loss of generality that $\mathcal{A}$ knows $x_i^1$). For any given such forgery:
\[
\{s,(P_1^j, P_2^j, L_1^j, s_2^j)\},\ j=1,2,
\]
I solve the discrete logarithm of $P_1^2$ with non-negligible probability. Following the verification algorithm, let $c_1^j = H_s\left(s_2^j G + H_s(L_1^j)H\right)$. It must then be true that
Supposing that $L_1^1= a G$ and $L_1^2= bG$ with $a,b$ known to $\mathcal{A}$, then
\[
aG + bG - sG - c_1^1 P_1^1 = c_1^2 P_1^2
\]
so, as $c_1^2$ is determined by the verification protocol, it must be the case that $\mathcal{A}$ knows the private key of $P_1^2$,
\[
x_1^2 := \frac{a+b-s-c_1^1 x_1^1}{c_1^2}\mod\ell
\]
This contradicts the discrete logarithm assumption for the given group.
\end{proof}
\subsection{Representing Amounts }
Amounts in the Ring CT protocol be represented in a similar manner as in \cite{GM}, however modified slightly to fit Monero.
CryptoNote coins organize denominations of coins into a databases of indices, so that they may be referenced in order of their appearance as inputs for ring signatures. As all values in CryptoNote coins are represented as 64-bit unsigned integers, we can use a range proof over the entire register to encode the output amount to the recipient. Beneficially, this also allows all outputs to be mixed with each other, so only a single index of outputs in order of appearance is required. A range proof of this is approximately 5 kilobytes. Ring signatures for inputs then become much more resilient to analysis, as the anonymity set is widely expanded.
While the range proofs are large, using a transaction hashing scheme that signs the transaction "prefix" (both input indices and outputs) and stores the range proof, along with ring signatures, separately enables large amounts of space saving when syncing to a checkpoint or operating as an SPV node. Similar to Sidechains Elements \cite{El}, we would store
$H(H(prefix) || H(signatures))$ in the merkle tree. Then, nodes syncing to and trusting a checkpoint need only download the prefix and a hash of the signatures, effectively reducing the amount of bandwidth require to sync dramatically. Because the transaction prefix uses a varint for the outputs it references in its ring signatures and outputs funds to single public keys, they are miniscule in comparison to the ring signature data in the inputs and range proofs. Later, the ring signatures may even be pruned from the database by some nodes to further save space, storing instead only the comparatively small UTXO set.
\subsubsection{Passing Amounts to Receiver}
Now, given any output amount, $b = b_02^0+ b_12^1+\cdots b_n 2^n $, a sender computes a new private /public key pair and corresponding shared ECDH secret $ss$ and makes the following information available in their transaction:
\begin{itemize}
\item$C_j = a_j G +(b_j 2^j) H$ where $a_i$ are some random numbers for $j=0,...,n$.
\item The data $\left\{(L_1^i, s_2^j),s\right\}$.
\item ECDH public key and $a + ss\ mod\ \ell$ where $a = a_0+\cdots+ a_n$.
\end{itemize}
The receiver then:
\begin{itemize}
\item Computes their shared secret $ss$ and computes $a$ from $a + ss\ mod\ \ell$.
\item Computes $C =\sum C_i$, computes $C - aG = bH$, and finds $b$ by comparing to all $bH$ in the given range $[0, 2^n]$. (In practice this will be a quick 500 kilobyte lookup with $n =14$ as in the previous section. If on the other hand $2^{32}$ were to be chosen as the upper limit value, as in \cite{GM}, the search would become computationally intensive).
\end{itemize}
\section{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.
\bibliographystyle{alpha}
\bibliography{refs}
\appendix
\section{Appendix: Security Proofs}
\subsection{MLSAG Unforgeability}
This follows similarly to \cite[Theorem 1]{LWW}. Let $H_{1}$ and
$H_{2}$ random oracles, and $\mathcal{SO}$ be a signing oracle which
returns valid MLSAG signatures. Assume there is a probabilistic polynomial
time (PPT) adversary $\mathcal{A}$ with the ability to forge an MLSAG
from a list of key vectors $L$ with non-negligible probability
Letting $x$ denote the private key of $y,$$y=xG$, then after solving
the above for $I_{j}$ and $I_{j^{\prime}}$ it follows that $I_{j}=xH\left(y_{\pi}^{j}\right)=xH\left(y\right)$
and similarly $I_{j^{\prime}}=xH\left(y\right).$ Thus the two signatures
include $I_{j}=I_{j^{\prime}}$, and therefore, since duplicate key images are rejected, one of them must not verify.
\end{proof}
\subsection{MLSAG Anonymity}
To prove the anonymity of the above protocol in the random oracle
model, let $H_{1},H_{2}$ be random oracles modeling discrete hash
functions. Let $\mathcal{A}$ be an adversary against anonymity. I
construct an adversary $\mathcal{M}$ against the Decisional Diffie Helman
(DDH) assumption as follows.
The DDH asumption says that given a
tuple $\left(G,aG,bG,\gamma G\right)$, the probability of determining
whether $\gamma G=abG$ is negligible.
\begin{thm}
\label{thm:Ring-CT-protocol}Ring CT protocol is signer-ambiguous
under the Decisional Diffie-Helman assumption. \end{thm}
%asdf stopped editing here
\begin{proof}
(Similar proof to \cite[Theorem 2]{LWW}) Assume that the Decisional Diffie-Helman problem is hard in the cyclic group generated by $G$ and suppose there exists a PPT
adversary $\mathcal{A}$ against signer ambiguity. Thus given a list
$L$ of $n$ public key-vectors of length $m$, a set of $t$ private
keys $\mathcal{D}_{t}=\left\{ x_{1},...,x_{t}\right\}$, a valid
signature $\sigma$ on $L$ signed by a user with respect to a key-vector
$\overline{y}$ such that the corresponding private key-vector $\overline{x}=\left(x_{1}^{\pi},...,x_{m}^{\pi}\right)$
satisfies $x_{j}^{\pi}\notin\mathcal{D}_{t}$, then $\mathcal{A}$
for some polynomial $Q\left(k\right)$. I construct a PPT adversary
$\mathcal{M}$ which takes as inputs a tuple
$\left(G,aG,bG,c_{i}G\right)$ where $i\in\{0,1\}$ is randomly chosen (and not a priori known to $\mathcal{M}$), $c_{1}=ab$, and $c_{0}$ is a random scalar, and outputs $i$ with probability
and note that at the last step when $i=\pi-1$, then $c_{i+1}$
is already determined, to maintain consistency with the random oracle
output.
Note that regardless of whether $\overline{x}$ is the actual private
key corresponding to $\overline{y},$ due to the fact that consistency
is maintained by the random oracles in subsequent calls, the above
signature verifies. If $\overline{x}$ is actually the private key-vector
of $\overline{y}$ , then there is no difference between SIMNIZKP
and an actual signature.
Finally, given a tuple $\left(G,aG,bG,c_{i}G\right)$ where $a,b$
are randomly selected scalars, with $c_{1}=ab$, $c_{0}$ a random
element, $i\in\left\{0,1\right\}$, $\mathcal{M}$ takes the following steps to solve the Decisional Diffie
Helman Problem with non-negligible probability.
$\mathcal{M}$ grabs
a random $\gamma\leftarrow H$ from the random oracle and takes a
private / public key-vector pair $\left(\overline{x},\overline{y}\right)$,
and then computes $s$ such that $a=s+\gamma x$. Now $\mathcal{M}$
performs SIMNIZKP with arbitrarily selected key-vectors $\left\{\overline{y_{i}}\right\}_{i=1,...,n}$
such that $\overline{y}=\overline{y}_{\pi},$$a\to a$, $c_{i}\to c$
some message $\mathfrak{m}$, and $\overline{x}\to\overline{x}$.
If it is the case that $i=1$, then $c=ab$, then
\[
log_{G}aG=log_{bG}cG=a
\]
and due to the fact that $\mathcal{A}$ is assumed to be able to
find $\pi$ with non-negligible probability, then there is a non-negligible
probability over $\frac{1}{2}$ that $\mathcal{A}$ returns $1$ (upon
which $\mathcal{M}$ returns $1$). If $i=0$, then $\mathcal{A}$
returns $1$ only with probability $\frac{1}{2}$, and so for some
non-negligible probability over $\frac{1}{2}$, $\mathcal{M}$ returns
the same value as $\mathcal{A}$, and thus solves the Decisional Diffie-Helman problem for randomly chosen scalars with non-negligible probability
over $\frac{1}{2}$, which is a contradiction.
\end{proof}
\section{Ring CT Demo Code}
In the repository at \cite{Snoe} I have created a simple demonstration of the Ring Confidential Transactions protocol utilizing the MLSAG signatures of section \ref{MLSAGsection} and the ASNL signatures of section \ref{AgSchnorr}:
\begin{verbatim}
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)
