\documentclass{llncs}

\pagestyle{plain}

\usepackage{amsmath,amssymb,amsfonts}
\usepackage{bookmark}
\setcounter{tocdepth}{3}

\newcommand{\G}{\mathbb{G}}
\newcommand{\F}{\mathbb{F}}
\newcommand{\hash}{\mathcal{H}}
\newcommand{\addr}{\operatorname{addr}}
\newcommand{\com}{\operatorname{Com}}
\newcommand{\dcom}{\operatorname{DCom}}

\begin{document}

\title{Lelantus Spark: Secure and Flexible Private Transactions}
\author{Aram Jivanyan\inst{1,2}\thanks{Corresponding author: \email{aram@firo.org}} \and Aaron Feickert\inst{3}}
\institute{Firo \and Yerevan State University \and Cypher Stack}
\maketitle

\begin{abstract}
    We propose a modification to the Lelantus private transaction protocol to provide recipient privacy, improved security, and additional usability features.
    Our decentralized anonymous payment (DAP) construction, Spark, enables non-interactive one-time addressing to hide recipient addresses in transactions.
    The modified address format permits flexibility in transaction visibility.
    Address owners can securely provide third parties with opt-in visibility into incoming transactions or all transactions associated to the address; this functionality allows for offloading chain scanning and balance computation without delegating spend authority.
    It is also possible to delegate expensive proving operations without compromising spend authority when generating transactions.
    Further, the design is compatible with straightforward linear multisignature operations to allow mutually non-trusting parties to cooperatively receive and generate transactions associated to a multisignature address.
    We prove that Spark satisfies formal DAP security properties of balance, non-malleability, and ledger indistinguishability.
\end{abstract}

\section{Introduction}

Distributed digital asset protocols have seen a wealth of research since the introduction of the Bitcoin transaction protocol, which enables transactions generating and consuming ledger-based outputs, and provides a limited but useful scripting capability.
However, Bitcoin-type protocols have numerous drawbacks relating to privacy: a transaction reveals source addresses and amounts, and subsequent spends reveal destination addresses.
Further, data and metadata associated with transactions, like script contents, can provide undesired fingerprinting of transactions.

More recent research has focused on mitigating or removing these limitations, while permitting existing useful functionality like multisignature operations or opt-in third-party transaction viewing.
Designs in privacy-focused cryptocurrencies like Beam, Firo, Grin, Monero, and Zcash take different approaches toward this goal, with a variety of different tradeoffs.
The RingCT-based protocol currently used in Monero, for example, practically permits limited sender anonymity due to the space and time scaling of its underlying signature scheme \cite{ringct,clsag}.
The Sprout and Sapling protocols supported by Zcash \cite{zcash} (and their currently-deployed related updates) require trusted parameter generation to bootstrap their circuit-based proving systems, and interact with transparent Bitcoin-style outputs in ways that can leak information \cite{zcash_sprout,zcash_sapling}.
The Mimblewimble-based construction used as the basis for Grin can leak graph information prior to a merging operation performed by miners \cite{mw}.
To mitigate Mimblewimble's linkability issue, Beam has designed and implemented into its system an adaption of Lelantus for use with the Mimblewimble protocol which enables obfuscation of the transaction graph \cite{LMW}.
The Lelantus protocol currently used in Firo does not provide recipient privacy; it supports only mints and signer-ambiguous spends of arbitrary amounts that interact with transparent Bitcoin-style outputs, which can leak information about recipient identity \cite{lelantus}.
Seraphis \cite{seraphis} is a transaction protocol framework of similar design being developed concurrently.

Here we introduce Spark, an iteration on the Lelantus protocol enabling trustless private transactions which supports sender, receiver and transaction amount privacy.
Transactions in Spark, like those in Lelantus and Monero, use specified sender anonymity sets composed of previously-generated shielded outputs.
A parallel proving system adapted from a construction by Groth and Bootle \textit{et al.} \cite{groth,bootle} (of independent interest and used in other modified forms in Lelantus\cite{lelantus} and Triptych \cite{triptych}) proves that a consumed output exists in the anonymity set; amounts are encrypted and hidden algebraically in Pedersen commitments, and a tag derived from a verifiable random function \cite{dodis,omniring} prevents consuming the same output multiple times, which in the context of a transaction protocol would constitute a double-spend attempt.

Spark transactions support efficient verification in batches, where range and spend proofs can take advantage of common proof elements and parameters to lower the marginal cost of verifying each proof in such a batch; when coupled with suitably-chosen sender anonymity sets, the verification time savings of batch verification can be significant.

Spark enables additional useful functionality.
The use of a modified Chaum-Pedersen discrete logarithm proof, which asserts spend authority and correct tag construction, enables efficient signing and multisignature operations similar to those of \cite{musig} where computationally-expensive proofs may be offloaded to more capable devices with limited trust requirements.
The protocol further adds two levels of opt-in visibility into transactions without delegating spend authority.
Incoming view keys allow a designated third party to identify transactions containing outputs destined for an address, as well as the corresponding amounts and encrypted memo data.
Full view keys allow a designated third party to additionally identify when received outputs are later spent (but without any recipient data), which enables balance auditing and further enhances accountability in threshold multisignature applications where this property is desired.

All constructions used in Spark require only public parameter generation, ensuring that no trusted parties are required to bootstrap the protocol or ensure soundness.

\section {Cryptographic Preliminaries}

Throughout this paper, we use additive notation for group operations.
Let $\mathbb{N}$ be the set $\{0,1,2,\ldots\}$ of non-negative integers.

\subsection{Pedersen Commitment Scheme}

A homomorphic commitment scheme is a construction producing one-way algebraic representations of input values.
The Pedersen commitment scheme is a homomorphic commitment scheme that uses a particularly simple linear combination construction.
Let $pp_{\text{com}} = (\G, \F, G, H)$ be the public parameters for a Pedersen commitment scheme, where $\G$ is a prime-order group where the discrete logarithm problem is hard, $\F$ is its scalar field, and $G,H \in \G$ are uniformly-sampled independent generators.
The commitment scheme contains an algorithm $\com: \F^2 \to \G$, where $\com(v,r) = vG + rH$ that is homomorphic in the sense that $$\com(v_1,r_1) + \com(v_2,r_2) = \com(v_1 + v_2,r_1 + r_1)$$ for all such input values $v_1,v_2 \in \F$ and masks $r_1,r_2 \in \F$.
Further, the construction is perfectly hiding and computationally binding.

This definition extends naturally to a double-masked commitment scheme.
Let $pp_{\text{dcom}} = (\G, \F, F, G, H)$ be the public parameters for a double-masked Pedersen commitment scheme, where $\G$ is a prime-order group where the discrete logarithm problem is hard, $\F$ is its scalar field, and $F,G,H \in \G$ are uniformly-sampled independent generators.
The commitment scheme contains an algorithm $\dcom: \F^3 \to \G$, where $\dcom(v,r,s) = vF + rG + sH$ that is homomorphic in the sense that $$\dcom(v_1,r_1,s_1) + \dcom(v_2,r_2,s_2) = \dcom(v_1 + v_2,r_1 + r_2,s_1 + s_2)$$ for all such input values $v_1,v_2 \in \F$ and masks $r_1,r_2,s_1,s_2 \in \F$.
Further, the construction is perfectly hiding and computationally binding.

\subsection{Representation proving system}

A representation proof is used to demonstrate knowledge of a discrete logarithm in zero knowledge.
Let $pp_{\text{rep}} = (\G, \F)$ be the public parameters for such a construction, where $\G$ is a prime-order group where the discrete logarithm problems is hard and $\F$ is its scalar field.

The proving system itself is a tuple of algorithms $(\text{RepProve},\text{RepVerify})$ for the following relation:
$$\left\{ pp_{\text{rep}}, G, X \in \G ; x \in \F : X = xG \right\}$$

The well-known Schnorr proving system may be used for this purpose.

\subsection{Modified Chaum-Pedersen Proving System}

A Chaum-Pedersen proof is used to demonstrate discrete logarithm equality in zero knowledge.
Here we require a modification to the standard proving system that uses additional group generators.
Let $pp_{\text{chaum}} = (\G, \F, F, G, H, U)$ be the public parameters for such a construction, where $\G$ is a prime-order group where the discrete logarithm problem is hard, $\F$ is its scalar field, and $F,G,H,U \in \G$ are uniformly-sampled independent generators.

The proving system is a tuple of algorithms $(\text{ChaumProve},\text{ChaumVerify})$ for the following relation:
$$\left\{ pp_{\text{chaum}}, S, T \in \G ; (x, y, z) \in \F : S = xF + yG + zH, U = xT + yG \right\}$$

We present an instantiation of such a proving system in Appendix \ref{app:chaum}, along with security proofs.

\subsection{Parallel One-out-of-Many Proving System}

We require the use of a parallel one-out-of-many proving system that shows knowledge of openings of commitments to zero at the same index among two sets of group elements in zero knowledge.
In the context of the Spark protocol, this will be used to mask consumed coin serial number and value commitments for balance, ownership, and double-spend purposes.
We show how to produce such a proving system as a straightforward modification of a construction by Groth and Kohlweiss \cite{groth} that was generalized by Bootle \textit{et al.} \cite{bootle}.

Let $pp_{\text{par}} = (\G, \F, n, m, pp_{\text{com}})$ be the public parameters for such a construction, where $\G$ is a prime-order group where the discrete logarithm problem is hard, $\F$ is its scalar field, $n > 1$ and $m > 1$ are integer-valued size decomposition parameters, and $pp_{\text{com}}$ are the public parameters for a Pedersen commitment (and matrix commitment) construction.

The proving system itself is a tuple of algorithms $(\text{ParProve},\text{ParVerify})$ for the following relation, where we let $N = n^m$:
\begin{multline*}
\left\{ pp_{\text{par}}, \{S_i,V_i\}_{i=0}^{N-1} \subset \G^2 ; l \in \mathbb{N}, (s,v) \in \F : \right. \\
\left. 0 \leq l < N, S_l = \com(0,s), V_l = \com(0,v) \right\}
\end{multline*}

We present an instantiation of such a proving system in Appendix \ref{app:parallel}.

\subsection{Authenticated Encryption Scheme}

We require the use of an authenticated symmetric encryption with associated data (AEAD) scheme.
In the context of the Spark protocol, this construction is used to encrypt value and arbitrary memo data for use by the sender and recipient of a transaction.

Let $pp_{\text{sym}}$ be the public parameters for such a construction.
The construction itself is a tuple of algorithms $(\text{AEADKeyGen},\text{AEADEncrypt},\text{AEADDecrypt})$.
Here $\text{AEADKeyGen}$ is a key derivation function that accepts as input an arbitrary string, and produces a key in the appropriate key space.
The algorithm $\text{AEADEncrypt}$ accepts as input a key, associated data, and arbitrary message string, and produces ciphertext in the appropriate space.
The algorithm $\text{AEADDecrypt}$ accepts as input a key, associated data, and ciphertext string, and produces a message in the appropriate space if authentication succeeds.
For the purposes of this protocol, we may assume the use of a fixed nonce, as keys are used uniquely with given associated data.

Assume that such a construction is indistinguishable against chosen-plaintext attack (IND-CPA), indistinguishable against adaptive chosen-ciphertext attack (IND-CCA2), and key-private under chosen-ciphertext attacks (IK-CCA) in this context.

\subsection{Range Proving System}

We require the use of a zero-knowledge range proving system.
A range proving system demonstrates that a commitment binds to a value within a specified range.
In the context of the Spark protocol, it avoids overflow that would otherwise fool the balance definition by effectively binding to invalid negative values.
Let $pp_{\text{rp}} = (\G, \F, v_{\text{max}}, pp_{\text{com}})$ be the relevant public parameters for such a construction, where $pp_{\text{com}}$ are the public parameters for a Pedersen commitment construction.

The proving system itself is a tuple of algorithms $(\text{RangeProve},\text{RangeVerify})$ for the following relation:
$$\left\{ pp_{\text{rp}}, C \in \G ; (v, r) \in \F : 0 \leq v \leq v_{\text{max}}, C = \com(v,r) \right\}$$

In practice, an efficient instantiation like Bulletproofs \cite{bp} or Bulletproofs+ \cite{bp_plus} may be used to satisfy this requirement.

\section{Concepts and Algorithms}

We now define the main concepts and algorithms used in the Spark transaction protocol.

\textbf{Addresses}. Users generate addresses that enable transactions.
An address consists of a tuple $$(\addr_{\text{pk}}, \addr_{\text{in}}, \addr_{\text{full}}, \addr_{\text{sk}}).$$
For each address, $\addr_{\text{pk}}$ is the public address used for receiving funds, $\addr_{\text{in}}$ is an incoming view key used to identify received funds, $\addr_{\text{full}}$ is a full view key used to identify outgoing funds and conduct computationally-heavy proving operations, and $\addr_{\text{sk}}$ is the spend key used to generate transactions.

\textbf{Coins.} A coin encodes the abstract value which is transferred through the private transactions. Each coin is associated with:
\begin{itemize}
\item A (secret) serial number that uniquely defines the coin.
\item A serial number commitment.
\item An integer value for the coin.
\item An encrypted value intended for decryption by the recipient.
\item A value commitment.
\item A range proof for the value commitment, or a proof that a plaintext value is represented by the value commitment.
\item A memo with arbitrary recipient data.
\item An encrypted memo intended for decryption by the recipient.
\item A recovery key used by the recipient to identify the coin and decrypt private data.
\end{itemize}
Coins additionally bind recipient addresses in an indistinguishable way; this may be useful for out-of-band payment proofs that require such binding.

\textbf{Private Transactions}. There are two types of private transactions in Spark:
\begin{itemize}
    \item $Mint$ transactions.
    A $Mint$ transaction generates new coins of public value destined for a recipient public address in a confidential way, either through a consensus-enforced mining process, or by consuming transparent outputs from a non-Spark base layer.
    In this transaction type, a representation proof is included to show that the minted coin is of the expected value.
    A $Mint$ transaction creates transaction data $\text{tx}_{\text{mint}}$ for recording on a ledger.
    \item $Spend$ transactions.
    A $Spend$ transaction consumes existing coins and generates new coins destined for one or more recipient public addresses in a confidential way.
    In this transaction type, a representation proof is included to show that the hidden input and output values are equal.
    A $Spend$ transaction creates transaction data $\text{tx}_{\text{spend}}$ for recording on a ledger.
\end{itemize}

\textbf{Tags.} Tags are used to prevent coins from being consumed in multiple transactions.
When generating a $Spend$ transaction, the sender produces the tag for each consumed coin and includes it on the ledger.
When verifying transactions are valid, it suffices to ensure that tags do not appear on the ledger in any previous transactions.
Tags are bound to validly-recoverable coins uniquely via the serial number commitment secret data, but cannot be associated to specific coins without the corresponding full view key.

\textbf{Algorithms}. Spark is a decentralized anonymous payment (DAP) system defined as the following polynomial-time algorithms:
\begin{itemize}
\item \textbf{Setup}: This algorithm outputs all public parameters used by the protocol and its underlying components.
The setup process does not require any trusted parameter generation.
\item \textbf{CreateAddress}: This algorithm outputs a public address, incoming view key, full view key, and spend key.
\item \textbf{CreateCoin}: This algorithm takes as input a public address, coin value, and memo, and outputs a coin destined for the public address.
\item \textbf{Mint:} This algorithm takes as input a public address, value, and (optionally) implementation-specific data relating to base-layer outputs, and outputs a mint transaction $\text{tx}_{\text{mint}}$.
\item \textbf{Identify:} This algorithm takes as input a coin and an incoming view key, and outputs the coin value and memo.
\item \textbf{Recover:} This algorithm takes as input a coin and a full view key, and outputs the coin value, memo, serial number, and tag.
\item \textbf{Spend:} This algorithm takes as input a full view key, a spend key, a set of input coins (including coins used as a larger ambiguity set), the indexes of coins to be spent, the corresponding serial numbers and values, a fee value, and a set of output coins to be generated, and outputs a spend transaction $\text{tx}_{\text{spend}}$.
\item \textbf{Verify:} This algorithm accepts either a mint transaction or a spend transaction, and outputs a bit to assess validity.
\end{itemize}

We provide detailed descriptions below, and show security of the resulting protocol in the appendixes.

\section{Algorithm Constructions}

In this section we provide detailed description of the DAP scheme algorithms.

\subsection{Setup}

In our setup the public parameters $pp$ are comprised of the corresponding public parameters of a Pedersen commitment (and matrix commitment) scheme, representation proving system, modified Chaum-Pedersen proving system, parallel one-out-of-many proving system, symmetric encryption scheme, and range proving system.

\textbf{Inputs:} Security parameter $\lambda$, size decomposition parameters $n > 1$ and $m > 1$, maximum value parameter $v_{\text{max}}$

\textbf{Outputs:} Public parameters $pp$

\begin{enumerate}
\item Sample a prime-order group $\G$ in which the discrete logarithm, decisional Diffie-Hellman, and computational Diffie-Hellman problems are hard.
Let $\F$ be the scalar field of $\G$.
\item Sample $F,G,H,U \in \G$ uniformly at random.
In practice, these generators may be chosen using a suitable cryptographic hash function on public input.
\item Sample cryptographic hash functions $$\hash_{\text{ser}},\hash_{\text{val}},\hash_{\text{ser}'},\hash_{\text{val}'},\hash_{\text{bind}}: \{0,1\}^* \to \F$$ uniformly at random.
In practice, these hash functions may be chosen using domain separation of a single suitable cryptographic hash function.
\item Compute the public parameters $pp_{\text{com}} = (\G,\F,G,H)$ of a Pedersen commitment scheme.
\item Compute the public parameters $pp_{\text{dcom}} = (\G,\F,F,G,H)$ of a double-masked Pedersen commitment scheme.
\item Compute the public parameters $pp_{\text{rep}} = (\G,\F)$ of a representation proving system.
\item Compute the public parameters $pp_{\text{chaum}} = (\G,\F,F,G,H,U)$ of the modified Chaum-Pedersen proving system.
\item Compute the public parameters $pp_{\text{par}} = (\G,\F,n,m,pp_{\text{com}})$ of the parallel one-out-of-many proving system.
\item Compute the public parameters $pp_{\text{sym}}$ of an authenticated symmetric encryption scheme.
\item Compute the public parameters $pp_{\text{rp}} = (\G,\F,v_{\text{max}},pp_{\text{com}})$ of a range proving system.
\item Output all generated public parameters and hash functions as $pp$.
\end{enumerate}

\subsection{CreateAddress}

We describe the construction of all addresses and underlying key types used in the protocol.

\textbf{Inputs:} Security parameter $\lambda$, public parameters $pp$

\textbf{Outputs:} Address key tuple $(\addr_{\text{pk}}, \addr_{\text{in}}, \addr_{\text{full}}, \addr_{sk})$

\begin{enumerate}
\item Sample $s_1, s_2, r \in \F$ uniformly at random, and let $D = \dcom(0, r, 0)$.
\item Compute $Q_1 = \dcom(s_1, 0, 0)$ and $Q_2 = \dcom(s_2, r, 0)$.
\item Set $\addr_{\text{pk}} = (Q_1, Q_2)$.
\item Set $\addr_{\text{in}} = s_1$.
\item Set $\addr_{\text{full}} = (s_1, s_2, D)$.
\item Set $\addr_{\text{sk}} = (s_1, s_2, r)$.
\item Output the tuple $(\addr_{\text{pk}}, \addr_{\text{in}}, \addr_{\text{full}}, \addr_{sk})$.
\end{enumerate}

\subsection{CreateCoin}

This algorithm generates a new coin destined for a given public address.
Note that while this algorithm generates a serial number commitment, it cannot compute the underlying serial number.

\textbf{Inputs:} Security parameter $\lambda$, public parameters $pp$, destination public address $\addr_{\text{pk}}$, value $v \in [0, v_{\text{max}})$, memo $m$, type bit $b$

\textbf{Outputs:} Coin public key $S$, recovery key $K$, value commitment $C$, value commitment range proof $\Pi_{\text{rp}}$ (if $b=0$), encrypted value $\overline{v}$ (if $b=0$) or value $v$ (if $b=1$), encrypted memo $\overline{m}$

\begin{enumerate}
\item Parse the recipient address $\addr_{\text{pk}} = (Q_1, Q_2)$.
\item Sample $k \in \F$.
\item Compute the recovery key $K = \dcom(k, 0, 0)$.
\item Compute the serial number commitment $$S = \dcom(\hash_{\text{ser}}(kQ_1,Q_1,Q_2), 0, 0) + Q_2.$$
\item Generate the value commitment $C = \com(v, \hash_{\text{val}}(kQ_1))$.
\item If $b=0$, generate a range proof $$\Pi_{\text{rp}} = \text{RangeProve}(pp_{\text{rp}},C;(v,\hash_{\text{val}}(kQ_1))).$$
\item Generate a symmetric encryption key $k_{\text{aead}} = \text{AEADKeyGen}(kQ_1)$; encrypt the value $\overline{v} = \text{AEADEncrypt}(k_{\text{aead}},\texttt{val},v)$ (if $b=0$) and memo $\overline{m} = \text{AEADEncrypt}(k_{\text{aead}},\texttt{memo},m)$.
\item If $b=0$, output the tuple $(S, K, C, \Pi_{\text{rp}}, \overline{v}, \overline{m})$.
Otherwise, output the tuple $(S, K, C, v, \overline{m})$.
\end{enumerate}
The case $b=0$ represents a coin with hidden value being generated in a $\text{Spend}$ transaction, while the case $b=0$ represents a coin with plaintext value being generated in a $\text{Mint}$ transaction.
Note that it is possible to securely aggregate range proofs within a transaction; this does not affect protocol security.

\subsection{Mint}

This algorithm generates new coins from either a consensus-determined mining process, or by consuming non-Spark outputs from a base layer with public value.
Note that while such implementation-specific auxiliary data may be necessary for generating such a transaction and included, we do not specifically list this here.
Notably, the coin value used in this algorithm is assumed to be the sum of all public input values as specified by the implementation.

\textbf{Inputs}: Security parameter $\lambda$, public parameters $pp$, destination public address $\addr_{\text{pk}}$, coin value $v \in [0, v_{\text{max}})$, memo $m$

\textbf{Outputs}: Mint transaction $\text{tx}_{\text{mint}}$

\begin{enumerate}
\item Generate the new coin $\text{CreateCoin}(\addr_{\text{pk}}, v, m, 1) \to \text{Coin} = (S, K, C, v, \overline{m})$.
\item Generate a value representation proof on the value commitment: $$\Pi_{\text{bal}} = \text{RepProve}(pp_{\text{rep}},H,C - \com(v,0); \hash_{\text{val}}(kQ_1))$$
\item Output the tuple $\text{tx}_{\text{mint}} = (\text{Coin}, \Pi_{\text{bal}})$.
\end{enumerate}

\subsection{Identify}

This algorithm allows a recipient (or designated entity) to compute the value and memo from a coin destined for its public address.
It requires the incoming view key corresponding to the public address to do so.
If the coin is not destined for the public address, the algorithm returns failure.

\textbf{Inputs:} Security parameter $\lambda$, public parameters $pp$, incoming view key $\addr_{\text{in}}$, public address $\addr_{\text{pk}}$, coin $\text{Coin}$.

\textbf{Outputs:} Value $v$, memo $m$

\begin{enumerate}
\item Parse the incoming view key $\addr_{\text{in}} = s_1$ and public address $\addr_{\text{pk}} = (Q_1, Q_2)$.
\item Parse the serial number commitment $S$, value commitment $C$, recovery key $K$, encrypted value $\overline{v}$ (if the coin is of type $b=0$) or value $v$ (if the coin is of type $b=1$), and encrypted memo $\overline{m}$ from $\text{Coin}$.
\item If $\dcom(\hash_{\text{ser}}(s_1 K,Q_1,Q_2), 0, 0) + Q_2 \neq S$, return failure.
\item Generate a symmetric encryption key $k_{\text{aead}} = \text{AEADKeyGen}(s_1 K)$; decrypt the value $v = \text{AEADDecrypt}(k_{\text{aead}},\texttt{val},\overline{v})$ (if $b=0$) and memo $m = \text{AEADDecrypt}(k_{\text{aead}},\texttt{memo},\overline{m})$.
\item If $\com(v,\hash_{\text{val}}(s_1 K)) \neq C$, return failure.
\item Output the tuple $(v, m)$.
\end{enumerate}

\subsection{Recover}

This algorithm allows a recipient (or designated entity) to compute the serial number, tag, value, and memo from a coin destined for its public address.
It requires the full view key corresponding to the public address to do so.
If the coin is not destined for the public address, the algorithm returns failure.

\textbf{Inputs:} Security parameter $\lambda$, public parameters $pp$, full view key $\addr_{\text{full}}$, public address $\addr_{\text{pk}}$, coin $\text{Coin}$.

\textbf{Outputs:} Coin serial number $s$, tag $T$, value $v$, memo $m$

\begin{enumerate}
\item Parse the full view key as $\addr_{\text{full}} = (s_1, s_2, D)$ and public address $\addr_{\text{pk}} = (Q_1, Q_2)$.
\item Parse the serial number commitment $S$, value commitment $C$, recovery key $K$, encrypted value $\overline{v}$ (if the coin is of type $b=0$) or value $v$ (if the coin is of type $b=1$), and encrypted memo $\overline{m}$ from $\text{Coin}$.
\item If $\dcom(\hash_{\text{ser}}(s_1 K,Q_1,Q_2), 0, 0) + Q_2 \neq S$, return failure.
\item Generate a symmetric encryption key $k_{\text{aead}} = \text{AEADKeyGen}(s_1 K)$; decrypt the value $v = \text{AEADDecrypt}(k_{\text{aead}},\texttt{val},\overline{v})$ (if $b=1$) and memo $m = \text{AEADDecrypt}(k_{\text{aead}},\texttt{memo},\overline{m})$.
\item If $\com(v,\hash_{\text{val}}(s_1 K)) \neq C$, return failure.
\item Compute the serial number $$s = \hash_{\text{ser}}(s_1 K,Q_1,Q_2) + s_2$$ and tag $$T = (1/s)(U - D).$$
\item If $T$ has been constructed in any other valid recovery, return failure.
\item Output the tuple $(s, T, v, m)$.
\end{enumerate}

\subsection{Spend}

This algorithm allows a recipient to generate a transaction that consumes coins destined to its public address, and generates new coins destined for arbitrary public addresses.
The process is designed to be modular; in particular, only the full view key is required to generate the parallel one-out-of-many proof, which may be computationally expensive.
The use of spend keys is only required for the final Chaum-Pedersen proof step, which is of lower complexity.

It is assumed that the recipient has run the $\text{Recover}$ algorithm on all coins that it wishes to consume in such a transaction.

\textbf{Inputs:}
\begin{itemize}
    \item Security parameter $\lambda$ and public parameters $pp$
    \item A full view key $\addr_{\text{full}}$
    \item A spend key $\addr_{\text{sk}}$
    \item A set of $N$ input coins $\text{InCoins}$ as part of a cover set
    \item For each $u \in [0,w)$ coin to spend, the index in $\text{InCoins}$, serial number, tag, value, and recovery key: $(l_u, s_u, T_u, v_u, K_u)$
    \item An integer fee value $f \in [0,v_{\text{max}})$
    \item A set of $t$ output coin public addresses, values, and memos: $$\{\addr_{\text{pk},j}, v_j, m_j\}_{j=0}^{t-1}$$
\end{itemize}

\textbf{Outputs:} Spend transaction $\text{tx}_{\text{spend}}$

\begin{enumerate}
    \item Parse the required full view key component as $\addr_{\text{full}} = D$.
    \item Parse the spend key $\addr_{\text{sk}} = (s_1, s_2, r)$.
    \item Parse the cover set serial number commitments and value commitments as $\text{InCoins} = \{(S_i, C_i)\}_{i=0}^{N-1}$.
    \item For each $u \in [0,w)$:
    \begin{enumerate}
        \item Compute the serial number commitment offset: $$S_u' = \dcom(s_u, 0, -\hash_{\text{ser}'}(s_u, D)) + D$$
        \item Compute the value commitment offset: $$C_u' = \com(v_u, \hash_{\text{val}'}(s_u, D))$$
        \item Generate a parallel one-out-of-many proof:
        \begin{multline*}
        (\Pi_{\text{par}})_u = \text{ParProve}(pp_{\text{par}},\{S_i - S_u', C_i - C_u'\}_{i=0}^{N-1}; \\
        (l_u, \hash_{\text{ser}'}(s_u, D), \hash_{\text{val}}(s_1 K_u) - \hash_{\text{val}'}(s_u, D)))
        \end{multline*}
    \end{enumerate}
    \item Generate a set $\text{OutCoins} = \{\text{CreateCoin}(\addr_{\text{pk},j}, v_j, m_j, 0)\}_{j=0}^{t-1}$ of output coins.
    \item Parse the output coin value commitments as $\text{OutCoins} = \{\overline{C}_j\}_{j=0}^{t-1}$, where each $\overline{C}_j$ contains a recovery key preimage $k_j$ and destination address component $(Q_1)_j$.
    \item Generate a representation proof for balance assertion:
    \begin{multline*}
    \Pi_{\text{bal}} = \text{RepProve}\left( pp_{\text{rep}}, H, \sum_{u=0}^{w-1} C_u' - \sum_{j=0}^{t-1} \overline{C}_j - \com(f,0); \right. \\
    \left. \sum_{u=0}^{w-1} \hash_{\text{val}'}(s_u,D) - \sum_{j=0}^{t-1} \hash_{\text{val}}(k_j(Q_1)_j) \right)
    \end{multline*}
    \item Let $\mu = \hash_{\text{bind}}( \text{InCoins}, \text{OutCoins}, f, \left\{ S_u', C_u', T_u, (\Pi_{\text{par}})_u, \right\}_{u=0}^{w-1}, \Pi_{\text{bal}} )$.
    \item For each $u \in [0,w)$, generate a modified Chaum-Pedersen proof, where we additionally bind $\mu$ to the initial transcript: $$(\Pi_{\text{chaum}})_u = \text{ChaumProve}(pp_{\text{chaum}},S_u', T_u; (s_u, r, -\hash_{\text{ser}'}(s_u, D)))$$
    \item Output the tuple:
    \begin{multline*}
    \text{tx}_{\text{spend}} = ( \text{InCoins}, \text{OutCoins}, f, \\
    \left\{ S_u', C_u', T_u, (\Pi_{\text{par}})_u, (\Pi_{\text{chaum}})_u \right\}_{u=0}^{w-1}, \Pi_{\text{bal}} )
    \end{multline*}
\end{enumerate}

\begin{remark}
We note that it is possible to modify the balance proof to account for other input or output values not represented by coin value commitments, similarly to the handling of fees.
This observation can allow for the transfer of value into new coins without the use of a $\text{Mint}$ transaction, or a transfer of value to a transparent base layer.
Such transfer functionality is likely to introduce practical risk that is not captured by the protocol security model, and warrants thorough analysis.
\end{remark}

\subsection{Verify}

This algorithm assesses the validity of a transaction.

\textbf{Inputs:} either a mint transaction $\text{tx}_{\text{mint}}$ or a spend transaction $\text{tx}_{\text{spend}}$

\textbf{Outputs:} a bit that represents the validity of the transaction

If the input transaction is a mint transaction:
\begin{enumerate}
    \item Parse the transaction $\text{tx}_{\text{mint}} = (\text{Coin}, \Pi_{\text{bal}})$.
    \item Parse the coin value and value commitment as $\text{Coin} = (v, C)$.
    \item Check that $v \in [0,v_{\text{max}})$, and output 0 if this fails.
    \item Check that $\text{RepVerify}(pp_{\text{rep}},\Pi_{\text{bal}},H,C - \com(v,0))$, and output 0 if this fails.
    \item Output 1.
\end{enumerate}

If the input transaction is a spend transaction:
\begin{enumerate}
    \item Parse the transaction:
    \begin{multline*}
    \text{tx}_{\text{spend}} = ( \text{InCoins}, \text{OutCoins}, f, \\
    \left\{ S_u', C_u', T_u, (\Pi_{\text{par}})_u, (\Pi_{\text{chaum}})_u \right\}_{u=0}^{w-1}, \Pi_{\text{bal}} )
    \end{multline*}
    \item Parse the cover set serial number commitments and value commitments as $\text{InCoins} = \{(S_i, C_i)\}_{i=0}^{N-1}$.
    \item Parse the output coin value commitments and range proofs as $\text{OutCoins} = \{ \overline{C}_j, (\Pi_{\text{rp}})_j \}_{j=0}^{t-1}$.
    \item For each $u \in [0,w):$
    \begin{enumerate}
        \item Check that $T_u$ does not appear again in this transaction or in any previously-verified transaction, and output 0 if it does.
        \item Check that $\text{ParVerify}(pp_{\text{par}},(\Pi_{\text{par}})_u,\{S_i - S_u',C_i - C_u'\}_{i=0}^{N-1})$, and output 0 if this fails.
        \item Check that $\text{ChaumVerify}(pp_{\text{chaum}},(\Pi_{\text{chaum}})_u,S_u',T_u)$, and output 0 if this fails.
    \end{enumerate}
    \item For each $j \in [0,t):$
    \begin{enumerate}
        \item Check that $\text{RangeVerify}(pp_{\text{rp}},(\Pi_{\text{rp}})_j,C)$, and output 0 if this fails.
    \end{enumerate}
    \item Check that $f \in [0,v_{\text{max}})$, and output 0 if this fails.
    \item Check that $$\text{RepVerify}\left( pp_{\text{rep}}, \Pi_{\text{bal}}, H, \sum_{u=0}^{w-1} C_u' - \sum_{j=0}^{t-1} \overline{C}_j - \com(f,0) \right)$$ and output 0 if this fails.
    \item Output 1.
\end{enumerate}

\section{Multisignature Operations}

Spark addresses and transactions support efficient and secure multisignature operations, where a group of signers are required to authorize transactions.
We describe a method for signing groups to perform the $\text{CreateAddress}$ and $\text{Spend}$ algorithms to produce multisignature addresses and spend transactions indistinguishable from others.

Throughout this section, suppose we have a group of $\nu$ signers who wish to collaboratively produce an address or transaction.
Further, sample a cryptographic hash function $\hash_{\text{agg}}: \{0,1\}^* \to \F$ uniformly at random.

\subsection{CreateAddress}

\begin{enumerate}
\item Each player $\alpha \in [0,\nu)$ chooses $s_{1,\alpha}, s_{2,\alpha}, r_\alpha \in \F$ uniformly at random, and sets $D_\alpha = \dcom(0, r_\alpha, 0)$.
It sends the the values $s_{1,\alpha}, s_{2,\alpha}, D_\alpha$ to all players.
\item All players compute the aggregate incoming view key and full view key components:
\begin{align*}
s_1 &= \sum_{\alpha=0}^{\nu-1} \hash_{\text{agg}}\left( \{s_{1,\beta}\}_{\beta=0}^{\nu-1}, \alpha \right) s_{1,\alpha} \\
s_2 &= \sum_{\alpha=0}^{\nu-1} \hash_{\text{agg}}\left( \{s_{2,\beta}\}_{\beta=0}^{\nu-1}, \alpha \right) s_{2,\alpha} \\
D &= \sum_{\alpha=0}^{\nu-1} \hash_{\text{agg}}\left( \{D_\beta\}_{\beta=0}^{\nu-1}, \alpha \right) D_\alpha
\end{align*}
\item All players compute the aggregate public address components:
\begin{align*}
Q_1 &= \dcom(s_1, 0, 0) \\
Q_2 &= \dcom(s_2, 0, 0) + D
\end{align*}

Note that each player $\alpha$ keeps its spend key share $r_\alpha$ private.
\end{enumerate}

\subsection{Spend}

Because all players possess the aggregate full view key corresponding to the aggregate public address, any player can use it to construct all transaction components except modified Chaum-Pedersen proofs.
We describe now how the signers collaboratively produce such a proof to authorize the spending of a coin, with the following proof inputs (using our previous notation):
$$\{pp_{\text{chaum}}, S_u', T_u; (s_u, r, -\hash_{\text{ser}'}(s_u, D))\}$$

\begin{enumerate}
\item Each player $\alpha \in [0,\nu)$ chooses $\overline{r}_\alpha, \overline{s}_\alpha, \overline{t}_\alpha \in \F$ uniformly at random.
It generates a commitment to the tuple $(\overline{r}_\alpha, \overline{s}_\alpha G, \overline{t}_\alpha)$ and sends it to all players.
\item Each player reveals its commitment opening to all players, verifies all players' openings, and aborts if any are invalid.
\item All players compute the initial proof terms:
\begin{align*}
A_1 &= \left( \sum_{\beta=0}^{\nu-1} \overline{r}_\beta \right) F + \sum_{\beta=0}^{\nu-1} (\overline{s}_\alpha G) \\
A_2 &= \left( \sum_{\beta=0}^{\nu-1} \overline{r}_\beta \right) T_u + \sum_{\beta=0}^{\nu-1} (\overline{s}_\alpha G) \\
A_3 &= \left( \sum_{\beta=0}^{\nu-1} \overline{t}_\beta \right) H
\end{align*}
They compute the challenge $c$ from the initial proof transcript.
\item Each player $\alpha \in [0,\nu)$ computes the following:
\begin{align*}
t_1 &= \sum_{\beta=0}^{\nu-1} \overline{r}_\beta + cs_u \\
t_{2,\alpha} &= \overline{s}_\alpha + c\hash_{\text{agg}}\left( \{D_\beta\}_{\beta=0}^{\nu-1}, \alpha \right) r_\alpha \\
t_3 &= \sum_{\beta=0}^{\nu-1} \overline{t}_\beta - c\hash_{\text{ser}'}(s_u, D)
\end{align*}
It sends $t_{2,\alpha}$ to all players.
\item All players compute the final proof term: $$t_2 = \sum_{\beta=0}^{\nu-1} t_{2,\beta}$$
\end{enumerate}

\section{Applications of Key Structures}

The key structure in Spark permits flexible and useful functionality relating to transaction scanning and generation.

The incoming view key is used in $\text{Identify}$ operations to determine when a coin is directed to the associated public address, and to determine the coin's value and associated memo data.
This permits two use cases of note.
In one case, blockchain scanning can be delegated to a device or service without delegating spend authority for identified coins.
In another case, wallet software in possession of a spend key can keep this key encrypted or otherwise securely stored during scanning operations, reducing key exposure risks.

The full view key is used in $\text{Recover}$ operations to additionally compute the serial number and tag for coins directed to the associated public address.
These tags can be used to identify a transaction spending the coin.
Providing this key to a third party permits identification of incoming transactions and detection of outgoing transactions, which additionally provides balance computation, without delegating spend authority.
Users like public charities may wish to permit public oversight of funds with this functionality.
Other users may wish to provide this functionality to an auditor or accountant for bookkeeping purposes.
In the case where a public address is used in threshold multisignature operations, a cosigner may wish to know if or when another cohort of cosigners has produced a transaction spending funds from its address.

Further, the full view key is used in $\text{Spend}$ to generate one-out-of-many proofs.
Since the parallel one-out-of-many proof used in Spark can be computationally expensive, it may be unsuitable for generation by a computationally-limited device like a hardware wallet.
Providing this key to a more powerful device enables easy generation of this proof (and other transaction components like range proofs), while ensuring that only the device holding the spend key can complete the transaction by generating the simple modified Chaum-Pedersen proofs.

\section{Efficiency}

It is instructive to examine the efficiency of $\text{Spend}$ transactions in size, generation complexity, and verification complexity.
In addition to our previous notation for parameters, let $v_{\text{max}} = 2^{64}$, so coin values and fees can be represented by $8$-byte unsigned integers.
Further, suppose coin memos are fixed at $M$ bytes in length, with a $16$-byte authentication tag; this is the case for the ChaCha20-Poly1305 authenticated symmetric encryption construction, for example \cite{chachapoly}.
Transaction size data for specific component instantiations is given in Table \ref{table:size}, where we consider the size in terms of group elements, field elements, and other data.
Note that we do not include input ambiguity set references in this data, as this depends on implementation-specific selection and representation criteria.

\begin{table}
    \caption{$\text{Spend}$ transaction size by component}
    \label{table:size}
    \centering
    \begin{tabular}{|l|l|r|r|r|}
        \hline
        \textbf{Component} & \textbf{Instantiation} & \textbf{Size ($\G$)} & \textbf{Size ($\F$)} & \textbf{Size (bytes)} \\
        \hline
        $f$ & & & & $8$ \\
        $\Pi_{\text{rp}}$ & Bulletproofs+ & $2 \lceil \lg(64t) \rceil + 3$ & $3$ & \\
        $\Pi_{\text{bal}}$ & Schnorr & & $2$ & \\
        \hline
        \multicolumn{5}{|c|}{Input data ($w$ coins)} \\
        \hline
        $(S',C')$ & & $2w$ & & \\
        $\Pi_{\text{par}}$ & this paper & $(2m + 4)w$ & $[m(n-1) + 4]w$ & \\
        $\Pi_{\text{chaum}}$ & this paper & $3w$ & $3w$ & \\
        \hline
        \multicolumn{5}{|c|}{Output data ($t$ coins)} \\
        \hline
        $(S,K,C)$ & & $3t$ & & \\
        $(\overline{v},\overline{m})$ & ChaCha20-Poly1305 & & & $(8 + M + 16)t$ \\
        \hline
    \end{tabular}
\end{table}

To evaluate the verification complexity of $\text{Spend}$ transactions using these components, we observe that verification in constructions like the parallel one-out-of-many proving system in this paper, Bulletproof+ range proving system, Schnorr representation proving system, and modified Chaum-Pedersen proving system in this paper all reduce to single linear combination evaluations in $\G$.
Because of this, proofs can be evaluated in batches if the verifier first weights each proof by a random value in $\F$, such that distinct group elements need only appear once in the resulting weighted linear combination.
Notably, techniques like that of \cite{pippenger} can be used to reduce the complexity of such evaluations by up to a logarithmic factor.
Suppose we wish to verify a batch of $B$ transactions, each of which spends $w$ coins and generates $t$ coins.
Table \ref{table:time} shows the verification batch complexity in terms of total distinct elements of $\G$ that must be included in a linear combination evaluation.

\begin{table}
    \caption{$\text{Spend}$ transaction batch verification complexity for $B$ transactions with $w$ spent coins and $t$ generated coins}
    \label{table:time}
    \centering
    \begin{tabular}{|l|r|}
        \hline
        \textbf{Component} & \textbf{Complexity} \\
        \hline
        Parallel one-out-of-many & $B[w(2m + 6) + 2m^m] + m^n + 1$ \\
        Bulletproofs+ & $B(t + 2\lg(64t) + 3) + 128T + 2$ \\
        Modified Chaum-Pedersen & $B(5w) + 4$ \\
        Schnorr & $B(w + t + 1) + 2$ \\
        \hline
    \end{tabular}
\end{table}

We further comment that the parallel one-out-of-many proving system presented in this paper may be further optimized in verification.
Because corresponding elements of the $\{S_i\}$ and $\{V_i\}$ input sets are weighted identically in the protocol verification equations, it may be more efficient (depending on implementation) to combine these elements with a sufficient weight prior to applying the proof-specific weighting identified above for batch verification.
Initial tests using a variable-time curve library suggest significant reductions in verification time with this technique.

\section*{Acknowledgments}

The authors thank pseudonymous collaborator \texttt{koe} for ongoing discussions during the development of this work.
The authors gratefully acknowledge Nikolas Kr\"{a}tzschmar for identifying an earlier protocol flaw relating to tag generation.

\bibliographystyle{splncs04}
\bibliography{main}

\appendix

\section{Modified Chaum-Pedersen Proving System}
\label{app:chaum}

The proving system is a tuple of algorithms $(\text{ChaumProve},\text{ChaumVerify})$ for the following relation:
$$\left\{ pp_{\text{chaum}}, S, T \in \G ; (x, y, z) \in \F : S = xF + yG + zH, U = xT + yG \right\}$$

The protocol proceeds as follows:
\begin{enumerate}
    \item The prover selects random $r,s,t \in \F$.
    It computes $$(A_1, A_2, A_3) := (rF + sG, rT + sG, tH)$$ and sends these values to the verifier.
    \item The verifier selects a random challenge $c \in \F$ and sends it to the prover.
    \item The prover computes responses $$(t_1, t_2, t_3) := (r + cx, s + cy, t + cz)$$ and sends these values to the verifier.
    \item The verifier accepts the proof if and only if $$A_1 + A_3 + cS = t_1 F + t_2 G + t_3 H$$ and $$A_2 + cU = t_1 T + t_2 G.$$
\end{enumerate}

We now prove that the protocol is complete, special sound, and special honest-verifier zero knowledge.

\begin{proof}
Completeness of this protocol follows trivially by inspection.

To show the protocol is special honest-verifier zero knowledge, we construct a valid simulator producing transcripts identically distributed to those of valid proofs.
The simulator chooses a random challenge $c \in \F$, random scalar values $t_1, t_2, t_3 \in \F$, and a random value $A_1 \in \G$.
It sets $A_2 := t_1 T + t_2 H - cU$ and $A_3 := t_1 F + t_2 G + t_3 H - cS - A_1$.
Such a transcript will be accepted by an honest verifier.
Observe that all transcript elements in a valid proof are independently distributed uniformly at random if the generators $F,G,H,U$ are independent, as are transcript elements produced by the simulator.

To show the protocol is special sound, consider two accepting transcripts with distinct challenge values $c \neq c' \in \F$:
$$(A_1, A_2, A_3, c, t_1, t_2, t_3)$$
and
$$(A_1, A_2, A_3, c', t'_1, t'_2, t'_3)$$
The first verification equation applied to the two transcripts implies that $$(c - c')S = (t_1 - t'_1)F + (t_2 - t'_2)G + (t_3 - t'_3)H,$$ so we extract the witness values $x := (t_1 - t'_1)/(c - c')$ and $y := (t_2 - t'_2)/(c - c')$ and $z := (t_3 - t'_3)/(c - c')$, or a nontrivial discrete logarithm relation between $F,G,H$ (a contradiction if these generators are independent).
Similarly, the second verification equation implies that $$(c - c')U = (t_1 - t'_1)T + (t_2 - t'_2)G,$$ yielding the same values for $x$ and $y$ as required.

This completes the proof.
\end{proof}

\section{Parallel One-out-of-Many Proving System}
\label{app:parallel}

The proving system itself is a tuple of algorithms $(\text{ParProve},\text{ParVerify})$ for the following relation, where we let $N = n^m$:
\begin{multline*}
\left\{ pp_{\text{par}}, \{S_i,V_i\}_{i=0}^{N-1} \subset \G^2 ; l \in \mathbb{N}, (s,v) \in \F : \right. \\
\left. 0 \leq l < N, S_l = \com(0,s), V_l = \com(0,v) \right\}
\end{multline*}

The protocol is shown in Figure \ref{fig:groth}, where we use the notation of \cite{lelantus}.

\begin{figure}
\centering
\begin{math}
\begin{array}{@{}l@{}c@{}l@{}}
\displaystyle \text{ParProve}\left(pp_{\text{par}}, \{S_i, V_i\}_{i=0}^{N-1}; (l,s,v)\right) && \text{ParVerify}\left(pp_{\text{par}}, \{S_i, V_i\}_{i=0}^{N-1}\right) \\\\
\text{Compute:} && \text{Accept if and only if:}\\
r_A, r_B, r_C, r_D, \{a_{j,i}\}_{j=0,i=1}^{m-1,n-1} \gets_R \F\\
\forall j \in [0,m) \\
\qquad a_{j,0} = -\sum _{i=1}^{n-1}a_{j,i}\\\\
A \equiv \com(\{a_{j,i}\}_{j,i=0}^{m-1,n-1}, r_A) \\
B \equiv \com(\{\sigma_{l_{j},i}\}_{j,i=0}^{m-1,n-1}, r_B) \\
C \equiv \\ \quad \com(\lbrace a_{j,i}(1-2\sigma_{l_j,i})\rbrace_{j,i=0}^{m-1,n-1}, r_C) \\
D \equiv \com(\{-a_{j,i}^2\}_{j,i=0}^{m-1,n-1}, r_D) \\\\
\forall j \in [0,m) &    \\
\qquad \rho^S_j, \rho^V_j \gets_R \F &\\\\

\qquad G^V_j \equiv \sum_{i=0}^{N-1}p_{i,j}V_i + \com(0, \rho^V_j )    &  A,B,C,D, & \\
\qquad G^S_j \equiv \sum_{i=0}^{N-1}p_{i,j}S_i + \com(0, \rho^S_j)& \lbrace G^S_j, G^V_j \rbrace_{j=0}^{m-1} \\
\qquad \qquad \text{(computing } p_{i,j}  & \xrightarrow{\qquad \qquad \qquad} & A, B, C, D, \{G^S_j, G^V_j\}_{j=0}^{m-1} \in \G \\
\qquad \qquad \text{ as in the orig. paper) } \\

\forall j \in [0,m), i \in [1,n) & \xleftarrow{x \gets \lbrace 0,1 \rbrace^\lambda} &  \\
\qquad f_{j,i} \equiv \sigma_{l_{j}i}x + a_{j,i} &&  \\
z_A = r_B x + r_A & \\
z_C = r_C x + r_D & \{f_{j,i}\}_{j=0,i=1}^{m-1,n-1}\\
z_S = sx^m -  \sum_{j=0}^{m-1}\rho^S_j x^j & z_A, z_C, z_S, z_V & \lbrace f_{j,i}\rbrace_{j,i =0,1}^{m-1,n-1} \in \F \\
z_V = vx^m - \sum_{j=0}^{m-1}\rho^V_h x^j &\xrightarrow{ \qquad \qquad } & z_A, z_C, z_V, z_R \in \F  \\

&& \forall j: f_{j,0} := x - \sum_{i=0}^{n-1} f_{j,i} \\\\
&& D+xC =  \\
&& \com( \lbrace f_{j,i}(x - f_{j,i})\rbrace_{j,i=0}^{m-1,n-1}; z_C) \\
&& A+xB =  \\
&& \com( \lbrace f_{j,i} \rbrace_{j,i=0}^{m-1,n-1};z_A) \\\\
&& \sum_{i=0}^{N-1}\overline{f}_i S_i - \sum_{j=0}^{m-1} x^j G^S_j \\
&& \qquad \qquad = \com(0, z_S) \\
& & \sum_{i=0}^{N-1}\overline{f}_i V_i - \sum_{j=0}^{m-1} x^j G^V_j \\
& & \qquad \qquad = \com(0, z_V) \\
&&  \text{where } \overline{f}_i \equiv \prod_{j=0}^{m-1} f_{j,i_j}
\end{array}
\end{math}
\caption{Parallel one-out-of-many protocol}
\label{fig:groth}
\end{figure}

This protocol is complete, special sound, and special honest-verifier zero knowledge; the proof is essentially the same as in the original construction, with only minor straightforward modifications.

\section{Payment System Security}

Zerocash \cite{zerocash} established a robust security framework for decentralized anonymous payment (DAP) scheme security that captures a realistic threat model with powerful adversaries who are permitted to add malicious coins into transactions' input ambiguity sets, control the choice of transaction inputs, and produce arbitrary transactions to add to a ledger.
Here we formally prove Spark's security within a related (but modified) security model; proofs follow somewhat similarly to that of \cite{zerocash}.

We recall the security definition for a DAP scheme $$\Pi = (\text{Setup}, \text{CreateAddress}, \text{Mint}, \text{Spend}, \text{Recover}, \text{Verify}),$$ which is secure if it satisfies definitions for ledger indistinguishability, transaction non-malleability, and balance security properties, which we define below.

Each security property is formalized as a game between a polynomial-time adversary $\mathcal{A}$ and a challenger $\mathcal{C}$, where in each game the behavior of honest parties is simulated via an oracle $\mathcal{O}^{DAP}$.
The oracle $\mathcal{O}^{DAP}$ maintains a ledger $L$ of transactions and provides an interface for executing \text{CreateAddress}, \text{Mint}, and \text{Spend} algorithm operations for honest parties.
To simulate behavior from honest parties, $\mathcal{A}$ passes a query to $\mathcal{C}$, which makes sanity checks and then proxies the queries to $\mathcal{O}^{DAP}$, returning the responses to $\mathcal{A}$ as needed.
For \text{CreateAddress} queries, $\mathcal{C}$ runs the \text{CreateAddress} protocol algorithm and returns the public address $\addr_{pk}$ to $\mathcal{A}$.
For \text{Mint} queries, the adversary specifies the value and destination public address for the transaction, and the resulting transaction is produced and returned by $\mathcal{C}$ if valid.
For \text{Spend} queries, the adversary specifies the input coins to be consumed, as well as the values and destination public addresses for the transaction, and the resulting transaction is produced (after $\mathcal{C}$ recovers the consumed coins) and returned by $\mathcal{C}$ if valid.
The oracle $\mathcal{O}^{DAP}$ also provides an \text{Insert} query that allows the adversary to insert arbitrary and potentially malicious $\text{tx}_{\text{mint}}$ or $\text{tx}_{\text{spend}}$ transactions to the ledger $L$, provided they are valid.

For each security property, we say the DAP satisfies the property if the adversary can win the corresponding game with only negligible probability.

\begin{remark}
We also require the DAP scheme to be complete, which implies that any unspent coin (with unique partial serial number commitment opening $(s,r,-)$ on the ledger can be spent.
This property means that if the coin appears on the ledger $L$ as an output of a transaction, but its corresponding tag is not revealed in any valid transaction, then a user in possession of the corresponding address spend key can generate a valid $\text{Spend}$ transaction consuming it.

Note that if the spend key holder cannot produce such a valid transaction, by construction the coin's tag must already appear in a previous valid transaction.
Such a previous valid transaction must have a modified Chaum-Pedersen proof that extracts, in part, the address's private spend key $r$, a contradiction since the adversary has only a negligible advantage in discrete logarithm extraction.
\end{remark}

\subsection{Balance}

Balance requires that no bounded adversary $\mathcal{A}$ can control more coins than are minted or spent to it.
It is formalized by a \textbf{BAL} game.
The adversary $\mathcal{A}$ adaptively interacts with $\mathcal{C}$ and the oracle with queries, and at the end of the interaction outputs a set of coins $\text{AdvCoins}$.
Letting $\text{ADDR}$ be set of all addresses of honest users generated by \text{CreateAddress} queries, $\mathcal{A}$ wins the game if
$$v_{\text{unspent}} + v_{\mathcal{A} \to \text{ADDR}} > v_{\text{mint}} + v_{\text{ADDR} \to \mathcal{A}},$$
which implies that the total value the adversary can spend or has spent already is greater than the value it has minted or received.
Here:
\begin{itemize}
    \item $v_{\text{unspent}}$ is the total value of unspent coins in $\text{AdvCoins}$;
    \item $v_{\text{mint}}$ is the total value minted by $\mathcal{A}$ to itself through \text{Mint} or \text{Insert} queries;
    \item $v_{\text{ADDR} \xrightarrow{} \mathcal{A}}$ is the total value of coins received by $\mathcal{A}$ from addresses in \text{ADDR}; and
    \item $v_{\mathcal{A} \xrightarrow{} \text{ADDR}}$ is the total value of coins sent by the adversary to the addresses in \text{ADDR}.
\end{itemize}
We say a DAP scheme $\Pi$ is \textbf{BAL}-secure if the adversary $\mathcal{A}$ wins the game \textbf{BAL} only with negligible probability:
$$\text{Pr}[\text{\textbf{BAL}}(\Pi, \mathcal{A}, \lambda) = 1] \leq \text{negl}(\lambda)$$

Assume the challenger maintains an extra augmented ledger $(L, \vec{a})$ where each $a_i$ contains secret data from transaction $\text{tx}_i$ in $L$.
In that case where $\text{tx}_i$ was produced by a query from $\mathcal{A}$ to the challenger $\mathcal{C}$, $a_i$ contains all secret data used by $\mathcal{C}$ to produce the transaction.
If instead $\text{tx}_i$ was produced by a direct $\text{Insert}$ query from $\mathcal{A}$, $a_i$ consists of all extracted witness data from proofs contained in the transaction.
The resulting augmented ledger $(L, \vec{a})$ is balanced if the following conditions are true:
\begin{enumerate}
    \item\label{cond:distinct} Each valid spend transaction $\text{tx}_{\text{spend},k}$ in $(L, \vec{a})$ consumes distinct coins, and each consumed coin is the output of a valid $\text{tx}_{\text{mint},i}$ or $\text{tx}_{\text{spend},j}$ transaction for some $i < k$ or $j < k$.
    This requirement implies that all transactions spend only valid coins, and that no coin is spent more than once within the same valid transaction.

    \item\label{cond:multiple} No two valid spend transactions in $(L, \vec{a})$ consume the same coin.
    This implies no coin is spent through two different transactions.
    Together with the first requirement, this implies that each coin is spent at most once.

    \item\label{cond:value} For each $(\text{tx}_{\text{spend}}, a)$ in $(L, \vec{a})$ consuming input coins with value commitments $\{C_u\}_{u=0}^{w-1}$, for each $u \in [0,w)$:
    \begin{itemize}
        \item If $C_u$ is the output of a valid \text{Mint} transaction with augmented ledger witness $a'$, then the value of $C_u$ contained in $a'$ is the same as the corresponding value contained in $a$ for the value commitment offset $C_u'$.
        \item If $C_u$ is the output of a valid \text{Spend} transaction with augmented ledger witness $a'$, then the value of $C_u$ contained in $a'$ is the same as the corresponding value contained in $a$ for the value commitment offset $C_u'$.
    \end{itemize}
    This implies that values are maintained between transactions.

    \item\label{cond:balance} For each $(\text{tx}_{\text{spend}}, a)$ in $(L, \vec{a})$ with fee $f$ that consumes input coins with value commitment offsets $\{C_u'\}_{u=0}^{w-1}$ and generates coins with value commitments $\{\overline{C}_j\}_{j=0}^{t-1}$, $a$ contains values $\{v_u\}_{u=0}^{w-1}$ and $\{\overline{v}_j\}_{j=0}^{t-1}$ corresponding to the commitments such that the balance equation
    $$\sum_{u=0}^{w-1} v_u = \sum_{j=0}^{t-1} \overline{v}_j + f$$
    holds.
    For each $(\text{tx}_{\text{mint}}, a)$ in $(L, \vec{a})$ with public value $v$ that generates a coin with value commitment $C$, $a$ contains a value $v'$ corresponding to the commitment such that $v = v'$.
    This implies that values cannot be created arbitrarily.

    \item\label{cond:honest} For each $\text{tx}_{\text{spend}}$ in $(L, \vec{a})$ inserted by $\mathcal{A}$ through an \text{Insert} query, each consumed coin in $\text{tx}_{\text{spend}}$ is not recoverable by any address in $\text{ADDR}$.
    This implies that the adversary cannot generate a transaction consuming coins it does not control.
\end{enumerate}
If these five conditions hold, then $\mathcal{A}$ did not spend or control more money than was previously minted or spent to it, and the inequality
$$v_{\text{mint}} + v_{\text{ADDR} \to \mathcal{A}} \leq v_{\text{unspent}} + v_{\mathcal{A} \to \text{ADDR}}$$
holds.
We now prove that Spark is \textbf{BAL}-secure under this definition.

\begin{proof}
By way of contradiction, assume the adversary $\mathcal{A}$ interacts with $\mathcal{C}$ leading to a non-balanced augmented ledger $(L, \vec{a})$ with non-negligible probability; then at least one of the five conditions described above is violated with non-negligible probability:

\textbf{$\mathcal{A}$ violates Condition \ref{cond:distinct}:} Suppose that the probability $\mathcal{A}$ wins the game violating Condition 1 is non-negligible.
Each $\text{tx}_{\text{spend}}$ generated by a non-$\text{Insert}$ oracle query satisfies this condition already, so there must exist a transaction $(\text{tx}_{\text{spend}}, a)$ in $(L, \vec{a})$ inserted by $\mathcal{A}$.

Suppose there exist inputs $u_1,u_2 \in [0,w)$ of $\text{tx}_{\text{spend}}$ that consume the same coin; that is, reveal the same partial opening $(s,r,-)$ of coin serial number commitments.
Validity of the modified Chaum-Pedersen proofs $(\Pi_{\text{chaum}})_{u_1}$ and $(\Pi_{\text{chaum}})_{u_2}$ for these inputs gives extracted openings $S_{u_1}' = s_{u_1} F + r_{u_1} G + y_{u_1} H$ and $S_{u_2}' = s_{u_2} F + r_{u_2} G + y_{u_2} H$ and tag representations such that $U = s_{u_1} T_{u_1} + r_{u_1} G$ and $U = s_{u_2} T_{u_2} + r_{u_2} G$.
Because transaction validity implies $T_{u_1} \neq T_{u_2}$, we must have $(s_{u_1},r_{u_1}) \neq (s_{u_2},r_{u_2})$.
Validity of the corresponding parallel one-out-of-many proofs $(\Pi_{\text{par}})_{u_1}$ and $(\Pi_{\text{par}})_{u_2}$ yields indices (corresponding to input set group elements $S_1$ and $S_2$) and discrete logarithm extractions such that $S_1 - S_{u_1}' = x_{u_1} H$ and $S_2 - S_{u_2}' = x_{u_2} H$.
This means
$$S_1 = \dcom(s_{u_1},r_{u_1},x_{u_1}+y_{u_1})$$
and
$$S_2 = \dcom(s_{u_2},r_{u_2},x_{u_2}+y_{u_2})$$
which contradicts the assumption of unique partial openings for consumed coin serial number commitments.

The second possibility for violation of the condition is that the transaction $\text{tx}_{\text{spend}}$ consumes a coin that is not generated in any previous valid transaction.
Validity of the modified Chaum-Pedersen proof for such an input gives a tag representation $U = sT + rG$ and serial number commitment offset $S' = sF + rG + yH$.
Validity of the parallel one-out-of-many proof for the input gives an index $l$ such that $S_l - S' = xH$, meaning $S_l = sF + rG + (x + y)H$ is an opening of this commitment.
Because transaction validity requires all input ambiguity set elements to be produced in previous valid transactions as valid commitments, the adversary knows an opening of such a commitment, which is a contradiction.

\textbf{$\mathcal{A}$ violates Condition \ref{cond:multiple}:} Suppose that the probability $\mathcal{A}$ wins the game violating Condition \ref{cond:multiple} is non-negligible.
This means the augmented ledger $(L, \vec{a})$ contains two valid \text{Spend} transactions consuming the same coin but producing distinct tags.
Similarly to the previous argument, this implies distinct openings of the coin serial number commitment, which is a contradiction.

\textbf{$\mathcal{A}$ violates Condition \ref{cond:value}:} Suppose that the probability $\mathcal{A}$ wins the game violating Condition \ref{cond:value} is non-negligible.
Let $C$ be the value commitment of the coin consumed by an input of $\text{tx}_{\text{spend}}$ and generated in a previous transaction (of either type) in $(L, \vec{a})$.
Since the generating transaction is valid, we have an extracted opening $C = vG + aH$ from either the balance proof (in a \text{Mint} transasction) or the range proof (in a \text{Spend} transaction).
Validity of the corresponding parallel one-out-of-many proof in $\text{tx}_{\text{spend}}$ gives an extracted discrete logarithm $C - C' = xH$, where $C'$ is the input's value commitment offset.
But this immediately gives $C' = vG + (a - x)H$, a contradiction since the commitment scheme is binding.

\textbf{$\mathcal{A}$ violates Condition \ref{cond:balance}:} Suppose that the probability $\mathcal{A}$ wins the game violating Condition \ref{cond:balance} is non-negligible.
If the augmented ledger $(L, \vec{a})$ contains a \text{Spend} transaction that violates the balance equation, this immediately implies a break in the commitment binding property since the corresponding balance proof $\Pi_{\text{bal}}$ is valid, which is a contradiction.
If instead the augmented ledger $(L, \vec{a})$ contains a \text{Mint} transaction that violates the balance requirement, this immediately implies a break in the commitment binding property since the corresponding balance proof $\Pi_{\text{bal}}$ is valid, again a contradiction.

\textbf{$\mathcal{A}$ violates Condition \ref{cond:honest}:} Suppose that the probability $\mathcal{A}$ wins the game violating Condition \ref{cond:honest} is non-negligible.
That is, $\mathcal{A}$ produces a \text{Spend} transaction $\text{tx}_{\text{spend}}$ by an \text{Insert} question that is valid on the augmented ledger $(L, \vec{a})$ and consumes a coin corresponding to a coin serial number commitment $S$ that can be recovered by a public address $(Q_1, Q_2) \in \text{ADDR}$.

Validity of the Chaum-Pedersen proof corresponding to this input of $\text{tx}_{\text{spend}}$ yields an extracted representation $S' = s'F + r'G + yH$.
Validity of the corresponding parallel one-of-many proof gives a serial number commitment $S$ and extraction such that $S - S' = xH$, so $S = s'F + r'G + (x + y)H$.

Now let $(s_1,s_2,r)$ be the secret key corresponding to the address $(Q_1,Q_2)$.
Since $\text{tx}_{\text{spend}}$ consumes a coin recoverable by this address, a serial number commitment for the recovered coin is
\begin{align*}
\overline{S} &= \hash_{\text{ser}}(s_1 K, Q_1, Q_2)F + Q_2 \\
&= (\hash_{\text{ser}}(s_1 K, Q_1, Q_2) + s_2)F + rG
\end{align*}
for recovery key $K$.

Since the commitment scheme is binding, we must therefore have $r' = r$, which is a contradiction since $\mathcal{A}$ cannot extract this discrete logarithm from the public address.

This completes the proof.
\end{proof}

\subsection{Transaction Non-Malleability}

This property requires that no bounded adversary can substantively alter a valid transaction.
In particular, non-malleability prevents malicious adversaries from modifying honest users' transactions by altering data or redirecting the outputs of a valid transaction before the transaction is added to the ledger.
Since non-malleability of \text{Mint} transactions is offloaded to authorizations relating to consensus rules or base-layer operations, we need only consider the case of \text{Spend} transactions.

This property is formalized by an experiment \textbf{TR-NM}, in which a bounded adversary $\mathcal{A}$ adaptively interacts with the oracle $\mathcal{O}^{\text{DAP}}$, and then outputs a spend transaction $\text{tx}'$.
If we let $T$ denote the set of all transactions produced by \text{Spend} queries to $\mathcal{O}^{\text{DAP}}$, and $L$ denote the final ledger, $\mathcal{A}$ wins the game if there exists $\text{tx} \in T$ such that:
\begin{itemize}
    \item $\text{tx}' \neq \text{tx}$;
    \item $\text{tx}'$ reveals a tag also revealed by $\text{tx}$; and
    \item both $\text{tx}'$ and $\text{tx}$ are valid transactions with respect to the ledger $L^{\prime}$ containing all transactions preceding $\text{tx}$ on $L$.
\end{itemize}

We say a DAP scheme $\Pi$ is \textbf{TR-NM}-secure if the adversary $\mathcal{A}$ wins the game \textbf{TR-NM} only with negligible probability:
$$\text{Pr}[\text{\textbf{TR-NM}}(\Pi, \mathcal{A}, \lambda) = 1] \leq \text{negl}(\lambda)$$

Let $\mathcal{T}$ be the set of all $\text{tx}_{\text{spend}}$ transactions generated by the $\mathcal{O}^{DAP}$ in response to $\text{Spend}$ queries.
Since these transactions are generated by these oracle queries, $\mathcal{A}$ does not learn any secret data used to produce these transactions.

\begin{proof}
Assume that the adversary $\mathcal{A}$ wins the game with non-negligible probability.
That is, $\mathcal{A}$ produces a transaction $\text{tx}'$ revealing a tag $T$ also revealed in a transaction $\text{tx}$.
Without loss of generality, assume each transaction consumes a single coin.

Observe that a valid \text{Spend} binds all transaction elements except for modified Chaum-Pedersen proofs into each such proof via $\hash_{\text{bind}}$ and the proof transcripts.
Therefore, in order to produce valid $\text{tx}' \neq \text{tx}$, we consider two cases:
\begin{itemize}
    \item the modified Chaum-Pedersen proofs are identical, but $\text{tx}'$ and $\text{tx}$ differ in another element of the transaction structures; or
    \item the modified Chaum-Pedersen proof in $\text{tx}'$ is distinct from the proof in $\text{tx}$.
\end{itemize}

In the first case, at least one input to the binding hash $\hash_{\text{bind}}$ used to initialize the modified Chaum-Pedersen transcripts must differ between the proofs.
Because we model this hash function as a random oracle, the outputs differ except with negligible probability, a contradiction since the resulting proof structures must be identical.

In the second case, suppose that the modified Chaum-Pedersen proof $\Pi_{\text{chaum}}'$ contained in $\text{tx}'$ yields extraction $(s',r',y')$, and that the proof $\Pi_{\text{chaum}}$ contained in $\text{tx}$ yields $(s,r,y)$.
Since the corresponding tags are identical, we must have $s' = s$ and $r' = r$.
Any serial number commitment $S$ with a partial opening $(s,r,-)$ consumed in $\text{tx}$ was generated such that $r$ is a spend key component of the controlling public address $(Q_1,Q_2)$.
Since $\mathcal{A}$ does not control this address, it cannot produce $r$ without extracting from $S$ or the $(Q_1,Q_2)$, which implies a non-negligible discrete logarithm advantage, a contradiction.
\end{proof}

\subsection{Ledger Indistinguishability}

This property implies that no bounded adversary $\mathcal{A}$ received any information from the ledger except what is already publicly revealed, even if it can influence valid ledger operations by honest users.

Ledger indistinguishability is formalized through an experiment \textbf{L-IND} between a bounded adversary $\mathcal{A}$ and a challenger $\mathcal{C}$, which terminates with a binary output $b^{\prime}$ by $\mathcal{A}$.
At the beginning of the experiment, $\mathcal{C}$ samples $\text{Setup}(1^\lambda) \to pp$ and sends the parameters to $\mathcal{A}$; next it samples a random bit $b \in \lbrace 0,1 \rbrace$ and initializes two separate DAP oracles $\mathcal{O}_0^{DAP}$ and $\mathcal{O}_1^{DAP}$, each with its own separate ledger and internal state.
At each consecutive step of the experiment:
\begin{enumerate}
\item $\mathcal{C}$ provides $\mathcal{A}$ two ledgers $(L_{\text{left}} = L_b, L_{\text{right}} = L_{1-b})$ where $L_b$ and $L_{1-b}$ are the current ledgers of the oracles $\mathcal{O}_b^{DAP}$ and $\mathcal{O}_{1-b}^{DAP}$ respectively.
\item $\mathcal{A}$ sends to $\mathcal{C}$ two queries $Q, Q^{\prime}$ of the same type (one of \text{CreateAddress}, \text{Mint}, \text{Spend}, \text{Recover}, or \text{Insert}).
\begin{itemize}
    \item If the query type is \text{Insert} or \text{Mint}, $\mathcal{C}$ forwards $Q$ to $L_{b}$ and $Q^\prime$ to $L_{1-b}$, permitting $\mathcal{A}$ to insert its own transactions or mint new coins to $L_{\text{left}}$ and $L_{\text{right}}$.
    \item For all queries of type \text{CreateAddress}, \text{Spend}, or \text{Recover}, $\mathcal{C}$ first checks if the two queries $Q$ and $Q^\prime$ are publicly consistent, and then forwards $Q$ to $\mathcal{O}_0^{DAP}$ and $Q^\prime$ to $\mathcal{O}_1^{DAP}$.
    It receives the two oracle answers $(a_0,a_1)$, but returns $(a_b,a_{1-b})$ to $\mathcal{A}$.
\end{itemize}
\end{enumerate}
As the adversary does not know the bit $b$ and the mapping between $(L_{\text{left}}, L_{\text{right}})$ and $(L_0, L_1)$, it cannot learn weather it affects the behavior of honest parties on $(L_0, L_1)$ or on $(L_1, L_0)$.
At the end of the experiment, $\mathcal{A}$ sends $\mathcal{C}$ a bit $b^\prime \in \lbrace 0,1 \rbrace$.
The challenger outputs $\mathcal{C}$ outputs 1 if $b = b^\prime$, and 0 otherwise.

We require the queries $Q$ and $Q^\prime$ be publicly consistent as follows: if the query type of $Q$ and $Q^\prime$ is \text{Recover}, they are publicly consistent by construction.
If the query type of $Q$ and $Q^\prime$ is \text{CreateAddress}, both oracles generate the same address.
If the query type of $Q$ and $Q^\prime$ is \text{Mint}, the minted values of both queries must be equal.
If the query type of $Q$ and $Q^\prime$ is \text{Spend}, then:
\begin{itemize}
    \item Both $Q$ and $Q^\prime$ must be well-formed and valid, so the referenced input coins must have been generated in a previous transaction on the ledger and be unspent.
    Further, the transaction must balance.
    \item The number of spent coins and output coins must be the same in $Q$ and $Q^\prime$.
    \item If a consumed coin in $Q$ references a coin in $L_0$ posted by $\mathcal{A}$ through an \text{Insert} query, then the corresponding index in $Q^\prime$ must also reference a coin in $L_1$ posted by $\mathcal{A}$ through an \text{Insert} query and the values of these two coins must be equal as well (and vice versa for $Q^\prime$).
    \item If an output coin referenced by $Q$ does not reference a recipient address in the oracle \text{ADDR} list (and therefore is controlled by $\mathcal{A}$), then the corresponding value must equal that of the corresponding coin referenced by $Q$ at the same index (and vice versa for $Q^\prime$).
\end{itemize}

We say a DAP scheme $\Pi$ is $\textbf{L-IND}$-secure if $\mathcal{A}$ wins the game \textbf{L-IND} only probability at most negligibly better than chance:
$$\text{Pr}[\text{\textbf{L-IND}}(\Pi, \mathcal{A}, \lambda) = 1] - \frac{1}{2} \leq \text{negl}(\lambda)$$

\begin{proof}
In order to prove that $\mathcal{A}$'s advantage in the \textbf{L-IND} experiment is negligible, we first consider a simulation experiment $\mathcal{D}^{\text{sim}}$, in which $\mathcal{A}$ interacts with $\mathcal{C}$ as in the L-IND experiment, but with modifications.

\textbf{The simulation experiment $\mathcal{D}^{\text{sim}}$}: Since the parallel one-out-of-many, modified Chaum-Pedersen, representation, and range proving systems are all special honest-verifier zero knowledge, we can take advantage of the simulator for each.
Given input statements and verifier challenges, each proving system's simulator produces transcripts indistinguishable from honest proofs.
Additionally, we now define the behavior of the full simulator.

\textbf{The simulation.} The simulation $\mathcal{D}^{\text{sim}}$ works as follows.
As in the original experiment, $\mathcal{C}$ samples the system parameters $\text{Setup}(1^\lambda) \to pp$ and a random bit $b$, and initializes DAP oracles $\mathcal{O}^{\text{DAP}}_0$ and $\mathcal{O}^{\text{DAP}}_1$.
Then $\mathcal{D}^{\text{sim}}$ proceeds in steps.
At each step, it provides $\mathcal{A}$ with ledgers $L_{\text{\text{left}}} = L_{b}$ and $L_{\text{\text{right}}} = L_{1-b}$,after which $\mathcal{A}$ sends two publicly-consistent queries $(Q, Q^\prime)$ of the same type.
Recall that the queries $Q$ and $Q^\prime$ are consistent with respect to public data and information related to the addresses controlled by $\mathcal{A}$.
Depending on the query type, the challenger acts as follows:
\begin{itemize}
    \item Answering \text{Recover} and \text{Insert} queries: The challenger proceeds as in the original \textbf{L-IND} experiment.
    \item Answering \text{CreateAddress} queries: In this case the challenger replaces the public address components $Q_1$ and $Q_2$ with random strings of the appropriate lengths, producing $\text{addr}_{pk}$ that is returned to $\mathcal{A}$.
    \item Answering \text{Mint} queries: The challenger does the following to answer $Q$ and $Q^\prime$ separately:
    \begin{enumerate}
        \item If $\mathcal{A}$ provided a public address $\addr_{\text{pk}}$ not generated by the challenger, it produces a coin using \text{CreateCoin} as usual.
        \item Otherwise, it simulates coin generation:
        \begin{enumerate}
            \item Samples a recovery key $K$ uniformly at random.
            \item Samples a serial number commitment $S$ uniformly at random.
            \item Samples a value commitment $C$ uniformly at random.
            \item Samples a random input used to produce a symmetric encryption key $\text{AEADKeyGen} \to k_{\text{enc}}$.
            \item Simulates the memo encryption by selecting random $\widetilde{m}$ of the proper length, and encrypting it to produce $$\text{AEADEncrypt}(k_{\text{enc}},\texttt{memo},\widetilde{m}) \to \overline{m}.$$
        \end{enumerate}
        \item Simulates the balance proof $\Pi_{\text{bal}}$ on the statement $(C - \com(v,0))$.
        \item Assembles the transaction and adds it to the ledger as appropriate.
    \end{enumerate}
    \item Answering \text{Spend} queries: The challenger does the following to answer $Q$ and $Q^\prime$ separately, where $w$ is the number of consumed coins and $t$ the number of generated coins specified by $\mathcal{A}$ as part of its queries:
    \begin{enumerate}
        \item Parse the input cover set serial number commitments and value commitments as $\text{InCoins} = \{(S_i, C_i)\}_{i=0}^{N-1}$.
        \item For each $u \in [0,w)$, where $l_u$ represents the index of the consumed coin in $\text{InCoins}$:
        \begin{enumerate}
            \item Samples a tag $T_u$ uniformly at random.
            \item Samples a serial number commitment offset $S_u'$ and value commitment offset $C_u'$ uniformly at random.
            \item Simulates a parallel one-out-of-many proof $(\Pi_{\text{par}})_u$ on the statement $(\{S_i - S_u', C_i - C_u'\}_{i=0}^{N-1})$.
        \end{enumerate}
        \item For each $j \in [0,t)$:
        \begin{enumerate}
            \item If $\mathcal{A}$ provided a public address $\addr_{\text{pk}}$ not generated by the challenger, it produces a coin using \text{CreateCoin} as usual.
            \item Otherwise, it simulates coin generation:
            \begin{enumerate}
                \item Samples a recovery key $K_j$ uniformly at random.
                \item Samples a serial number commitment $S_j$ uniformly at random.
                \item Samples a value commitment $\overline{C}_j$ uniformly at random.
                \item Samples a random input used to produce a symmetric encryption key $\text{AEADKeyGen} \to k_{\text{enc}}$.
                \item Simulates the value encryption by selecting random $\widetilde{v}$ of the proper length, and encrypting it to produce $$\text{AEADEncrypt}(k_{\text{enc}},\texttt{val},\widetilde{v}) \to \overline{v}_j.$$
                \item Simulates the memo encryption by selecting random $\widetilde{m}$ of the proper length, and encrypting it to produce $$\text{AEADEncrypt}(k_{\text{enc}},\texttt{memo},\widetilde{m}) \to \overline{m}_j.$$
                \item Simulates a range proof $(\Pi_{\text{rp}})_j$ on the statement $(\overline{C}_j)$.
            \end{enumerate}
        \end{enumerate}
        \item Simulates the balance proof $\Pi_{\text{bal}}$ on the statement $$\left(\sum_{u=0}^{w-1} C_u' - \sum_{j=0}^{t-1} \overline{C}_j - \com(f,0)\right).$$
        \item For each $u \in [0,w)$, computes the binding hash $\mu$ as defined and simulates a modified Chaum-Pedersen proof $(\Pi_{\text{chaum}})_u$ on the statement $(S_u', T_u)$.
        \item Assembles the transaction and adds it to the ledger as appropriate.
    \end{enumerate}
\end{itemize}

For experiments defined below, we define $\text{Adv}^{\mathcal{D}}$ as the advantage of $\mathcal{A}$ in some experiment $\mathcal{D}$ over the original $\textbf{L-IND}$ game.
By definition, all answers sent to $\mathcal{A}$ in $\mathcal{D}^{\text{sim}}$ are computed independently of the bit $b$, so $\text{Adv}^{\mathcal{D}^{\text{sim}}} = 0$. We will prove that $\mathcal{A}$'s advantage in the real L-IND experiment $\mathcal{D}^{\text{real}}$ is at most negligibly different than $\mathcal{A}$'s advantage in $\mathcal{D}^{\text{sim}}$.
To show this, we construct intermediate experiments in which $\mathcal{C}$ performs a specific modification of $\mathcal{D}^{\text{real}}$ against $\mathcal{A}$.

\textbf{Experiment $\mathcal{D}_1$}: This experiment modifies $\mathcal{D}^{\text{real}}$ by simulating all one-out-of-many proofs, range proofs, representation proofs, and modified Chaum-Pedersen proofs.
As all these protocols are special honest-verifier zero knowledge, the simulated proofs are indistinguishable from the real proofs generated in $\mathcal{D}^{\text{real}}$.
Hence $\text{Adv}^{\mathcal{D}_1} = 0$.

\textbf{Experiment $\mathcal{D}_2$}: This experiment modifies $\mathcal{D}_{1}$ by replacing all encrypted values and memos in transactions with challenger-generated recipient public addresses with encryptions of random values of appropriate lengths under keys chosen uniformly at random, and by replacing recovery keys with uniformly random values.
Since the underlying authenticated symmetric encryption scheme is IND-CCA and IK-CCA secure and we assume the decisional Diffie-Hellman problem is hard, the adversarial advantage in distinguishing ledger output in the $\mathcal{D}_2$ experiment is negligibly different from its advantage in the $\mathcal{D}_{1}$ experiment.
Hence $\lvert \text{Adv}^{\mathcal{D}_2} - \text{Adv}^{\mathcal{D}_1} \rvert$ is negligible.

\textbf{Experiment $\mathcal{D}^{\text{sim}}$}: The $\mathcal{D}^{\text{sim}}$ experiment is formally defined above.
In particular, it differs from $\mathcal{D}_{2}$ by replacing consumed coin tags, serial number commitment offset, and value commitment offsets with uniformly random values; and by replacing output coin serial number and value commitments with random values.
In previous experiments (including $\mathcal{D}^{\text{real}}$), tags are generated using a pseudorandom function \cite{dodis}, and the other given values are generated as commitments with masks derived from hash functions modeled as independent random oracles, so the adversarial advantage in distinguishing ledger output in $\mathcal{D}^{\text{sim}}$ is negligibly different from its advantage in the $\mathcal{D}_2$ experiment.
Hence $\lvert \text{Adv}^{\mathcal{D}^{\text{sim}}} - \text{Adv}^{\mathcal{D}_2} \rvert$ is negligible.

This shows that the adversary has only negligible advantage in the real $\textbf{L-IND}$ game over the simulation, where it can do no better than chance, which completes the proof.
\end{proof}

\end{document}