Merge pull request #20

d5ceceb updating (Brandon Goodell)
5056c7f updating (Brandon Goodell)
8dce16b Finish upgrade subadd to mrl6 (Brandon Goodell)
8c04196 Upgrading subaddys (Brandon Goodell)
8ac8ef5 Upgrading to MRL6 (Brandon Goodell)
4235bb4 updating files (Brandon Goodell)
87024f5 old copy, see thresh.tex (Brandon Goodell)
9131519 old copy (Brandon Goodell)
d40cd00 Add files via upload (Brandon Goodell)
979d8de Updating files (Brandon Goodell)
9876e13 Where did roadmap 2 go? (Brandon Goodell)
4b76a90 Organizing (Brandon Goodell)
af3dfdd Changing more filenames, adding subaddys (Brandon Goodell)
5c1c881 More filename changes (Brandon Goodell)
833e077 Renaming folders (Brandon Goodell)
8b57e07 Copying over the work of Shen on ge_fromfe (binaryfate)
4dd4d1d renamed directory to StringCT-java (knaccc)
6ae0228 renamed bootleruffing to stringct (knaccc)
63dfd2b converted to use x25519 bouncycastle impl (knaccc)

publications/bulletins/MRL-0006-subaddy/main.bib

@@ -0,0 +1,23 @@
+@misc{cryptonote,
+title = {CryptoNote v2.0},
+author = {van Saberhagen, Nicolas},
+year = {2013}
+}
+
+@misc{pr,
+title = {Subaddresses},
+author = {Monero project},
+howpublished = {\url{https://github.com/monero-project/monero/pull/2056}},
+note = {GitHub pull request \#2056}
+}
+
+@article{uniform,
+  title={Uniform distribution and sum modulo m of independent random variables},
+  author={Scozzafava, Paola},
+  journal={Statistics \& Probability Letters},
+  volume={18},
+  number={4},
+  pages={313--314},
+  year={1993},
+  publisher={Elsevier}
+}

publications/bulletins/MRL-0006-subaddy/main.tex

@@ -0,0 +1,125 @@
+\documentclass{mrl}
+
+\title{An efficient implementation of Monero subaddresses}
+\authors{Sarang Noether\footnote{\texttt{sarang.noether@protonmail.com}} and Brandon Goodell\footnote{\texttt{surae.noether@protonmail.com}}}
+\affiliations{Monero Research Lab}
+\date{\today}
+
+\type{RESEARCH BULLETIN}
+\ident{MRL-XXXX}
+
+\begin{document}
+
+\begin{abstract}
+Users of the Monero cryptocurrency who wish to reuse wallet addresses in an unlinkable way must maintain separate wallets, which necessitates scanning incoming transactions for each one. We document a new address scheme that allows a user to maintain a single master wallet address and generate an arbitary number of unlinkable subaddresses. Each transaction needs to be scanned only once to determine if it is destinated for any of the user's subaddresses. The scheme additionally supports multiple outputs to other subaddresses, and is as efficient as traditional wallet transactions.
+\end{abstract}
+
+\section{Introduction}
+Privacy within Monero transactions is achieved by three primary constructions: ring signatures, one-time keys, and amount commitments. The use of ring signatures ensures that an attacker cannot determine the actual input public key used in the transaction, as it is obscured by the presence of randomly chosen input public keys \cite{cryptonote}. Amount commitments use homomorphic properties to guarantee that while a third party is not able to determine the amount of a transaction output, it can prove that the transaction inputs and outputs are balanced. When combined with a range proof to ensure that the output is within a defined and valid range, commitments mask transaction amounts while avoiding misuse by a malicious spender. One-time keys are generated using transaction parameters and the recipient's published wallet address, and are intended to make it impossible for anyone but the recipient to identify the destination of transactions or spend the resulting funds.
+
+An issue not addressed (pun intended) by these privacy guards is that of recipient addresses. Bob may wish to receive Monero into a wallet for personal donations, but also wish to receive Monero for purchases from his business. If Bob is conscious of his privacy, he may not wish to use the same wallet address, since this links his personal and business online presence to the same individual. An obvious solution is for Bob to create two wallets and publish the addresses separately, one to his personal blog and the other to his business site. However, this means that Bob must scan each incoming transaction twice to determine if it was sent to one of his two wallets. This problem is compounded linearly when Bob creates additional addresses for separate uses.
+
+What is needed is a method for allowing Bob to publish different and unlinkable addresses in a way that does not adversely affect computations applied to incoming transactions. In this whitepaper, we document an efficient solution to the problem: a \textit{subaddress} scheme \cite{pr}. The scheme allows Bob to produce as many addresses as he wishes and distribute them in any way he sees fit. These subaddresses cannot be linked to each other, nor to Bob's original wallet address. When scanning incoming transactions, the computations required scale in constant time with the number of subaddresses, meaning there is no additional computational complexity.
+
+
+\section{Construction}
+Suppose that Alice wishes to send some of her hard-earned Monero to Bob. Bob's master wallet address, which he has not published anywhere, is $(A,B) = (aG, bG)$, where $a$ and $b$ are secret scalars and $G$ a common elliptic curve basepoint. Bob wishes to use his master address to generate a subaddress, which he can give to Alice or otherwise publish.
+
+Bob is assumed to maintain a list on the computer tasked with managing his wallets; this list consists of scalars used in previous subaddresses. To create a new subaddress, Bob chooses a scalar $i$, not necessarily at random, that is not already in the list. He computes the following:
+\begin{eqnarray*}
+D_i &\equiv& B + H_s(a,i)G \\
+C_i &\equiv& aD_i
+\end{eqnarray*}
+Here $H_s$ is a cryptographic scalar hash function. The subaddress is defined as the pair of points $(C_i,D_i)$. Bob is assumed to also have a hash table stored on his computer that maps $D_i \mapsto i$.
+
+To send Monero to Bob's subaddress $(C_i,D_i)$, Alice chooses a random transaction scalar $s$ and computes the transaction public key:
+$$R \equiv sD_i$$
+Alice then computes the output public key:
+$$P \equiv H_s(sC_i)G + D_i$$
+The use of separate transaction keys for each output allows Alice to include multiple outputs directed to subaddresses.
+
+If Alice wants to send change to her own master wallet address $(X,Y) = (xG,yG)$, she can do so by constructing a change public key:
+$$P_{\operatorname{change}} \equiv H_s(xR)G + Y$$
+If instead Alice has a subaddress $(Z_j,W_j)$ of her own, she can direct her change output there:
+$$P_{\operatorname{change}} \equiv H_s(xR)G + W_j$$
+
+When Bob scans incoming transactions, he checks each output public key $P$ (with associated transaction public key $R$) by computing the following:
+$$D' \equiv P - H_s(aR)G$$
+If Bob sees that this value $D'$ maps to a scalar $i$ in his local hash table, he is assured that the output was sent to the subaddress $(C_i,D_i)$. This is because
+\begin{eqnarray*}
+P - H_s(aR)G &=& H_s(sC_i)G + D_i - H_s(a(sD_i))G \\
+&=& H_s(sC_i)G + D_i - H_s(s(aD_i))G \\
+&=& H_s(sC_i)G + D_i - H_s(sC_i)G \\
+&=& D_i.
+\end{eqnarray*}
+
+In order to use his funds as the input to a later transaction, Bob needs to be able to determine the private key associated to $P$. He can do this easily using the index returned from the hash table lookup:
+$$p \equiv H_s(aR) + b + H_s(a,i)$$
+This succeeds since
+\begin{eqnarray*}
+pG &=& (H_s(aR) + b + H_s(a,i))G \\
+&=& (H_s(sC_i) + b + H_s(a,i))G \\
+&=& H_s(sC_i)G + D_i \\
+&=& P.
+\end{eqnarray*}
+
+
+\section{Integration with transactions}
+The present subaddress scheme introduces a necessary change in the handling of transactions, and cannot be considered a ``drop-in" replacement for standard wallets. When Alice wishes to spend to Bob's standard wallet, she constructs a transaction public key $R = rG$ using the common basepoint. One naive way that Alice could later prove she was the author of the transaction is to prove knowledge of $r$ (or, even more naively, reveal $r$ directly) to a third party; notably, she can do this without revealing that the funds go to Bob's wallet address.
+
+Using subaddresses, Alice must instead construct the transaction public key as $R = sD$, using Bob's subaddress public key as the basepoint. Since the secret key $s$ is chosen uniformly at random, a subaddress transaction public key is still uniformly distributed; however, Alice can no longer naively prove she knows the common basepoint secret key without also revealing Bob's subaddress as the recipient of the funds, since it is tied in with Bob's subaddress in the Diffie-Hellman exchange. She would need to reveal $D$ in addition to $s$. While other methods exist to prove authorship of a transaction using commitments, it is worth noting this change.
+
+With standard transactions, Bob can ask Charlie to watch incoming transactions for him, or otherwise wish for Charlie to audit his wallet. To do this, Bob would reveal to Charlie the secret view key $a$ and wallet address component $B$. In the subaddress scheme, Bob can similarly reveal $a$ to Charlie. Charlie must then construct the hash table using either a list of known indices from Bob or a set range that he precomputes.
+
+
+\section{Subaddress accounts}
+Since a change output can be directed to either the sender's master wallet or a subaddress, it is possible to logically group subaddresses in a natural way that parallels the function of separate wallet balances. One way to do this is to replace the subaddress index $i$ with an ordered pair $(i,j)$. For any fixed $i$, the wallet holder defines the set of subaddresses $\{i,j\}_j$ as an \textit{account}, where each subaddress has \textit{major index} $i$ and \textit{minor index} $j$.
+
+When Bob receives funds at a subaddress $(i,j)$ within account $i$, his wallet software sums the funds held by all subaddresses in the account as a single balance. Change can then be redirected to the subaddress $(i,0)$ when spent. We stress that this is a protocol convenience only, and has no bearing on the cryptography of the subaddress scheme.
+
+
+\section{Analysis}
+\subsection{Linking and wallet determination}
+Because the cryptographic scalar hash function $H_s$ has uniformly distributed output, the set of Bob's possible subaddress components $$\{D_i\}_i = \{B + H_s(a,i)G\}_i$$ is also uniformly distributed \cite{uniform}. This means an adversary in possession of an arbitrary collection of subaddresses $\{(C_i,D_i)\}_i = \{aD_i,D_i\}$ can neither determine the discrete logarithm $a = \log_{C_i} D_i$ nor invert the hash function (which would also require knowledge of $B$). This means Bob's master wallet address is protected, even if the adversary convinces him to generate new subaddresses with chosen indices.
+
+\subsection{Reconstructed wallet}
+If Bob loses access to his local wallet software and restores from the seed, he will not immediately be able to identify transactions destined for his subaddresses, as he would need access to the hash table. To reconstruct the table without missing any likely subaddresses, Bob chooses two lookahead values, $L_M$ and $L_m$. He generates the hash table using major indices $i \leq L_M$ and minor indices $j \leq L_m$ (for each major index). After scanning transactions using the initial table, Bob repeats this process, ensuring he has generated hash entries $L_M$ past the highest major index of any transaction, and $L_m$ past the highest minor index within each major index. Provided used subaddresses do not fall beyond these lookahead values in any transactions, Bob will recover the necessary hash entries.
+
+\subsection{Mixed-type transactions}
+Suppose that Alice's wallet software had one too many glasses of cryptocognac, and formats a transaction incorrectly. In particular, suppose Alice produces the transaction public key $R = sG$ (instead of $R = sD$) but continues to compute the output public key as $P = H_s(sC_i) + D_i$. That is, the transaction is now of ``mixed type" and is not a correct subaddress transaction.
+
+In this case, the transaction public key no longer contains information about the subaddress destination, and Bob cannot use a single scan to detect this transaction. Indeed, his wallet software will fail to recognize that the mixed-type transaction is directed at him. However, if Bob suspects that this situation has arisen, he can iterate through his subaddress indices and compute
+$$P - H_s(a[b+H_s(a,j)]R)$$
+for each $j$ that he has used to generate a subaddress. For $j = i$, the result is guaranteed to be $D_i$. This means that Alice's error can be detected if Bob performs such a linear scan, and Bob can still recover the private key needed to spend his money. The tradeoff is that Bob loses the ability to perform single transaction scans, so he may choose to have his wallet software complete a linear scan every so often if he is concerned about mixed-type transactions.
+
+\subsection{Secret view key}
+It is not possible to provide view access to a third party selectively to only particular subaddresses under the assumption of uniformly distributed secret keys. If Charlie receives Bob's view key $a$ and one hash table entry $D_i \mapsto i$, he computes the master wallet address component $B = D_i - H_s(a,i)G$. If Bob does not choose his subaddress indices at random, Charlie can easily reconstruct other hash table entries using low indices that are likely also subaddresses Bob has used:
+$$D_j = B + H_s(a,j)G$$
+In order to keep other transactions private so Charlie cannot view them, Bob must create a new master wallet and ensure Charlie does not have access to its secret view key.
+
+\subsection{Secret spend key}
+Similarly, it is not possible to provide a third party with the ability to selectively spend funds from a particular subaddress if the secret keys are uniformly distributed. To spend funds from any subaddress, Bob needs both master wallet secret keys $a$ and $b$, as well as the subaddress index. Revealing this information to Charlie would allow him to spend funds sent to any subaddress to which he knows (or can otherwise determine) the index. Of course, the correct way to do this is for Bob to send funds to Charlie's wallet or subaddress, just as with a standard wallet setup.
+
+\subsection{Efficiency}
+Construction of a new subaddress requires a trivial number of elliptic curve operations and is negligible since this operation is performed only as needed.
+
+Sending to a subaddress requires the same number of operations as an equivalent traditional transaction to a standard wallet address. However, instead of computing the transaction key $R = rG$ using the common basepoint in a traditional transaction, Alice instead computes the key as $R = sD$ using the subaddress basepoint; indeed, Alice does not even know the transaction secret key in this case! This means she cannot precompute the transaction key without knowing the desired recipient's subaddress. In practice, this is not an issue. Computation of the output public key is precisely analogous to the traditional case.
+
+Using a standard wallet, Bob would check a transaction against his master wallet secret view key by applying one hash-to-scalar operation, two elliptic curve scalar multiplications, and one elliptic curve point addition (where the hash time is negligible). In the present scheme, Bob must apply the same number of equivalent operations, with the point addition replaced with point subtraction. There is an additional hash lookup for each transaction, but this scales in constant time with the number of generated subaddresses. This is in stark contrast to the use of multiple wallet addresses, where each transaction must be separately checked against each secret view key.
+
+We therefore conclude that scanning incoming (correctly formatted) transactions for ownership by an arbitrary number of subaddresses is no greater than scanning for ownership by a single standard wallet address. This reduces the otherwise linear scaling of scanning for multiple standard wallet addresses to constant time in the subaddress case.
+
+
+\section{Conclusions}
+We have presented brief documentation of a subaddress scheme, an efficient alternative to maintenance of multiple wallet addresses. Under the standard CryptoNote wallet implementation in Monero, Bob must publish separate wallet addresses if he wishes to keep them unlinkable from the perspective of a third party or adversary. However, this approach requires Bob (or another holder of his secret view key) to check every incoming transaction against each of his addresses.
+
+The proposed scheme allows Bob to use a single master wallet address to efficiently generate as many subaddresses as he wishes. An adversary can neither determine if two subaddresses are generated from the same master wallet address, nor identify the parent address. Bob need only maintain a local private hash table that links subaddresses to the scalar index used to generate them.
+
+Transactions to a subaddress require only a minor change to the existing transaction protocol. Multiple outputs are supported, and the change output of a transaction from Alice to Bob can be directed to either Alice's master wallet address or to a subaddress of her choice. When examining incoming transactions, Bob performs only a single verification for each transaction regardless of the number of subaddresses he maintains, using his local hash table to recover the corresponding transaction private key.
+
+Unlinkable subaddresses represent an efficient and secure solution to the problem of multiple wallet addresses, allowing users to determine how their wallets are presented to others and the level of privacy they desire.
+
+\bibliographystyle{plain}
+\bibliography{main}
+
+\end{document}

publications/bulletins/MRL-0006-subaddy/mrl.cls

@@ -0,0 +1,43 @@
+\ProvidesClass{mrl}
+\LoadClass{article}
+\usepackage{amsmath,amssymb,amsthm}
+\usepackage[top=1in,bottom=1in,right=1in,left=1in]{geometry}
+\usepackage{color}
+\usepackage{graphicx}
+\usepackage{hyperref}
+
+\definecolor{bloo}{rgb}{0,0.2,0.4}
+\renewcommand*{\thefootnote}{\fnsymbol{footnote}}
+\linespread{1.2}
+
+\renewcommand\title[1]{\def\@title{#1}}
+\let\@title=\@empty
+
+\newcommand\authors[1]{\def\@authors{#1}}
+\let\@authors=\@empty
+
+\newcommand\affiliations[1]{\def\@affiliations{#1}}
+\let\@affiliations=\@empty
+
+\renewcommand\date[1]{\def\@date{#1}}
+\let\@date=\@empty
+
+\newcommand\ident[1]{\def\@ident{#1}}
+\let\@ident=\@empty
+
+\newcommand\type[1]{\def\@type{#1}}
+\let\@type=\@empty
+
+\AtBeginDocument{
+\hfill\includegraphics[width=100px]{logo.png}
+\newline
+\noindent\colorbox{bloo}{\parbox{\textwidth}{{\sffamily\color{white}\@type \hfill \@ident}}}
+\vskip 10pt
+\noindent{\Large\@title}
+\vskip 5pt
+\noindent{\@authors}
+\newline
+\noindent{\@affiliations}
+\newline
+\noindent{\@date}
+}

publications/bulletins/in-prog/MRL-9999-lrtm-schemes/biblio.bib

@@ -0,0 +1,127 @@
+@article{nakamoto2008bitcoin,
+  title={{B}itcoin: {A} peer-to-peer electronic cash system},
+  author={Nakamoto, Satoshi}
+}
+
+@article{noether2016ring,
+  title={Ring confidential transactions},
+  author={Noether, Shen and Mackenzie, Adam and others},
+  journal={Ledger},
+  volume={1},
+  pages={1--18},
+  year={2016}
+}
+
+@inproceedings{liu2004linkable,
+  title={Linkable spontaneous anonymous group signature for ad hoc groups},
+  author={Liu, Joseph K and Wei, Victor K and Wong, Duncan S},
+  booktitle={ACISP},
+  volume={4},
+  pages={325--335},
+  year={2004},
+  organization={Springer}
+}
+
+@article{rivest2001leak,
+  title={How to leak a secret},
+  author={Rivest, Ronald and Shamir, Adi and Tauman, Yael},
+  journal={Advances in Cryptology, ASIACRYPT 2001},
+  pages={552--565},
+  year={2001},
+  publisher={Springer}
+}
+
+@article{abe20021,
+  title={1-out-of-n signatures from a variety of keys},
+  author={Abe, Masayuki and Ohkubo, Miyako and Suzuki, Koutarou},
+  journal={Advances in Cryptology, Asiacrypt 2002},
+  pages={639--645},
+  year={2002},
+  publisher={Springer}
+}
+
+@misc{van2013cryptonote,
+  title={Cryptonote v 2. 0},
+  author={van Saberhagen, Nicolas},
+  year={2013}
+}
+
+@inproceedings{pointcheval1996security,
+  title={Security proofs for signature schemes},
+  author={Pointcheval, David and Stern, Jacques},
+  booktitle={Eurocrypt},
+  volume={96},
+  pages={387--398},
+  year={1996},
+  organization={Springer}
+}
+
+@inproceedings{ohta1998concrete,
+  title={On concrete security treatment of signatures derived from identification},
+  author={Ohta, Kazuo and Okamoto, Tatsuaki},
+  booktitle={Annual International Cryptology Conference},
+  pages={354--369},
+  year={1998},
+  organization={Springer}
+}
+
+@inproceedings{bresson2002threshold,
+  title={Threshold ring signatures and applications to ad-hoc groups},
+  author={Bresson, Emmanuel and Stern, Jacques and Szydlo, Michael},
+  booktitle={Annual International Cryptology Conference},
+  pages={465--480},
+  year={2002},
+  organization={Springer}
+}
+
+@inproceedings{bender2006ring,
+  title={Ring signatures: Stronger definitions, and constructions without random oracles},
+  author={Bender, Adam and Katz, Jonathan and Morselli, Ruggero},
+  booktitle={TCC},
+  volume={6},
+  pages={60--79},
+  year={2006},
+  organization={Springer}
+}
+
+@article{scozzafava1993uniform,
+  title={Uniform distribution and sum modulo $m$ of independent random variables},
+  author={Scozzafava, Paola},
+  journal={Statistics \& probability letters},
+  volume={18},
+  number={4},
+  pages={313--314},
+  year={1993},
+  publisher={Elsevier}
+}
+
+@misc{maxwell2015borromean,
+  title={Borromean ring signatures},
+  author={Maxwell, Gregory and Poelstra, Andrew},
+  year={2015}
+}
+
+@article{bonehthreshold,
+  title={Threshold Cryptosystems From Threshold Fully Homomorphic Encryption},
+  author={Boneh, Dan and Gennaro, Rosario and Goldfeder, Steven and Jain, Aayush and Kim, Sam and Rasmussen, Peter MR and Sahai, Amit}
+}
+
+@article{shamir1979share,
+  title={How to share a secret},
+  author={Shamir, Adi},
+  journal={Communications of the ACM},
+  volume={22},
+  number={11},
+  pages={612--613},
+  year={1979},
+  publisher={ACm}
+}
+
+@incollection{shamir1981mental,
+  title={Mental poker},
+  author={Shamir, Adi and Rivest, Ronald L and Adleman, Leonard M},
+  booktitle={The mathematical gardner},
+  pages={37--43},
+  year={1981},
+  publisher={Springer}
+}

publications/bulletins/in-prog/MRL-9999-lrtm-schemes/main.bib

@@ -0,0 +1,30 @@
+@misc{cryptonote,
+title = {CryptoNote v2.0},
+author = {van Saberhagen, Nicolas},
+year = {2013}
+}
+
+
+@misc{van2013cryptonote,
+  title={Cryptonote v 2. 0},
+  author={van Saberhagen, Nicolas},
+  year={2013}
+}
+
+@misc{pr,
+title = {Subaddresses},
+author = {Monero project},
+howpublished = "\url{https://github.com/monero-project/monero/pull/2056}",
+note = {GitHub pull request \#2056}
+}
+
+@article{uniform,
+  title={Uniform distribution and sum modulo m of independent random variables},
+  author={Scozzafava, Paola},
+  journal={Statistics \& Probability Letters},
+  volume={18},
+  number={4},
+  pages={313--314},
+  year={1993},
+  publisher={Elsevier}
+}

publications/bulletins/in-prog/MRL-9999-lrtm-schemes/mrl.cls

@@ -0,0 +1,43 @@
+\ProvidesClass{mrl}
+\LoadClass{article}
+\usepackage{amsmath,amssymb,amsthm}
+\usepackage[top=1in,bottom=1in,right=1in,left=1in]{geometry}
+\usepackage{color}
+\usepackage{graphicx}
+\usepackage{hyperref}
+
+\definecolor{bloo}{rgb}{0,0.2,0.4}
+\renewcommand*{\thefootnote}{\fnsymbol{footnote}}
+\linespread{1.2}
+
+\renewcommand\title[1]{\def\@title{#1}}
+\let\@title=\@empty
+
+\newcommand\authors[1]{\def\@authors{#1}}
+\let\@authors=\@empty
+
+\newcommand\affiliations[1]{\def\@affiliations{#1}}
+\let\@affiliations=\@empty
+
+\renewcommand\date[1]{\def\@date{#1}}
+\let\@date=\@empty
+
+\newcommand\ident[1]{\def\@ident{#1}}
+\let\@ident=\@empty
+
+\newcommand\type[1]{\def\@type{#1}}
+\let\@type=\@empty
+
+\AtBeginDocument{
+\hfill\includegraphics[width=100px]{logo.png}
+\newline
+\noindent\colorbox{bloo}{\parbox{\textwidth}{{\sffamily\color{white}\@type \hfill \@ident}}}
+\vskip 10pt
+\noindent{\Large\@title}
+\vskip 5pt
+\noindent{\@authors}
+\newline
+\noindent{\@affiliations}
+\newline
+\noindent{\@date}
+}

publications/bulletins/in-prog/MRL-9999-lrtm-schemes/thresh.tex

@@ -0,0 +1,507 @@
+\documentclass{mrl}
+\usepackage{enumerate}
+\usepackage{todo}
+
+\theoremstyle{definition}
+\newtheorem{theorem}{Theorem}[subsection]
+\newtheorem{defn}[theorem]{Definition}
+\newtheorem{disc}[theorem]{Remark}
+
+
+
+\title{Ring Threshold Multisignature Schemes and Security Models}
+\authors{Brandon Goodell\footnote{\texttt{surae.noether@protonmail.com}} and Sarang Noether\footnote{\texttt{sarang.noether@protonmail.com}}}
+\affiliations{Monero Research Lab}
+\date{\today}
+
+\type{RESEARCH BULLETIN}
+\ident{MRL-XXXX}
+
+\begin{document}
+
+\begin{abstract}
+This research bulletin extends \cite{noether2016ring} by constructing a $t$-of-$n$ threshold multi-layered linkable spontaneous anonymous group signature scheme ($t$-of-$n$ MLSAG) in the same style as the LSAG schemes put forth by \cite{liu2004linkable}. %We present security models for this scheme, present security proofs in those models, describe an implementation, and explain some use-cases for the scheme in cryptocurrencies.
+\end{abstract}
+
+\section{Introduction and Background}
+
+Collaboration to construct, compute, share, and leak a secret is a central goal in the construction of cryptographic systems. Although the idea of constructing a shared secret has a very long history, modern secret sharing through threshold cryptosystems found its most successful footing in \cite{shamir1979share}. These and related ideas (as in \cite{shamir1981mental}) formed the historical foundation of secure multi-party computation, threshold encryption, and threshold authentication. For example, threshold multisignatures play a critical role in multi-factor message authentication in general and off-chain transactions for cryptocurrencies in particular, e.g.\ the Bitcoin Lightning Network.  For a more modern treatment of threshold cryptosystems, see \cite{bonehthreshold}.
+
+Ring signatures are digital signatures that are verifiably signed by one of possibly several public keys (\textit{ring members}), and can play a critical role in promoting signer during message authentication. It is therefore natural to apply the notion of threshold cryptosystems to ring signatures for implementation in cryptocurrencies, resulting in signer-ambiguous threshold multisignatures. 
+
+A $t$-of-$N$ threshold multisignature scheme specifies sets containing $N$ public keys and thresholds $t$ such that any subset with at least $t$ elements may collaborate to fashion a signature. A \textit{ring threshold multisignature} (RTM) scheme allows any set of $N$ keys to collaborate as a coalition of signers with threshold $t$. The coalition is assigned a shared public key $X_{\texttt{shared}}$ such that any $t$ coalition members may collaborate to fashion a ring signature with $X_{\texttt{shared}}$. The ring of signatories $\mathcal{Q}$ contains the key $X_{\texttt{shared}}$, but an adversary cannot determine which element of $Q$ computed the signature. This may be made into a \textit{linkable} signature scheme using key images, and this may be made into a \textit{one-time} signature scheme by inserting a one-time key exchange step between signing and the construction of $X_{\texttt{shared}}$. A one-time signature scheme inserts a barrier between user key pairs and one-time signature key pairs. Due to this utility, one-time ring signature schemes enjoy application in many cryptocurrency protocols. 
+
+A usual digital signature scheme is a $1$-of-$1$ multisignature scheme, so we can regard all keys as shared public keys (just perhaps with a coalition of only one member). A $1$-of-$N$ multisignature scheme can be trivially accomplished by handing out the same private key to each coalition member. 
+
+If the number of users cooperating in the construction of a signature is not secret, naive multisignature schemes can be constructed from any signature scheme (ring signature or otherwise) by simply requiring each participating user to present a separate signature. These signatures can be combined into a list to obtain signature sizes that vary according to the number of signers, or can be combined in more sophisticated ways that are more private (see \cite{bonehthreshold}).  If a user does not desire to reveal to an adversary how many devices were used for some multi-factor authentication, it should be difficult for an adversary to determine the size of a coalition behind some shared public key. We investigate some security definitions for a one-time linkable ring threshold multisignature (OT-LRTM) scheme.
+
+%This property cannot be satisfied if the adversary has corrupted any public key in the coalition. If some coalition member for $X$, say $X^{\prime}$, is a shared $t^{\prime}$-of-$N^{\prime}$ public key, this means that if the adversary has corrupted $t^{\prime}$ or more members of the coalition for $X^{\prime}$, then coalition-indistinguishability is impossible. Thus we investigate the notion of \textit{subthreshold corruption oracle access}.
+
+%Moreover, for multifactor authentication purposes, $(N-1)$-of-$N$ and $N$-of-$N$ schemes are of particular interest. Due to this, we consider only $t$-of-$N$ threshold ring signatures with $N-1 \leq t \leq N$, with $t > 1$, and with $N > 1$.
+
+
+
+\subsection{Our Contribution}
+
+
+We consider a formal definition of one-time linkable ring threshold multisignature (OT-LRTM) schemes. We introduce the definition of \textit{coalition-indistinguishable keys}, \textit{signer ambiguity}, and \textit{existential unforgeability} in these schemes. We describe a modified implementation of $t$-of-$N$ linkable ring threshold multisignature (under the restriction $N-1 \leq t \leq N$ with $2 
+\leq t$ and $2 \leq N$) first described by previous Monero Research Lab (MRL) contributors Shen Noether in \cite{noether2016ring} and implemented for use in Monero by contributor \texttt{Luigi}. We prove that this implementation satisfies our security definitions. Lastly, we remark on some recent advancements in thresholdizing cryptoschemes from \cite{bonehthreshold} using different security definitions.
+
+
+\subsection{Notation and Prerequisites}
+
+We let $\mathbb{G}$ be a group with prime order $\mathfrak{q}$ and we let $G \in \mathbb{G}$ denote a commonly-known point with order $\mathfrak{q}$. Let $H_p$ and $H_s$ be secure cryptographic hash-to-point and hash-to-scalar functions. Denote the user and transaction key spaces, respectively, as $\mathcal{K}_{\texttt{user}}, \mathcal{K}_{\texttt{txn}}$. In implementations involving cryptocurrencies, there exists a function $\texttt{dest}:\mathcal{K}_{\texttt{txn}} \to \mathcal{K}_{\texttt{user}}$ describing the user key pair to whom a certain transaction key pair is addressed. For any transaction key pair $(q,Q) \in \mathcal{K}_{\texttt{txn}}$, we say $\texttt{dest}(q,Q)$ is the \textit{destination} user key pair for $(q,Q)$. %We sometimes write $Q$ as $Q_X$ to emphasize the destination user key $X$ associated with the transaction key $Q$.
+%We denote the message space $\mathcal{M}=\left\{0,1\right\}^*$. We let $\mathbb{G}$ be an additive group with prime order $q$ an an arbitrary generator $G$. We denote $H_{\mathcal{X},\mathcal{Y}}(-)$ as a cryptographic hash function from the space $\mathcal{X}$ to $\mathcal{Y}$. For example $H_{\mathbb{G},\mathbb{Z}_q}(-)$ is a cryptographic point-to-scalar function. We assume that any two hash functions $H_{\mathcal{X},\mathcal{Y}}(-)$ and $H_{\mathcal{X}^{\prime},\mathcal{Y}^{\prime}}(-)$ are statistically independent.
+
+
+\section{MLSAG and Straightforward Threshold Set-ups}
+
+
+We briefly describe LSAG ring signatures in the sense of \cite{liu2004linkable} and their MLSAG variant as used in Monero, and then a straightforward implementation of an LRTM scheme (which is one-time if the transaction keys are one-time). 
+
+\subsection{MLSAGs}
+
+A user with user key pair $(y,Y)$ wishes to spend an old transaction output with private-public transaction key pair $(q,Q) \in \mathcal{K}_{\texttt{txn}}$ such that $\texttt{dest}(q,Q) = (y,Y)$. With a destination user key $X$, the user computes a new transaction public key $Q*$, constructs an appropriate message $M$, computes the key image $J = qH_p(Q)$, and selects a ring of public transaction keys $\mathcal{Q}=\left\{Q_1, \ldots Q_L\right\}$ such that, for a secret distinguished index $k$, $Q_{k}=Q$. For each $i=1,\ldots,L$, the signer computes an elliptic curve point from the $i^{th}$ ring member public key  as $H_i := H_{p}(Q_i)$. The signer computes $M^* = (M, J, Q^*, \mathcal{Q})$.
+
+The signer selects a random secret scalar $u$, computes an initial temporary pair of points $uG$ and $uH_{k}$, and computes an initial commitment $c_{k+1} := H_{s}(M^*,uG, uH_k)$. The signer sequentially proceeds through indices $i=k+1, k+2, \ldots, L, 1, 2, \ldots, k-1$  by selecting a random scalar $s_i$, computing the next pair of points $s_iG + c_i Q_i$ and $s_i H_i + c_i J$, and computes the next commitment $c_{i+1}:=H_{s}(M^*,s_i G + c_i Q_i, s_i H_i + c_i J)$. The signer continues proceeding through the set of keys until commitments $c_i$ have been computed for each $i=1, \ldots, L$. The signer then computes $s_{k}:=u - c_{k}q_{k}$. 
+
+Now $\sigma=(c_1, s_1, \ldots, s_L)$ is the signature on $M^*$. A verifier checks this $M^*$ signed by at least one member of $\mathcal{Q}$ in the following way. Given a message $M^*$ and signature $\sigma$, the verifier parses $M^* = (M,J,Q^*,\mathcal{Q})$ and $\sigma = (c_1, s_1, \ldots, s_L)$. For each $i=1,2,\ldots, L$, the verifier computes $z_{i} = s_i^* G + c_i^* Q_i$ and $z_{i}^{\prime} = s_i^* H_i + c_i^* J^*$ and uses these to compute the $(i+1)^{th}$ commitment $c_{i+1} = H_{s}(M^*, z_i, z^{\prime}_i)$. After computing $c_2, c_3, \ldots, c_L, c_1$, the verifier approves of the signature if and only if $c_1 = c_1^*$. A verifier can check against double spends by comparing the key images of two signature-tag pairs. 
+
+\begin{disc}
+The MLSAG generalization, where transaction keys are represented by vectors, is straightforward. With transaction keys $\underline{q}=(q_1,\ldots,q_w)$, each component of $\underline{q}$ is used to generate a temporary pair of points starting with $u_jG$, $u_j H_k$ and then $s_{j,i} G + c_{i} Q_{j,i}$, $s_{j,i} H_{j,i} + c_{i} J$, providing the associated commitments
+\[c_{i+1}:=H_{s}\left(M^*,\left\{(s_{j,i} G + c_i Q_{j,i}, s_{j,i} H_{j,i} + c_i J)\right\}_{j=1}^{w}\right).\]
+\end{disc}
+
+
+\begin{disc}
+Note that user keys are not used above except as a destination for the transaction key. Anyone with a destination public user key in mind and knowledge of a transaction private key may fashion a signature like the one above. In the reference CryptoNote protocol \cite{van2013cryptonote}, the private transaction key $q$ associated to some public transaction key $Q$ is only feasibly computable by a user who knows the private destination user key in $\texttt{dest}(q,Q)$ or by an adversary who can solve the discrete logarithm problem.
+\end{disc}
+
+\subsection{Extending to Threshold Signatures} \label{naiveImplement}
+
+%Note that a $1$-of-$N$ threshold signature scheme may be accomplished by simply handing out an identical set of keys to $N$ individuals: whoever decides to use them first will be able to fashion a signature. We consider this a degenerate case. On the other hand, a $1$-of-$1$ signature scheme is a usual signature scheme, as we mentioned. So we only consider $t$-of-$N$ signatures with $2 \leq t \leq N$.
+
+Generally, we wish to allow a coalition of (distinct) public user keys $C=\left\{X_{1}, X_{2}, \ldots, X_{N}\right\} \subseteq \mathcal{K}_{\texttt{user}}$ (where each $X_i = x_iG$) to collaboratively fashion a shared public user key $X_{\texttt{shared}}$ such that, for any transaction key pair $(q,Q) \in \mathcal{K}_{\texttt{txn}}$ such that $\texttt{dest}(q,Q) = X_{\texttt{shared}}$, any subset of at least $t$ of the users in $C$ can collaborate to fashion a signature on a message $M$ corresponding to public transaction key $Q$. Certainly we wish that no member of $C$ reveal their own private user key $x_i$, but moreover we wish that coalition members cannot feasibly learn the private transaction key $q$. 
+
+In the $N$-of-$N$ case, we may use CryptoNote-styled user and transaction keys to see an example implementation. For this example, we assume user private-public key pairs $(x,X)$ take the form $x=(a,b)$ for some scalars $a$, $b$ and $X=(A,B)$ where $A=aG$ and $B=bG$. The private-public transaction key pair $(q,Q)$ takes the form $Q=(S,P)$, $q=(s,p)$ where $s$ is a scalar, $S=sG$, $p=H_s(aS)+b$, and $P=pG$\footnote{In the CryptoNote whitepaper, the private key $p$ was denoted $x$, the random scalar $s$ wa denoted $r$, and the random point $S=sG$ was denoted $R=rG$. The point $S=sG$ (originally denoted $R$) in the original CryptoNote whitepaper was the \textit{public transaction key}, the value $P$ was the \textit{public output key}. This allowed for many outputs (each with their own signature) to have a common transaction output key. However, in MLSAG, we only use one output per signature anyway, so the value in distinguishing between $S$ as a transaction key and $P$ as an output key is diminished.}.
+
+Given a message $M$, the coalition of user keys $C$ compute their shared public key as $X_{\texttt{shared}} := (\sum_i A_i, \sum_i B_i)$, which is published. The coalition members secretly compute and share $a^*=\sum_i a_i$ and share this secret view key among themselves. With a destination user key $X$, the coalition computes a new transaction public key $Q^*$. Assume $(q,Q)=((s,p),(S,P))$ is a transaction key pair such that $\texttt{dest}(q,Q) = X_{\texttt{shared}}$. The coalition $C$ selects a ring of public transaction keys $\mathcal{Q} = \left\{Q_1, Q_2, \ldots, Q_L\right\}$ such that $Q = Q_{k}$ for some secret index $k$.  For each $j=1, \ldots, N$, the $j^{th}$ coalition member in $C$ computes a partial key image $J_j = b_j H_p(Q)$, picks a random secret scalar $u_j$, and computes $H_i = H_{p}(Q_i)$ for each $Q_i \in R$. The coalition $C$ computes the key image $J = H_s(a^* S) + \sum_j J_j$. The coalition constructs an appropriate message $M^*=(M,J,Q^*,\mathcal{Q})$.
+
+The coalition computes the points $u_{k} G = \sum_j u_{j} G$ and $u_{k} H_{k}= \sum_j u_{j} H_{k}$. The coalition $C$ decides upon random values $s_{k+1}, \ldots, s_{L}, s_1, \ldots, s_{k-1}$. Any member in $C$ may compute the commitments 
+\begin{align*}
+c_{k+1} :=& H_{s}(M^*,  u_k G, u_k H_k) \text{ and}\\
+c_{i+1} :=& H_{s}(M^*,  s_{i} G + c_i Q_i, s_{i} H_i + c_i J)\text{ for }i=k+1, \ldots, k-1.
+\end{align*}
+All coalition members then use $c_k$ to compute their personal $s_{k,j} = u_j - c_{k} b_j$. The signers share their $s_{k,j}$ with the other signers. Any threshold member may then compute the value $s_{k} = (\sum_j s_{k,j}) - c_k H_s(a^* S)$ and publishes as before. Any user may verify this signature corresponds to the $N$-of-$N$ shared public key $X_{\texttt{shared}}$ using the same method as above.
+
+This set-up extends naturally to an $(N-1)$-of-$N$ set-up. As before, a set of $N$ public keys $\left\{X_{1}, X_{2}, \ldots, X_{N}\right\}$ form a coalition. Each pair of users has a shared secret scalar $z_{i,j} = H_{s}(x_i X_j)$ with associated point $Z_{i,j} = z_{i,j}G$. There are $\frac{N(N-1)}{2}$ such pairs; if any $N-1$ members get together, all of the associated shared secrets are known. Hence, we may simply instantiate the $(N-1)$-of-$N$ threshold as an $N^*$-of-$N^*$ set-up with $N^* = \frac{N(N-1)}{2}$. All values $Z_{i,j}$ are necessary to compute the shared public user key $Z_{\texttt{shared}}$, and all values of $z_{i,j}$ are necessary to fashion a signature with a public transaction key $Q$ with $\texttt{dest}(Q)=Z_{\texttt{shared}}$.
+
+\begin{disc}
+Note that members in $C$ do not directly learn the private transaction key $q=H_s(a^* S)+\sum_j b_j$ and do not directly reveal their own private \textit{spend} keys $b_j$ (although they collaborate to compute their shared private view key $a^*$. Assuming at least one contributing user key in $C$ was honestly generated from a uniform random scalar, an adversary who has learned a public threshold address cannot determine the number of summands contributing to it, let alone determine the summands.  \end{disc}
+
+%Coalition members certainly do not want to reveal their secret keys during participation, but dually, coalitions may not want the fact that an address has been collaboratively fashioned to be publicized. We should prefer, then, that implementations produce keys and signatures that are indistinguishable by an adversary from a usual signature scheme. We discuss this in more detail later.
+\begin{disc}\label{remark:recursion}
+Note that the same basic extension works for coalitions containing coalitions also: each time a member of a coalition must make a decision in a signing protocol, the coalition may simply compute a sum. For example, when the $j^{th}$ coalition member computes the partial key image $J_j$, if this coalition member is some sub-coalition, then each member of the sub-coalition can compute their own partial key image $J_{j,k}$ and the sub-coalition can report the sum $J_j = \sum_k J_{j,k}$. In this manner, signatures involving nested coalitions may be executed recursively. We elaborate on this in Section \ref{sec:otlrtm}.
+\end{disc}
+
+\begin{disc}\label{hashed-keys}
+Note that an adversary with knowledge of some set of public keys can compute the sums of all subsets to brute-force test whether a certain user key $X$ is a threshold key. Moreover, if the computation of sums is done inappropriately, the summands may be accidentally revealed. Using hash functions and encrypt-then-authenticate communication, we may resolve these problems.
+
+Consider modifying the $N$-of-$N$ implementation by having coalition members select secret scalars $\mu_j$ associated with the threshold $t$ and coalition $C$, e.g.:
+\[\mu_j = H_s(\text{``multisig constant for escrow at local coffee shop''}, \texttt{secret salt})\] 
+Now merely require that participating members not use their private user keys in the construction of their shared user key pair, but instead the $i^{th}$ coalition member selects a constant $\mu_i$ associated with their coalition and instead uses $x^*_i = H(x_i, \mu_i)$ as their private key (or in the $(N-1)$-of-$N$ case, computing $z^*_{i,j} = H_s(x_i^* X_j^*)$ instead of $z_{i,j} = H_s(x_i X_j)$ and communicating the points $Z^*_{i,j}$ to the coalition). In the case of CryptoNote keys of the form $((a,b), (A,B))$, select constants $\mu_j, \gamma_j$ and set $a^* = H_s(a, \mu_j)$, $b^*=H_s(b,\gamma_j)$.
+
+With this modification, an adversary cannot use strictly public information to determine if a certain key is a threshold key or not. The possibility remains that the adversary may overhear the associated public points $X^*_i$ (or $Z^*_{i,j}$) being communicated within the coalition, allowing the adversary to fall back on the brute force approach again. Hence, the points $X^*_i$ (or $Z^*_{i,j}$) should be communicated with a secure encrypt-then-authenticate scheme. Note that either step alone (hashing, then encrypt-then-authenticating) is insufficient to prevent the adversary from using brute force. Also note that the above does not take into account the possibility of malicious coalition members.
+\end{disc}
+
+
+
+\section{Security Models}
+
+%In this section we present definitions we use later on. Any signature scheme requires unforgeability. Moreover, a ring signature scheme requires signature ambiguity. In a threshold multisignature scheme, coalitions of users collaborate to generate new threshold keys from sets of old keys and to generate signatures on messages using those threshold keys. A linkable signature
+
+\subsection{One-Time Linkable Ring Threshold Multisignatures}\label{sec:otlrtm}
+
+We begin by defining a one-time linkable ring threshold multisignature (OT-LRTM) scheme. A central idea to our security models is that a coalition of user keys may be merged into a new user key, which may then be again merged with other user keys. 
+
+
+\begin{defn}{[One-Time Linkable Ring Threshold Multisignature Scheme]}\label{OT-LRTM} A one-time linkable ring threshold multisignature scheme is a set of PPT algorithms (\texttt{UserKeyGen}, \texttt{Merge}, \texttt{TxnKeyGen},  \texttt{Sign}, \texttt{Verify}, \texttt{Link}) that, respectively, generates usual private-public keypairs for users, generates public transaction keys, merges user keys into new shared user keys, fashions signatures on messages given a ring of public transaction keys, verifies signatures, and links signatures. Formally:
+\begin{enumerate}[(i)]
+    \item $\texttt{UserKeyGen}(1^\lambda)$ outputs a random user key pair $(x,X)$ called a \textit{$1$-of-$1$ user key pair} where $x$ is a private user key with associated public user key $X$.
+    
+    \item $\texttt{Merge}(t,C)$ takes as input a positive integer (threshold) $t$ and coalition of private-public user keypairs $C=\left\{(x_1,X_1), (x_2,X_2), \ldots, (x_n,X_N)\right\}$ and outputs a public user key $X_{t,C}$ called a \textit{$t$-of-$N$ user key pair} or a \textit{shared user key pair}.
+    
+    \item $\texttt{TxnKeyGen}(1^\lambda, X)$ takes as input a public user key $X$ called the \textit{destination key}. A one-time random private-public transaction key pair $(q_X,Q_X)$ is generated. $\texttt{TxnKeyGen}$ outputs $Q_X$.
+    
+    %\item $\texttt{ImageGen}(1^\lambda, Q, y)$ takes as input a public transaction key $Q$ with a set of private user keys $y = \left\{x_1, \ldots\right\}$ and outputs a point $J_Q$ called the \textit{key image} for the private transaction key $q$ and outputs $J_Q$.
+    
+    \item $\texttt{Sign}(M,X,\mathcal{Q},k, y)$ takes as input message $M$, a destination user key $X$, ring of public transaction keys $\mathcal{Q}=\left\{Q_1, \ldots, Q_L\right\}$, secret index $k$, and a set of private user keys $y$. A transaction key $Q^*$ addressed to $X$ is computed $Q^* \leftarrow \texttt{TxnKeyGen}(1^\lambda, X)$, a key image $J$ is generated, and a modified message $M^*=(M, J, Q^*, \mathcal{Q})$ is constructed. $\texttt{Sign}$ outputs $(\sigma, M^*)$.
+    
+    \item $\texttt{Verify}(M^*,\sigma)$ takes as input a message $M^* = (M, J, Q^*, \mathcal{Q})$  and a signature $\sigma$, and outputs a bit $b \in \left\{0,1\right\}$. 
+    
+    \item $\texttt{Link}((M^*_0, \sigma_0), (M^*_1, \sigma_1))$ takes as input two signatures on two messages and outputs a bit $b \in \left\{0,1\right\}$.
+\end{enumerate}
+\end{defn}
+
+ Note that a $1$-of-$1$ user key may be regarded as a ``usual'' user key in a one-time linkable ring signature scheme. In this way, we may regard all user keys as $t$-of-$N$ shared user keys by simply regarding $1$-of-$1$ keys as having a coalition of a single member. We consider only \textit{restricted} OT-LRTM schemes where $\texttt{Merge}$ is modified such that (i) if $t=1$ and $\left|C\right| = 1$, then $\texttt{Merge}$ returns the public user key in $C$, (ii) if the inequalities $2 \leq t$ and $2 \leq N$ and $N-1 \leq t \leq N$ do not hold then $\texttt{Merge}$ outputs $\bot$ instead of a key.
+
+\begin{defn}
+Assume for each $i \in \{0,1\}$ that $M_i$ is an arbitrary message, $X_i$ is an arbitrary $t_i$-of-$N_i$ shared public user key with coalition $C_i$, $\mathcal{Q}_i=\left\{Q_{i,j}\right\}_{j=1}^{\left|\mathcal{Q}_i\right|}$ is an arbitrary ring of public transaction keys with associated secret index $k_i$ such that $\texttt{dest}(Q_{i,k_i}) = X_i$, each $y_i$ is a set of private user keys such that $y_i \subseteq C_i$ and $t_i \leq \left|y_i\right|$, and each signature is generated fairly from $\sigma_i \leftarrow \texttt{Sign}(M_i,X_i,\mathcal{Q}_i,k_i,y_i)$. Further say $M^*_i = (M_i, J_i, Q^*_i, \mathcal{Q}_i)$. We say an OT-LRTM scheme is \textit{complete} if
+\begin{enumerate}[(a)]
+\item $\texttt{VER}(M^*_i,\sigma_i) = 1$ and
+\item if $Q_{i,k_i} = Q_{j,k_j}$ then $\texttt{LNK}((M^*_i, \sigma_i), (M^*_j, \sigma_j))=1$.
+\end{enumerate}
+\end{defn}
+
+
+
+Recall Remark \ref{hashed-keys} and consider the hash-then-encrypt-then-authenticate approach to computing shared public keys. We let $\Pi = (\texttt{UserKeyGen}^*,\texttt{Enc}^*, \texttt{Auth}^*, \texttt{Ver}^*, \texttt{Dec}^*)$ be a secure encrypt-then-authenticate scheme (where $\Pi_{\texttt{enc}} = (\texttt{Gen}^*,\texttt{Enc}^*, \texttt{Dec}^*)$ is a secure encryption sub-scheme and $\Pi_{\texttt{auth}} = (\texttt{Gen}^*,\texttt{Auth}^*, \texttt{Ver}^*)$ is a secure message authentication sub-scheme). Augmenting the implementation of Section \ref{naiveImplement} with $\Pi$ allows the coalition for $X_{\texttt{shared}}$ to compute the appropriate values to participate in the signing of a message in a recursive fashion. 
+
+To see how, note that when the implementation of Section \ref{naiveImplement} is carried out, this $t$-of-$N$ shared public user key $X_{\texttt{shared}}$ must first compute the partial key image, next select a random secret scalar $u_j$, then compute the commitments $c_k$, and finally must compute the values $s_{k,j} = u_j - c_k b_j$, and then finally $s_k = (\sum_j s_{k,j}) - c_k H_s(a^* S)$. Denote the coalition of user key pairs for $X_{\texttt{shared}}=(A^*,B^*)$ as $\left\{((a_{j}, b_{j}), (A_{j}, B_{j}))\right\}$. The coalition for $X_\texttt{shared}$ may use $\Pi$ to share their $(H_s(a_{j} S) + b_{j})\cdot H_p(Q)$ and compute the key image $J = (H_s(a^* S) + \sum_j b_{j}) H_p(Q)$. If some index, say $j$, corresponds to a user key pair $((a_j,b_j),(A_j,B_j))$ that is a $t_j$-of-$N_j$ public key, then the secrets $a_j$ and $b_j$ are not known by the coalition and so the $j^{th}$ share of the key image, $J_j$, must be collaboratively computed by at least $t_j$ coalition members for the shared key $((a_j,b_j),(A_j,B_j))$. Denote the coalition for this key as $\left\{((a_{j,i}, b_{j,i}), (A_{j,i}, B_{j,i}))\right\}_{i=1}^{N_j}$. Each member computes their share, $J_{j,i} = b_{j,i}H_p(Q)$, this sub-coalition uses $\Pi$ to compute $J_j = (H_s(a_{j} S)H_p(Q) +   \sum_i J_{j,i}$, and the sub-coalition outputs $J_j$.
+
+Similarly the random scalar $u_j$ is computed as a sum $u_j = \sum_i u_{j,i}$ using $\Pi$. Now any of these coalition members may compute the commitments $c_k$ and disseminate them to the rest of the coalition with $\Pi$. At that point each member of the coalition may compute their individual $s_{k,j,i} = u_{j,i} - c_k x_{j,i}$ and the coalition may use $\Pi_{\texttt{auth}}$ to compute $s_{k,j} = \sum_i s_{k,j,i}$. In this way, sub-coalitions are simply handled recursively.
+
+\begin{disc} 
+In Definition \ref{threshIndist}, we formalize the notion that keys cannot be feasibly determined by a PPT algorithm to be threshold keys or $1$-of-$1$ keys. If an OT-LTRM scheme is secure under that definition, then it is not feasible for any PPT algorithm to check whether the keys used as input for $\texttt{Merge}$ are $1$-of-$1$, so modifying the straightforward implementation above to prevent recursive formation of coalition keys is not feasible. \end{disc}
+
+
+\subsection{Coalition Indistinguishable Keys} \label{subsec:CIK}
+
+Definition \ref{threshIndist} formalizes the idea that an adversary should not be able to determine information about the input of $\texttt{Merge}$ based on its output except with negligible probability. %Although we focus on restricted OT-LRTM schemes, and where thresholds are bounded by $N-1 \leq t \leq N$, this is a general definition that applies more broadly than the restricted case.  %Definition \ref{threshIndist} emphasizes the idea that the \textit{method of collaboratively fashioning keys} is not easily discernible by an adversary.
+
+\begin{defn}[Coalition Indistinguishable Keys]\label{threshIndist} Let $\mathcal{A}$ be a PPT adversary. Let $N(-)$, $L(-)$ be polynomials.
+\begin{enumerate}[(i)]
+\item A set of user key pairs $S^* \subseteq \mathcal{K}_{\texttt{user}}$ with $\left|S^*\right|=N(\lambda)$ is generated where the $i^{th}$ key pair is $t_i$-of-$N_i$ public user key for some $t_i, N_i$ such that $2 \leq t_i \leq N_i \leq L(\lambda)$. The set of public keys $S = \left\{X_i \mid \exists (x_i, X_i) \in S^*\right\}$ is sent to $\mathcal{A}$.
+
+\item $\mathcal{A}$ outputs $(\tau_0,C_0)$ where $C_0 \subseteq S$, $\tau_0 \in \mathbb{N}$, and $\tau_0 \leq \left|C_0\right|$.
+
+\item A random pair $(\tau_1, C_1)$ is selected where $C_1 \subseteq S$, $\tau_1 \in \mathbb{N}$, $\tau_1 \leq \left|C_1\right|$, $\tau_0 \neq \tau_1$, and $C_1 \neq C_0$. A random bit $b$ is selected. The key $X_{\tau_b,C_b} \leftarrow \texttt{Merge}(\tau_b, C_b)$ is sent to $\mathcal{A}$.
+
+\item $\mathcal{A}$ outputs a bit $b^{\prime}$. This counts as a success if $b=b^{\prime}$.
+\end{enumerate}
+We say an OT-LRTM scheme has Coalition Indistinguishable Keys (CIK) if the adversary can succeed with probability only negligibly more than $1/2$.
+\end{defn}
+
+%We make some remarks on the straightforward $N$-of-$N$ implementation in Section \ref{naiveImplement}. 
+
+
+
+
+ \begin{disc}
+ We may be tempted to strengthen Definition \ref{threshIndist} to take into account corruption oracle access on the part of the adversary. Unfortunately this leads to certain problems with the security definition.   However, by using the hash-then-encrypt-then-authenticate method of computing shared public keys, without knowledge of the values of $\mu_j$, even if the adversary corrupts all the public keys in $S$ and has the ability to compute discrete logs, then $\mathcal{A}$ cannot successfully run $\texttt{Merge}$ for each threshold value $1 \leq t \leq \left|S\right|$ to check the results by hand in comparison against the key $X_{t_b,C_b}$.  Thus, if the participating coalition members keep each $\mu_j$ and $\mu_j G$ secret, then even a very powerful adversary with corruption and discrete log oracle access will still be unable to discern whether some user key is a coalition key or not.
+ \end{disc}
+%In \cite{bender2006ring}, anonymity in ring signatures assumes at least two honest users in each ring, because if the adversary controls all keys except a single key controlled by an honest user, that adversary can certainly identify whether that honest user fashioned a signature!  %The adversary does not even need to know private information to violate coalition indistinguishability. %In fact, by merely knowing the CryptoNote public view key of a set $S$ of $N$ possible signers, an adversary may trivially check if some CryptoNote key pair $(A,B)$ is an $N$-of-$N$ key pair for the coalition $S$. 
+
+%If granted corruption oracle access, any threshold subset of a coalition will also degrade coalition indistinguishability. To see why, assume the adversary is granted access to a corruption oracle and has corrupted a threshold subset of $S$. The adversary will then be able to construct valid signatures without the signing oracle, and will be able to conclude some information about the threshold, allowing for non-negligible success probability in the game of Definition \ref{threshIndist}. 
+
+%Although we cannot strengthen Definition \ref{threshIndist} to take into account corruption by the adversary, 
+\subsection{Signer Ambiguity}
+
+In addition to coalition indistinguishability, we desire the ring signature property of \textit{signer ambiguity}. Variations of security models appear in \cite{bender2006ring}. 
+
+Double-spend protection in Monero relies on a one-time linkable ring signature scheme that is not signer ambiguous with respect to adversarially generated keys according to the definition presented in \cite{bender2006ring}. Indeed, in Monero, $\texttt{Link}$ simply checks if two key images $J_i$ are identical. In this way, the signer ambiguity game falls apart: $\mathcal{A}$ can obtain signature-tag pair $(\sigma_0, J_0)$ on $M_0$ using ring $R_0$ with $Q_{i_0} \in R_0$ and a pair $(\sigma_1, J_1)$ on $M_1$ using ring $R_1$ with $Q_{i_1} \in R_1$. Then, upon receipt of $(\sigma,J)$ in step (v), $\mathcal{A}$ can check if $J=J_0$ or $J=J_1$. The definition may be modified, however, to take key images into account.
+
+
+Let $\mathcal{SO}(-,-,-,-)$ be a signing oracle that takes as input $(M,X,\mathcal{Q},k)$ (a message, a destination public user key, a ring of public transaction keys, and an index $k$) and outputs a valid signature-tag pair $(\sigma, J) \leftarrow \texttt{Sign}(M,X,\mathcal{Q},k,y)$ for some set $y$ of private user keys.
+
+\begin{defn}{[Linkable Signer Ambiguity v. Adversarially Generated Keys]}\label{def:ambig} Let $N(-)$ be a positive polynomial. Let $\mathcal{A}$ be a PPT adversary. Let $\mathcal{A}$ have access to $\mathcal{SO}$. Consider the following game:
+\begin{enumerate}[(i)]
+
+\item A set of user key pairs $S^* \subseteq \mathcal{K}_{\texttt{user}}$ is selected with $\left|S^*\right| = N(\lambda)$. The public keys in $S^*$ are sent to $\mathcal{A}$.
+
+\item $\mathcal{A}$ outputs a set of user key pairs $S \subseteq S^*$.
+
+\item For each public user key $X_i \in S$, a public transaction key $Q^*_i$ addressed to $X_i$ is generated. The set $\mathcal{Q}^* := \left\{Q^*_i\right\} \subseteq \mathcal{K}_{\texttt{txn}}$ is constructed, randomly permuted, and then sent to $\mathcal{A}$.
+
+\item $\mathcal{A}$ outputs a message $M$, a destination public user key $X \in \mathcal{K}_{\texttt{user}}$, a ring of transaction public keys $\mathcal{Q}=\left\{Q_1, \ldots, Q_L\right\} \subseteq \mathcal{K}_{\texttt{txn}}$, and two indices $i_0 \neq i_1$ such that $\left\{Q_{i_0}, Q_{i_1}\right\} \subseteq \mathcal{Q} \cap \mathcal{Q}^*$.
+
+\item A random bit $b$ is chosen. The message $M^*=(M,J,Q^*,\mathcal{Q})$ and signature $\sigma \leftarrow \mathcal{SO}(M^*,X,\mathcal{Q},i_b)$ are sent to $\mathcal{A}$.
+
+\item $\mathcal{A}$ outputs a bit $b^{\prime}$. The game counts as a success if (a) $b = b^{\prime}$ and (b) if $(M^{\prime},X^{\prime},\mathcal{Q}^{\prime},i)$ is any query from $\mathcal{A}$ to $\mathcal{SO}$, then the $i^{th}$ element of $\mathcal{Q}^{\prime}$ is not $Q_{i_0}$ or $Q_{i_1}$.
+
+\end{enumerate}
+We say the scheme is \textit{linkably signer ambiguous against adversarially generated keys} (LSA-AGK) if the probability that $\mathcal{A}$ succeeds is negligibly close to $1/2$ (with respect to $\lambda$).
+\end{defn}
+
+Definition \ref{def:ambig} essentially modifies the signer ambiguity game in \cite{bender2006ring} by adding requirements in step (vi) that the transcript for $\mathcal{A}$ reveals the key images for $\left\{Q_{i_0}, Q_{i_1}\right\}$ for the first time in step (v).
+
+\subsection{Unforgeability}
+ 
+
+Unforgeability of any threshold signature scheme must take into account subthreshold corruption oracle access. Multisignatures must not be forgeable by a subthreshold collection of malicious coalition members, otherwise they have no utility as signatures, of course. A naive definition may be something like this:
+
+\begin{defn}{[Prototype: Subthreshold Oracle Access]}\label{def:prot:subthresh}
+Given a $S = \left\{X_1, \ldots, X_N\right\} \subseteq \mathcal{K}_{\texttt{user}}$ where each $X_i \in S$ is a $t_i$-of-$N_i$ public user key, we say that any PPT adversary $\mathcal{A}$ with access to an oracle $\mathcal{O}(-)$ has had \textit{subthreshold oracle access} to $S$ if, for any $X_i \in S$, at most $t_{i}-1$ coalition members for $X_i$ appear in the transcript between $\mathcal{A}$ and $\mathcal{O}(-)$.
+\end{defn}
+
+However, since $\texttt{Merge}$ allows inputs of arbitrary (possibly threshold) user keys, this definition is insufficient. %At the risk of abusing notation, we call $\texttt{Merge}^{-1}(-)$ an oracle that inverts $\texttt{Merge}$ by taking as input a public $t$-of-$N$ key $X$ and producing as output $\texttt{Merge}^{-1}(X)=C$ such that $X = \texttt{Merge}(t,C)$ for some $t$. If $X$ is a usual user key, $\texttt{Merge}^{-1}(X)=(1,\left\{X\right\})$. We can apply $\texttt{Merge}^{-1}$ to sets of keys by taking the union of the output, $\texttt{Merge}^{-1}\left(\left\{X_1, \ldots, X_L\right\}\right) = \cup_{i=1}^{L} \texttt{Merge}^{-1}(X_i)$. We can define $\texttt{Merge}^{-1}\left(\texttt{Merge}^{-1}(X)\right) = \texttt{Merge}^{-2}(X) = \cup_{Y \in \texttt{Merge}^{-1}(X)} \texttt{Merge}^{-1}(Y)$, and so on iteratively. For any public key $X$, the sequence of sets $\left\{\texttt{Merge}^{-i}(X)\right\}_{i=1,2,\ldots}$ eventually terminates at the empty set. In other words, for any public key $X$, there exists an integer $\tilde{k}$ such that $\texttt{Merge}^{-i}(X) = \emptyset$ for any $i \geq \tilde{k}$. Define $\texttt{Merge}^{\leftarrow}(X) = \cup_i \texttt{Merge}^{-i}(X)$, which is the \textit{the set of all public user keys contributing to $X$}.
+
+\begin{defn}{[Subthreshold Oracle Access]}\label{def:prot:subthresh}
+Let $S$ be a set of public user keys $S = \left\{X_1, \ldots, X_N\right\}$ where each $X_i$ is a $t_i$-of-$N_i$ public user key. We say that any PPT adversary $\mathcal{A}$ with access to an oracle $\mathcal{O}(-)$ has had \textit{subthreshold oracle access} to $S$ if, for any public user key $Y \in \texttt{Merge}^{\leftarrow}(S)$, if $Y$ is a $t_Y$-of-$N_Y$ shared public user key, then at most $t_{Y}-1$ coalition members from $\texttt{Merge}^{-1}(Y)$ appear in the transcript between $\mathcal{A}$ and $\mathcal{O}(-)$.
+\end{defn}
+
+
+% 
+
+%In this definition, we grant $\mathcal{A}$ access to $\mathcal{SO}$ as before but also $\mathcal{CO}_{\texttt{user}}(-)$, a user key corruption oracle. $\mathcal{CO}_{\texttt{user}}(-)$ accepts as input a public user key and produces as output the associated private user key. 
+
+Also for notational convenience, we call $\texttt{TxnKeyGen}^{-1}(-)$ an oracle that inverts $\texttt{TxnKeyGen}$ by taking as input a public transaction key $Q_X$ and produces as output the user key $X$. Let $\mathcal{CO}(-)$ be a corruption oracle that takes as input a public user key and outputs the associated private user key.
+
+
+
+%Every signature scheme is only as useful as its unforgeability properties in the face of an adversary with corruption and signing oracle access. Previous security definitions as in \cite{bender2006ring} do not take into account threshold multisignatures. Indeed, an attacker with at most subthreshold corruption oracle access to $R$ should also be unable to forge a signature:
+
+
+
+\begin{defn}{[Existential Unforgeability v. Adaptive Chosen Message and Subthreshold Insider Corruption]}\label{steuf} Let $\mathcal{A}$ be a PPT adversary and $N(-)$ be a polynomials. $\mathcal{A}$ is given access to a signing oracle $\mathcal{SO}$, a corruption oracle $\mathcal{CO}_{\texttt{user}}$. Consider the following game:
+
+\begin{enumerate}[(i)]
+\item A set of user key pairs $S^* \subseteq  \mathcal{K}_{\texttt{user}}$ is selected with $\left|S^*\right| = N(\lambda)$. The public keys in $S^*$ are sent to $\mathcal{A}$.
+\item $\mathcal{A}$ outputs a set of user key pairs $S \subseteq S^*$.
+\item For each public user key $X_i \in S$, a public transaction key $Q_i^* \leftarrow \texttt{TxnKeyGen}(1^\lambda, X_i)$ is generated and the set $\mathcal{Q}^* := \left\{Q_i^*\right\}$ is constructed, randomly permuted, and then sent to $\mathcal{A}$.
+\item $\mathcal{A}$ outputs a message $M$, a destination public user key $X \in \mathcal{K}_{\texttt{user}}$, ring $\mathcal{Q} \subseteq \mathcal{K}_{\texttt{txn}}$ of public transaction keys, and a signature $\sigma$. The game counts as a success if 
+\begin{enumerate}[(a)]
+\item $\mathcal{Q} \subseteq \mathcal{Q}^*$,
+\item $\texttt{VER}(M,\sigma)=1$,
+\item for each index $k$ in $R$, $(M,X,\mathcal{Q},k)$ does not appear in the queries between $\mathcal{A}$ and $\mathcal{SO}$
+\item for each $Q_k \in \mathcal{Q}$, $\mathcal{CO}_{\texttt{user}}$ is not queried with the public user key $\texttt{TxnKeyGen}^{-1}(Q_k)$, and
+\item $\mathcal{A}$ has had subthreshold $\mathcal{CO}_{\texttt{user}}$ access to the set $\left\{\texttt{TxnKeyGen}^{-1}(Q_k) \mid Q_k \in R\right\}$.
+
+\end{enumerate}
+\end{enumerate}
+A scheme in which an adversary is only negligibly likely to succeed is said to be \textit{existentially unforgeable with respect to adaptive chosen message attacks and subthreshold insider corruption} (or \textit{st-EUF} for subthreshold existentially unforgeable).
+\end{defn}
+
+
+
+
+
+\section{Proposed Implementation}\label{sec:implement}
+
+We provide an implementation of a restricted OT-LRTM scheme allowing only for $N-1 \leq t \leq N$ in the spirit of the original CryptoNote methodology. We assume a coordinating member of the coalition is constructing the signature and has persuaded threshold members to participate. User secret keys and public keys are both ordered pairs of keys, i.e.\ private key $(a,b)$ and public key $(A,B)$. Following terminology from \cite{van2013cryptonote}, we refer to $(a,A)$ as the \textit{view keypair} and $(b,B)$ and the \textit{spend keypair}.  We let $\Pi = (\texttt{Gen}^*,\texttt{Enc}^*, \texttt{Auth}^*, \texttt{Ver}^*, \texttt{Dec}^*)$ be a secure encrypt-then-authenticate scheme (where $\Pi_{\texttt{enc}} = (\texttt{Gen}^*,\texttt{Enc}^*, \texttt{Dec}^*)$ is a secure encryption sub-scheme and $\Pi_{\texttt{auth}} = (\texttt{Gen}^*,\texttt{Auth}^*, \texttt{Ver}^*)$ is a secure message authentication sub-scheme). %We use both of these schemes for computing sums, so the encryption and decryption algorithms may be taken as an homomorphic encryption scheme.
+\begin{enumerate}[(I)]
+\item \texttt{UserKeyGen} generates the secret key $z=(a,b)$ by selecting $a,b$ from an i.i.d.\ uniform distribution on $\mathbb{Z}_q$, and computing $Z=(A,B)$ with $A:=aG$ and $B:=bG$. \texttt{UserKeyGen} then outputs $(z,Z)$.
+
+\item \texttt{Merge} takes as input a threshold $t$ and a set of key pairs $C=\left\{(z_1,Z_1), \ldots, (z_n,Z_N)\right\}$  such that $2 \leq t$ and $2 \leq N$ and $N-1 \leq t \leq N$ where each $Z_i = (A_i,B_i)$, and outputs a shared public user key $Z_{\texttt{shared}}$.
+\begin{enumerate}[(1)]
+\item Each member of the coalition selects constants $\mu_i, \gamma_i$ for the multisig address. 
+\item Each member derives a partial secret keypair $(a^*_i, b^*_i)$ where $a^*_i = H_s(a_i, \mu_i)$ and $b^*_i = H_s(b_i, \gamma_i)$ and computes their associated public points $A^*_i=a^*_i G$ and $B^*_i = b^*_i G$. 
+%\item Each member uses $\Pi_{\texttt{auth}}$ to send $(A^*_i, B^*_i)$ to the coalition.
+\item If $t=N$, then each coalition member uses $\Pi$ to send $a^*_i$ to the coordinating user, who computes the shared secret view key $a^* = \sum_i a^*_i$\footnote{Note that although secret information is about $a_i$ not being directly shared with the coalition, the result of the computation is, in fact, a secret key, $a^*$.} The coordinating user computes the shared public spend key $B^* = \sum_{i=1}^{N} B^*_i$. The coordinating user outputs $(A^*, B^*)$, which may be made public.
+\item If $t=N-1$, then 
+\begin{enumerate}[(a)]
+\item For each $i,j$, a partial shared secret view key $\alpha_{i,j} := H_s(a^*_iA^*_j)$ and a partial shared secret spend key $\beta_{i,j} := H_s(b^*_iB^*_j)$ is computed by either participant $i$ or $j$.
+\item Set $N^* := \frac{N(N+1)}{2}$, $S^* := \left\{((\alpha_{i,j},\beta_{i,j}), (\alpha_{i,j}G, \beta_{i,j}G))\right\}_{1 \leq i < j \leq N}$, and run $\texttt{Merge}(N^*, S^*)$.
+\end{enumerate}
+\end{enumerate}
+
+\item \texttt{TxnKeyGen} takes as input a set of destination user public keys $\left\{(A_i,B_i)\right\}_{i}$. For each destination, the coordinating user selects a random scalar $s_i$, computes $S_i=s_iG$ and $P_i = H_s(s_iA_i)G + B_i$, outputs the (public) pairs $\left\{(S_i,P_i)\right\}_i$.%The coalition uses $\Pi$ to share $s$ with each other and 
+
+%\item \texttt{ImageGen} takes as input a set of private user keys $y = \left\{(a_1, b_1), \ldots, (a_N, b_N)\right\}$ and a public transaction key $(R,P)$. For each $i=1,\ldots,N$, the $i^{th}$ member of $y$ computes partial key image $J_i = (H_s(a_i R)+ b_i)H_p(R,P)$. The participating members use $\Pi_\texttt{auth}$ to compute $J = \sum_i J_i$.
+
+\item \texttt{Sign} takes as input a message $M$, a destination public user key $(A_{\texttt{dest}}, B_{\texttt{dest}})$, a set of input public transaction keys $\left\{(S_i, P_i)\right\}_{i=1}^{I}$, a set of output public transaction keys $\left\{(\widetilde{S}_d, \widetilde{P}_d)\right\}_{d=1}^{D}$, a secret index $1 \leq i^* \leq I$, and a set of $t$ user private keys $y=\left\{(a^*_n, b^*_n)\right\}_{n=1}^{t}$ such that $a^*_n = a^*_m$ for each $n,m$.
+\begin{enumerate}[(1)]
+\item The coalition computes $(S^*, P^*) \leftarrow \texttt{TxnKeyGen}(1^\lambda, (A_{\texttt{dest}}, B_{\texttt{dest}}))$.
+\item For each $(a_i, b_i) \in y$, the points $b_i H_p(S_k, P_k)$ are computed and communicated with $\Pi$ to the coalition. The sum $\sum_i b_i H_p(S_k, P_k)$ is computed together with the key image $J = (H_s(a^*_1 S_k)+\sum_i b_i)H_p(S_k, P_k)$ by any member of the coalition and shared with the coalition using $\Pi$.
+\item The coalition computes $M^* = (M, J, S^*, P^*, \mathcal{Q})$.
+\item A set $\left\{s_{k+1}, s_{k+2}, \ldots, s_{k-1}\right\}$ of i.i.d.\ observations of uniform random variables are generated by the coalition and shared among the coalition using $\Pi$.
+
+\item For each $j$, the $j^{th}$ signatory selects a random scalar $u_{k,j}$, computes $H_i:=H_{p}(B_i)$ for each index $1 \leq i \leq L$, and computes the points $u_{k,j}G$ and $u_{k,j}H_{k}$. The coalition uses $\Pi$ to collaboratively compute $u_{k}G := \sum_j u_{k,j} G$ and $u_k H_k:= \sum_j u_{k,j} H_{k}$.
+
+\item Some threshold member computes 
+\begin{align*}
+    c_{k+1} =& H_{p}(M^*, u_{k} G, u_{k} H_{k})\text{ and }\\
+    c_{i+1} =& H_{p}(M^*, s_i G + c_i P_i, s_i H_{i} + c_i J)\text{ for }i=k+1, k+2, \ldots, k-1.
+\end{align*}
+\item The threshold member from the previous step uses $\Pi$ to send $c_{k}$ to all other signers with authentication. These signers may check that their received $c_k$ matches their expected computations.
+\item If $t=N$, each signatory computes their personal $s_{k,j} := u_j - c_{k} b_j^*$. If $t=N-1$, each signatory computes $s_{k,j} = u_j - c_{k} \sum_{i=1}^{L}z_{i,j}$. The coalition uses $\Pi$ to collaboratively compute $s_k = \sum_j s_{k,j}$ and construct $\sigma = (c_1, s_1, s_2, \ldots, s_L)$.
+\item Any signatory may now publish the signature $\sigma=(c_1, s_1, \ldots, s_N)$, and any verifier may use the usual MLSAG verification to check that some member of the ring $\left\{(S_i, P_i)\right\}$ fashioned the signature.
+ \end{enumerate}
+ \end{enumerate}
+ 
+\begin{disc} The resulting signature takes the same form as LSAG signatures as in \cite{liu2004linkable}. Modifying the above to appropriately to take into account key vectors provides the generalization to MLSAG signatures. Thus the verification algorithm for these signatures is identical to the verification algorithm for usual MLSAG signatures and we omit its description. Similarly, $\texttt{Link}$ merely outputs a bit signifying whether two key images are identical, so we don't describe it further either.
+
+\end{disc}
+
+
+ 
+ \begin{disc}
+ Each $u_j$ is kept secret from the other users and is generated randomly when the signature process begins. Certainly if $u_j$ is revealed to another signatory, since the values of $s_j$ and $c_i$ are communicated in with authentication but not encryption, revealing the value $u_j - c_{i^{\prime}} x_j$ can lead an observer to deduce $x_j$. Encryption does not solve the problem if threshold members are untrustworthy.
+ 
+ 
+ Similarly, if some value of $u_j$ is re-used twice with the same private key, an observer can deduce the private key. Indeed, assuming we are using a hash function resistant to second pre-image attacks, the commitments from two signature processes $c_{i^{\prime}}, c_{i^{\prime}}^*$ are unequal except with negligible probability even if the other threshold members are colluding. Hence since $s_{i^{\prime},j} = u_j - c_{i^{\prime}} x_{j}$ and $s_{i^{\prime},j}^* = u_j - c_{i^{\prime}}^* x_{j}$, an observer may solve for the private key $x_j$. Don't re-use values of $u_j$, keep them secret, generate them randomly.
+ 
+ \end{disc}
+ 
+ \begin{disc}  Note that users in $(N-1)$-of-$N$ processes are prompted to select constants $\mu, \gamma$ multiple times for multiple sets of keys. If our hash function $H_s(-)$ is suitably secure, the lazy user can re-use the same constants $\mu$ and $\gamma$ without concern; nevertheless, it is recommended that users do not re-use constants in $\texttt{Merge}$. 
+ \end{disc}
+ 
+ \begin{disc}
+ When a transaction is relayed on the Monero network, the transaction key pair $(S,P)$ is scanned by any of the coalition members. Any of these members can use their shared secret view key $a^*$ to check whether $B^* = P - H_s(a^* S)G$. If so, they can execute $\texttt{Sign}$ to sign a message with the private key $p$ without revealing it.
+ \end{disc}
+ 
+ 
+ \section{Security}
+ 
+ %Note that for our restricted RTM described in Section \ref{sec:implement} only accepts thresholds $t$ such that $2 \leq N-1 \leq t \leq N$ and only merges keys of depth zero. 
+ 
+ Recall the critical fact proven in \cite{scozzafava1993uniform} that the sum of a uniform random variable with any indepenent random variable in $\mathbb{Z}/m\mathbb{Z}$ results in a uniform random variable (and conversely when $m$ is prime). Hence, no PPT algorithm will be able to distinguish between a uniform random variable $U$ and a sum of uniform random variables, $\sum_i U_i$. 
+ 
+ Assume $H_s$, $H_p$ in the OT-LRTM implementation from Section \ref{sec:implement} are cryptographic hash functions under the random oracle model whose outputs are statistically indistinguishable from a uniform distribution except with non-negligible probability, and whose outputs are independent of one another. Assume $\texttt{UserKeyGen}$ produces keys from a distribution  that is statistically indistinguishable from a uniform distribution. 
+ 
+
+
+\begin{theorem}
+If $H_s$ is a secure hash function under the random oracle model, the restricted OT-LRTM implementation from Section \ref{sec:implement} is CIK.
+\end{theorem}
+\begin{proof}
+Either the key pair $X_b = (A,B)$ received by $\mathcal{A}$ in step (iii) of Definition \ref{threshIndist} is $N$-of-$N$ for some $N \geq 2$, $(N-1)$-of-$N$ for some $N \geq 3$, or a mere $1$-of-$1$ user key. Of course, $(N-1)$-of-$N$ key pairs are $N^*$-of-$N^*$ key pairs. Thus, we really only need to deal with two cases: an $N$-of-$N$ key pair with $N > 1$ or a $1$-of-$1$ key pair.
+  
+If $(A,B)$ is an $N$-of-$N$ key pair, then the keys defined in $\texttt{Merge}$ are $A^* = \sum_{i} H_s(a_i, \mu_i) G$ and $B^* = \sum_i H_s(b_i, \gamma_i) G$. Since $H_s$ is a random oracle, any one of its outputs is uniformly random, and so any sum of its outputs is uniformly random \cite{scozzafava1993uniform}, so no PPT adversary may determine the number of signatories. On the other hand, if $(A,B)$ is a $1$-of-$1$ key pair, then $A$ and $B$ are each independent uniform random variables from $\texttt{UserKeyGen}$, so no PPT algorithm can determine whether $A$ or $B$ is a sum or not.
+  
+\end{proof}
+  
+  \begin{theorem} If the Decisional Diffie Hellman hardness assumption holds in $\mathbb{G}$, then the OT-LRTM implementation from Section \ref{sec:implement} is LSA-AGK.
+  \end{theorem}
+  \begin{proof}
+  Assume $\mathcal{A}$ has a non-negligible advantage in the game of Definition \ref{def:ambig} played with the above implementation, namely let us say there exists some polynomial $f_1(\lambda)$ such that 
+  \[\mathbb{P}\left[\mathcal{A}\text{ succeeds in Definition \ref{def:ambig}}\right] > \frac{1}{2} + \frac{1}{f_1(\lambda)}\]
+  
+  
+  We construct an algorithm $\mathcal{M}$ that gains a non-negligible advantage in solving the DDH game by running $\mathcal{A}$ as a subroutine, leading us to a contradiction.  A base point $G$ is chosen and given to $\mathcal{M}$. Random scalars $r$, $s$, and $t$ are selected, a random bits $c \in \left\{0,1\right\}$ are chosen. The points $Q_0 = tG$, $Q_1 = rsG$, $Q_2 = rG$, $Q_3 = sG$ are computed. The points $(Q_c, Q_2,Q_3)$ are given to $\mathcal{M}$, who outputs a bit $c^{\prime}$. The game counts as a success if $c=c^{\prime}$.    
+  
+  The algorithm $\mathcal{M}$ receives $(Q_1^*, Q_2^*, Q_3^*)$ and executes part (i) from Definition \ref{def:ambig} by calling $\texttt{UserKeyGen}(1^{\lambda})$, and calls $\mathcal{A}$ to execute (ii) as usual. In (iii), $\mathcal{M}$ constructs $\mathcal{Q}^*$ to include $Q_i^*$ for $i=1,2,3$ in the following way. First, $\mathcal{M}$ instructs $\mathcal{A}$ to select three user public keys $X_1, X_2, X_3 \in S$, picks a random permutation $\tau \in S_3$, and assigns $\texttt{dest}(Q_i^*):=X_{\tau(i)}$ for each $i=1,2,3$. Next, $\mathcal{M}$ calls $\texttt{TxnKeyGen}$ using the other members of $S$ as usual to build $\mathcal{Q}^*$. Denote the index for $Q_i^*$ in $\mathcal{Q}^*$ as $j_i$ for $i=1,2,3$. Now $\mathcal{M}$ instructs $\mathcal{A}$ to select $i_0 = j_1$ and $i_1 \in \left\{j_2, j_3\right\}$. Steps (v) and (vi) execute as usual. If $\mathcal{A}$ succeeds, then $\mathcal{M}$ outputs $c^{\prime}=1$, otherwise selects a random bit as an output. We have the following from the law of total probability.
+ \begin{align*}
+ \mathbb{P}\left[\mathcal{M}\text{ succeeds at DDH}\right] =& \mathbb{P}\left[\mathcal{M}(Q^*_1, Q^*_2, Q^*_3)=c \mid c=0\right]\mathbb{P}\left[c=0\right] + \mathbb{P}\left[\mathcal{M}(Q^*_1, Q^*_2, Q^*_3)=c \mid c=1\right]\mathbb{P}\left[c=1\right]
+ \end{align*}
+ Certainly, $\mathbb{P}\left[c=0\right] = \mathbb{P}\left[c=1\right] = \frac{1}{2}$. If $c=0$, then $\mathcal{A}$ did not succeed so $\mathcal{M}$ can only guess. In this case,  $\mathbb{P}\left[\mathcal{M}(Q^*_1, Q^*_2, Q^*_3)=c \mid c=0\right] = \frac{1}{2}$. We have
+ \begin{align*}
+ \mathbb{P}\left[\mathcal{M}\text{ succeeds at DDH}\right] =& \frac{1}{4} + \frac{1}{2}\mathbb{P}\left[\mathcal{M}(Q^*_1, Q^*_2, Q^*_3)=c \mid c=1\right]
+ \end{align*}
+ Moreover, $\mathcal{M}$ outputs $1$ if and only if $\mathcal{A}$ has succeeded:
+  \begin{align*}
+ \mathbb{P}\left[\mathcal{M}\text{ succeeds at DDH}\right] =& \frac{1}{4} + \frac{1}{2}\mathbb{P}\left[\mathcal{A}\text{ succeeds in Definition \ref{def:ambig}}\right]\\
+ >& \frac{1}{4} + \frac{1}{2}\left(\frac{1}{2} + \frac{1}{f(\lambda)}\right)\\
+ >& \frac{1}{2} + \frac{1}{2f(\lambda)}
+ \end{align*}
+  
+  
+  \end{proof}
+ 
+ \begin{theorem} The OT-LRTM implementation from Section \ref{sec:implement} is st-EUF.
+ \end{theorem}
+ \begin{proof} 
+ Assume $\mathcal{A}$ is a PPT adversary that can succeed at the game in Definition \ref{} with non-negligible advantage. The adversary has sub-threshold access to the ring, $\mathcal{A}$ cannot execute $\texttt{Sign}$ fairly and must attempt a forgery by generating additional random numbers. In this case, the adversary is merely attempting to forge a usual LSAG signature, and the security proof reduces to the one presented by \cite{liu2004linkable}.
+ 
+ %We use the rewind-on-success approach presented in \cite{liu2004linkable}.  Assume a reduction master $\mathcal{M}$ simulates adversary $\mathcal{A}$ who can succeed at the game presented in Definition \ref{steuf} with non-negligible probability, bounded below by $1/Q_1(\lambda)$ for some polynomial $Q_1(-)$. Let $q_{H}$ be the number of queries $\mathcal{A}$ makes to the $H_s(-)$ or $H_p(-)$, $q_C$ be the number of queries $\mathcal{A}$ makes to the corruption oracle, let $q_S$ be the number of queries $\mathcal{A}$ makes to the signing oracle.
+ 
+ %Then $\mathcal{A}$ produces a signature $\sigma$, a message $M$, and a set $R \subseteq S$ such that $\texttt{VER}(M,R,\sigma) = 1$. Denote the number of public keys $\left|R\right|$. 
+ 
+ %We first show that, except with negligible probability, $\mathcal{A}$ must have included all verification queries to $H_p$ of the form 
+ %\[c_{i+1} = H_p(m, s_i G + c_i B_i, s_i H_i + c_i J)\]
+ %among their $q_H$ queries. To pass this verification, $\left|R\right|$ solutions to these equations must be presented. Let $E$ be the event that all $\left|R\right|$ of these queries are included in the $q_H$ queries made by $\mathcal{A}$, and $\overline{E}$ the set complement. In the event $\overline{E}$, $\mathcal{M}$ needs to generate additional random numbers in order to verify the forgery; but $\mathcal{A}$ did not make oracle queries for these random numbers, so $\mathcal{A}$ could only guess the outcomes of those queries. Consequently, the probability that $c_1$ matches the required validation is at most $1/(q - q_H - n q_S)$. Since this is negligible, the probability of the intersection of $E$ with a forgery by $\mathcal{A}$ is non-negligible. Note that this result is independent of corruption oracle and signing oracle access, since the adversary cannot invert $H_p(-)$ except with negligible probability.
+ 
+ %Thus, in any transcript where $\mathcal{A}$ computes a successful forgery there exists an oracle query of the form $H_p(m, s_i G + c_i B_i, s_i H_i + c_i J)$.
+ 
+ %Moreover, $\mathcal{A}$ has not directly corrupted any keys in $R$, $\mathcal{A}$ has at most subthreshold corruption oracle access to any threshold keys in $R$, and $\mathcal{A}$ has not send $(k,M,R)$ in a query to $\mathcal{SO}$. 
+ \end{proof}
+
+%If we assume all threshold members are honest, the scheme reduces to the usual LSAG signature as in \cite{liu2004linkable}. However, this is an undesirable assumption for applications in cryptocurrency. Definition \ref{defn:unf} is inadequate in the threshold setting because, if some $B_i$ is a $t_i$-of-$n_i$ shared public key in the ring, the adversary may query the oracle $\mathcal{SO}$ to sign messages on behalf of some of the $n_i$ members sharing the public key $B_i$ without violating the conditions of Definition \ref{defn:unf}. Do to this, we consider Definition \ref{defn:unf2} to describe adaptive chosen message attacks where insiders. 
+
+%Since we may regard any $(n-1)$-of-$n$ instantiation of the above scheme as an $n^*$-of-$n^*$ instantiation, it is sufficient to prove that any $n$-of-$n$ instantiation is secure. The $1$-of-$1$ instantiation is merely the LSAG signature from \cite{liu2004linkable}; in this setting, Definitions \ref{defn:unf} and \ref{defn:unf2} coincide, so we only must concern ourselves with $n$-of-$n$ instantiations with $n \geq 2$.
+
+%The strength of the security proof from \cite{liu2004linkable} rests on novel rewind-on-success simulations. Rewind simulations were first presented as the forking lemma in \cite{pointcheval1996security} and the heavy row lemma in \cite{ohta1998concrete}; rewind-on-success simulations are first presented in \cite{liu2004linkable}. With a master PPT $\mathcal{M}$ invoking a PPT adversary $\mathcal{A}$ to obtain a transcript $\mathcal{T}$ in an attack game on some scheme $\Pi$ may, the rewind-on-success simulation will, upon finding a success in $\mathcal{T}$,  rewind $\mathcal{T}$ to some point, header $h$ and ``begin again'' to seek an additional success. Resimulating $\mathcal{A}$ with new random data, $\mathcal{M}$ generates a new transcript $\mathcal{T}^*$ where $\mathcal{T}$ and $\mathcal{T}^*$ are identical up to (and including) header $h$. It is established in \protect{\cite[Lem E.1]{liu2004linkable}} that the probabilities of success of $\mathcal{T}$ and $\mathcal{T}^*$ are identical (although this says nothing of their independence). Thus an attacker who can find one success with non-negligible probability can find any finite number they desire using rewind-on-success with non-negligible probability.
+
+%Thus, if the adversary can successfully compute one forged signature on a message with non-negligible probability, say $\sigma = (c_1, s_1, \ldots, s_N, J)$, then that adversary can rewind and compute a second forged signature with the same key image but different random values $s_i^*$, say $\sigma^* = (c_1^*, s_1^*, \ldots, s_N^*, J)$, also with non-negligible probability. In checking that these forgeries satisfy verification, the adversary must compute the commitments in the LSAG signature, and hence must query some hash function $H$ at least once per commitment. So the adversary must make as many queries to $H$ as there are ring members, $L$, each of the form $H(J,m, sG + cB, sH(B) + cJ)$, where $B$ is a public key in the ring and $J$ is the key image associated to the signature. In computing the first forgery, the adversary must compute some first commitment $H(m,J, uG, vG^{\prime}) = H(m,J, sG + cB, sH(B) + cJ)$, where $u$, $v$, and the base point $G^{\prime}$ are each unknown before rewinding. After rewinding and computing a second forgery, the adversary has the system of equations
+%\begin{align*}
+    %uG =& sG + cB\\
+    %uG =& s^*G + c^*B\\
+    %vG^{\prime} =& sH(B) + cJ\\
+    %vG^{\prime} =& s^*H(B) + c^*J\\
+%\end{align*}
+%The adversary can then compute the secret key $b = \frac{s-s^*}{c^*-c}$, solving the discrete log problem $B = bG$.
+
+%This proof extends directly to MLSAG signatures; this was claimed in \cite{noether2016ring} but the proof therein contained a mistake, which we correct here:
+%\todo{Shen's security theorem and corrected proof}
+%\begin{thm}
+%*
+%\end{thm}
+ 
+
+%The signatories must make several joint decisions in the process described under Section \ref{sec:implement}. We are vague in their description because the implementation of these steps can be done in many ways. 
+
+%For example, in Step 3, the signatories decide upon a ring and a secret index to store their public keys. This may be done by merely having some member do it randomly (introducing a sort of Byzantine General problem), or using some deterministic (but seemingly random) method chosen ahead of time in meatspace based on the input message. The secret index should appear to be uniformly random, regardless of method employed. Note that one of the signatories can publicly communicate a sort of encryption of the secret index without harm by merely publishing the ring of public keys $Q$; other signatories know their own public keys, so they can inspect the ring and determine the secret index without any further information from the first signatory and without observers being able to discern which index is the threshold key.
+
+%Also in Step 3, the signatories decide on the values of $s_i$ randomly. One method is for each signatory to compute their own $s_{i,j}$ and computing the shared sums $s_i = \sum_j s_{i,j}$. This requires a lot of interaction; another method is to simply let one threshold member do it and communicate the values to the group with authentication. Note that the values $s_i$ are eventually made public in the signature and there is no harm in sharing these values without encryption. Similarly, in step 8, we compute the sum $\sum_j s_{i^{\prime},j}$; since each user keeps their $u_j$ secret, they can reveal their $u_j - c_{i^{\prime}} b_j^*$ or $u_j - c_{i^{\prime}} \sum_{i=1}^{L} z_{i,j}$ without risking their private keys, so there is no harm in sharing these values without encryption.
+
+%To communicate a message with authentication, we use the HMAC scheme: for the $j^{th}$ threshold member to communicate a message $M$ to the $i^{th}$ threshold member, a shared secret $t_{i,j}$ is computed and $(M, \texttt{HMAC}(t_{i,j}, M))$ is sent. For a CCA-secure encrypt-and-authenticate scheme \cite{katzAndLindell}, two users generate two shared secrets $t_{i,j}$, $t^*_{i,j}$. The sending user computes the ciphertext $C = \texttt{Enc}(t_{i,j}, M)$ and the authentication codes $\tau = \texttt{HMAC}(t^*_{i,j}, C)$ and sends $(C,\tau)$ to the receiver. If a receiver sees some $(C,\tau)$, they can check if $\tau$ is a valid HMAC on $C$ for any of their shared secrets. If so, they can decrypt $C$ with the other shared secret.
+
+
+
+
+%\begin{comment}
+
+
+%Additional properties are often required in application, such as \textit{linkability}: an adversary can feasibly identify whether two signatures have been fashioned by some common private keys. In the case of usual ring signatures, this is an obvious question: if the true signer of two signatures is the same, output $1$, otherwise $0$. Linkability schemes can be de-anonymizing if the process reveals more than just a bit, like the associated user public key (or worse, the user secret key). Unfortunately, in the case of $t$-of-$n$ threshold signatures, the property of linkability comes in several flavors.
+
+
+%A brief notational consideration: for some signature $\sigma$ generated by following the protocol honestly, denote $P^*_\sigma$ as the ring of public signing keys associated with $\sigma$, denote $(sk^*_\sigma, pk^*_\sigma)$ as the signing keypair of the signatory for $\sigma$. For such a signature, there must have existed a $t$-of-$n$ configuration of users (recall this is a collection of user secret keys), which comes equipped with a set of user public keys $P_\sigma$, and a subset of the associated user secret keys $S_\sigma$. Denote the set of public keys associated with the user secret keys in $S_\sigma$ as $P(S_\sigma)$.
+
+%A t-of-n threshold ring signature scheme can be made into a linkable $t$-of-$n$ threshold ring signature if it comes equipped with an PPT algorithm \texttt{Lnk} that outputs a bit if two input signatures are linked. Implementation of \texttt{Lnk} depends critically on the application. If linkability is defined such that we only detect when \textit{exact same} $t$-of-$n$ configuration of users signed two signatures, then it is possible that a group of $n=t+1$ users conspire to fashion $t+1$ different $t$-of-$n$ threshold ring signatures, each with a unique $t$-of-$n$ configuration. Hence, these signers are able to fashion as many different $t$-of-$n$ signatures as they have conspirators before linkability reveals their behavior. On the other hand, by requiring all user keys from \texttt{GenUserKey} be one-time keypairs generated in a Diffie-Hellman exchange, this forces all of our signatures to be one-time signatures and the problem is resolved.
+
+%On the other end of the spectrum, presume linkability is defined such that two signatures are linked if \textit{at least one} user private key is used in common between two signatures. Then each private key can participate in at most one signing, regardless of the size of coalition of users $n$ or threshold $t$, before use of their private key will lead to linkage. This may be undesirable for many applications, but the appeal for use in e-cash schemes is obvious. 
+
+%We use the following terminology. If an adversary can feasibly compute some nontrivial function of the sets $P(S_{\sigma_1})$ and $P(S_{\sigma_2})$, we say the scheme is \textit{leaky}.  If an attacker can feasibly determine whether $P(S_{\sigma_1}) = P(S_{\sigma_2})$, then we say that the scheme is \textit{linkable}. If an attacker can feasibly determine whether $P(S_{\sigma_1}) \cap P(S_{\sigma_2}) = \emptyset$, then we say that the scheme is \textit{individually linkable}.   Certainly every linkable scheme and every individually linkable scheme is leaky. If an adversary can feasibly compute some nontrivial function of the sets $S_{\sigma_1}$ and $S_{\sigma_2}$, we say the scheme is \textit{very leaky}. Note that every very leaky scheme is leaky. We attain a hierarchy induced by both linkability and leakage.
+
+
+%Recall that a usual ring signature is a $1$-of-$1$ threshold ring signature. Thus, a linkable ring signature is a linkable $1$-of-$1$ threshold ring signature. In particular, given two signatures, an adversary can feasibly determine whether the public key of the signer of both signatures is the same. It's clear that in this scenario, the notion of linkability and the notion of individual linkability coincide.
+
+
+%For our purposes, we use a \texttt{Lnk} algorithm that takes as input a $t_1$-of-$n_1$ signature $\sigma_1$ on message $M_1$ with possible signing public keys $P^*_1$, a $t_2$-of-$n_2$ signature $\sigma_2$ on message $M_2$ with possible signing public keys $P^*_2$. The algorithm outputs a bit if any secret key used to generate $\sigma_1$ was also used to generate $\sigma_2$.
+
+%In a linkable $t$-of-$n$ threshold ring signature with, say $L$ ring members, each ring member consists of some $t$-of-$n$ threshold configuration of user keys. In this way, each signature implicates $L$ threshold configurations, each with $t$ users, so each signature implicates $tL$ users. If any particular $t$-of-$n$ threshold configuration
+
+
+\section{Further Analysis}
+
+\subsection{Efficiency and comparisons}
+
+The signatures resulting from the OT-LRTM scheme are indistinguishable from MLSAG signatures, so space complexity and verification time complexity of the OT-LRTM scheme is identical to that of MLSAGs. Due to the use of $\Pi$ and several (possibly recursive) rounds of communication between coalition participants, efficiency of signatures is greatly reduced. 
+
+For a coalition consisting of $1$-of-$1$ keys, $\texttt{Merge}$ takes one round of communication inside the coalition with $\Pi$, $\texttt{ImageGen}$ takes one round of communication inside the coalition with $\Pi_{\texttt{auth}}$, $\texttt{Sign}$ takes three distinct rounds of communication with $\Pi_{\texttt{auth}}$ and calls $\texttt{TxnKeyGen}$ and $\texttt{ImageGen}$ each once. In total, this amounts to five rounds of communication inside the coalition per signature. For a coalition containing shared user keys for sub-coalitions, the rounds of communication in $\texttt{Sign}$ must also take place inside each sub-coalition (and sub-sub-coalition, and so on).
+
+In total, if we define the \textit{depth} of $1$-of-$1$ public user key as depth $0$, and the \textit{depth} of any $t$-of-$N$ public user key $X$ with coalition $C$ as $\max\left\{\texttt{depth}(X) \mid X \in C\right\}+1$. Then for a signature with a coalition of depth $D$ where each coalition has at most $N$ members, we require at most $2 + 3\cdot D^N$ rounds of communication to fashion a signature.
+
+\subsection{Elaborations}
+
+
+ %A stronger version of Definition \ref{threshIndist} is available by granting the adversary access to a signing oracle, providing coalition indistinguishable keys and signatures against chosen message attacks (CIKS-CMA), which guarantees that not only are \textit{keys} coalition-indistinguishable, but also signatures, even if the adversary can obtain arbitrary signatures.
+ 
+
+
+
+
+%Modifications to the CryptoNote-styled constructions of key images may allow for stronger notions of signer ambiguity in the future without sacrificing robustness against double-spend attacks. For example, by taking key images as homomorphic commitments, two commitments may be linked if their difference is a commitment to zero without revealing their masks. This is beyond the scope of this document.
+
+In \cite{bonehthreshold}, a very general fully homomorphic thresholdizing set-up is described, leading to fully homomorphic threshold signatures and encryption. The threshold signature scheme defined in \cite{bonehthreshold} generates a unique verification key (akin to our transaction keys) for each coalition and access structure, so the scheme in \cite{bonehthreshold} vacuously satisfies CIK. On the other hand, in our proposed implementation, keys are being combined into new keys, so it is critical to check that combined keys do not reveal anything about the participating members.
+
+Coalition indistinguishability on keys is related to two distinct security notions defined in \cite{bonehthreshold}, where a highly general fully homomorphic thresholdizing scheme using only one round of communication is presented. Threshold signatures described in \cite{bonehthreshold} are required to be \textit{anonymous} and \textit{succinct}. Anonymity in \cite{bonehthreshold} is defined such that an adversary should be unable to discern which subset of the coalition produced the signature, and succinctness is defined such that signature size is dependent only on the security parameter. 
+
+Our proposed implementation is certainly \textit{succinct} because it produces a signature in the format of a usual MLSAG signature, regardless of the details of the coalition. Our scheme is anonymous because all signatures are, without loss of generality, $N$-of-$N$, so each signature is fashioned with a full subset. 
+
+A natural question is to ask whether the definition of CIK can be expanded to coalition indistinguishability on keys and signatures (say CIKS) by demanding that signatures also provide no information about the signing subset or signing coalition.  With an LRTM, an expansion of Definition \ref{threshIndist} to take into account an adaptive chosen message attack is nontrivial but straightforward. A CIKS LRTM scheme is necessarily succinct and anonymous according to the definition in \cite{bonehthreshold}. Moreover, a succinct and anonymous threshold signature scheme from \cite{bonehthreshold} that generates verification keys for each coalition randomly is also CIKS. In this sense, CIKS is equivalent to succinct anonymity. 
+
+%More importantly, \cite{bonehthreshold} presents some new definitions regarding thresholdizing cryptoschemes. 
+
+Additional helpful definitions appear in \cite{bonehthreshold}. For example, a threshold cryptoscheme may be regarded as \textit{private} if no subthreshold collection of key shares can reveal any information about the shared secrets, and \textit{robust} if maliciously generated evaluation key shares can always be detected. Since our implementation never reveals the shared secret key even with a threshold number of coalition members participating, our implementation is private. However, in the presence of maliciously generated choices in the signature process, we have no guarantee of robustness: although a malicious subthreshold party will only enjoy a negligible advantage in constructing a forgery, their attempt will merely appear to be an invalid signature.
+
+\vspace{0.1in}
+
+\textbf{Special Thanks}: We would like to issue a special thanks to the members of the Monero community who used the \texttt{GetMonero.org} Community Forum Funding System to support the Monero Research Lab. Readers may also regard this as a statement of conflict of interest, since our funding is denominated in Monero and provided directly by members of the Monero community by the Forum Funding System.
+
+\medskip{}
+
+\bibliographystyle{plain}
+\bibliography{biblio.bib}
+
+\end{document}

publications/research-bulletins/in-prog/MRL-9999 - Threshold Multisignatures/main.tex

@@ -1,256 +0,0 @@
-\documentclass[12pt,english]{mrl}
-\usepackage{graphicx}
-\usepackage{listings}
-\usepackage{cite}
-\usepackage{amsthm}
-
-\usepackage[toc,page]{appendix}
-
-\renewcommand{\familydefault}{\rmdefault}
-\usepackage[T1]{fontenc}
-\usepackage[latin9]{inputenc}
-\usepackage{color}
-\usepackage{babel}
-\usepackage{verbatim}
-\usepackage{float}
-\usepackage{url}
-\usepackage{amsthm}
-\usepackage{amsmath}
-\usepackage{amssymb}
-\usepackage[unicode=true,pdfusetitle, bookmarks=true,bookmarksnumbered=false,bookmarksopen=false,  breaklinks=false,pdfborder={0 0 1},backref=false,colorlinks=true]{hyperref}
-\usepackage{breakurl}
-\usepackage{todonotes}
-
-
-\usepackage{amsmath}
-\usepackage{amsfonts}
-\usepackage{amssymb,enumerate}
-\usepackage{amsthm}
-\usepackage{cite}
-\usepackage{comment}
-\usepackage[all]{xy}
-%\usepackage[notref,notcite]{showkeys}
-\usepackage{hyperref}
-\usepackage{todonotes}
-
-% THEOREM ENVIRONMENTS
-\newtheorem*{example}{Example}
-\theoremstyle{definition}
-\newtheorem{lem}{Lemma}[section]
-\newtheorem{cor}[lem]{Corollary}
-\newtheorem{prop}[lem]{Proposition}
-\newtheorem{thm}[lem]{Theorem}
-\newtheorem{soln}[]{Solution}
-\newtheorem{conj}[lem]{Conjecture}
-\newtheorem{Defn}[lem]{Definition}
-\newtheorem{Ex}[lem]{Example}
-\newtheorem{Question}[lem]{Question}
-\newtheorem{Property}[lem]{Property}
-\newtheorem{Properties}[lem]{Properties}
-\newtheorem{Discussion}[lem]{Remark}
-\newtheorem{Construction}[lem]{Construction}
-\newtheorem{Notation}[lem]{Notation}
-\newtheorem{Fact}[lem]{Fact}
-\newtheorem{Notationdefinition}[lem]{Definition/Notation}
-\newtheorem{Remarkdefinition}[lem]{Remark/Definition}
-\newtheorem{rem}[lem]{Remark}
-\newtheorem{Subprops}{}[lem]
-\newtheorem{Para}[lem]{}
-\newtheorem{Exer}[lem]{Exercise}
-\newtheorem{Exerc}{Exercise}
-
-\newenvironment{defn}{\begin{Defn}\rm}{\end{Defn}}
-\newenvironment{ex}{\begin{Ex}\rm}{\end{Ex}}
-\newenvironment{question}{\begin{Question}\rm}{\end{Question}}
-\newenvironment{property}{\begin{Property}\rm}{\end{Property}}
-\newenvironment{properties}{\begin{Properties}\rm}{\end{Properties}}
-\newenvironment{notation}{\begin{Notation}\rm}{\end{Notation}}
-\newenvironment{fact}{\begin{Fact}\rm}{\end{Fact}}
-\newenvironment{notationdefinition}{\begin{Notationdefinition}\rm}{\end{Notationdefinition}}
-\newenvironment{remarkdefinition}{\begin{Remarkdefinition}\rm}{\end{Remarkdefinition}}
-\newenvironment{subprops}{\begin{Subprops}\rm}{\end{Subprops}}
-\newenvironment{para}{\begin{Para}\rm}{\end{Para}}
-\newenvironment{disc}{\begin{Discussion}\rm}{\end{Discussion}}
-\newenvironment{construction}{\begin{Construction}\rm}{\end{Construction}}
-\newenvironment{exer}{\begin{Exer}\rm}{\end{Exer}}
-\newenvironment{exerc}{\begin{Exerc}\rm}{\end{Exerc}}
-
-\newtheorem{intthm}{Theorem}
-\renewcommand{\theintthm}{\Alph{intthm}}
-
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
-\floatstyle{ruled}
-\newfloat{algorithm}{tbp}{loa}
-\providecommand{\algorithmname}{Algorithm}
-\floatname{algorithm}{\protect\algorithmname}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.
-\numberwithin{equation}{section}
-\numberwithin{figure}{section}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% User specified LaTeX commands.
-\usepackage{algpseudocode}
-
-\usepackage{subcaption}
-
-\numberwithin{equation}{section}
-
-
-\makeatletter
-
-
-\makeatletter
-
-\newcommand{\h}{\mathcal{H}}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
-\floatstyle{ruled}
-\newfloat{algorithm}{tbp}{loa}
-\providecommand{\algorithmname}{Algorithm}
-\floatname{algorithm}{\protect\algorithmname}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.
-\numberwithin{equation}{section}
-\numberwithin{figure}{section}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% User specified LaTeX commands.
-\usepackage{algpseudocode}
-
-\makeatother
-
-\begin{document}
-\begin{frontmatter}
-
-\begin{fmbox}
-{\huge\sffamily Quarterly update} \hfill\setlength{\fboxrule}{0px}\setlength{\fboxsep}{5px}\fbox{\includegraphics[width=2in]{moneroLogo.png}}
-\dochead{}
-\date{\today}
-\author[
-   addressref={mrl},
-   email={bggoode@g.clemson.edu}
-]{\fnm{Brandon} \snm{Goodell}}
-
-
-\address[id=mrl]{
-  \orgname{Monero Research Lab}
-}
-\end{fmbox}
-
-%\begin{abstractbox}
-%This document describes
-%\begin{abstract}
-%We outline the various ideas currently under investigation by the Monero Research Lab, provide context for each task, and present some informative sources regarding each task. \end{abstract}
-%\end{abstractbox}
-\end{frontmatter}
-
-This document is intended to inform the community of the work done at MRL in the past quarter, sort of as a response to the first MRL Roadmap, MRL-R001, and sort of as a newsletter to inform everyone about Monero Research Lab. We try to address the partial MRL ``to-do'' list of research items from the first MRL Research Bulletin, MRL-R001, and document the work that has been done both directly and indirectly toward those ends. We document which items on those lists are being de-prioritized on the next MRL Roadmap, and we introduce a few new items that came up over the past few months that will make it onto the next MRL Roadmap (which we expect to put out in the next two to three weeks).
-
-The Monero Research Lab wishes to state emphatically that our concern is to report our findings on Monero, which is an open source project, as honestly and transparently as possible, subject to the restriction that we do not compromise the safety or security of the funds of our users by doing so. Our goal is not to persuade, re-assure, or enrich speculators or investors; our goal is to assist the Monero community and the Monero Core Team in the design of a robust and strong cryptocurrency with an emphasis on user privacy.  Consequently, all findings will be responsibly disclosed to the Monero community. Responsible disclosure may involve maintaining secrecy regarding security flaws for a period of time before disclosure to the public, which provides the development team time to correct known issues and protect our users. This also provides time to discreetly contact the developers of other cryptocurrencies so they, also, may protect their users.
-
-Now that is out of the way, here is what we did with our summer:
-
-
-\section{RingCT Security Proofs} 
-
-We have combined this topic with the threshold signature topic (see next item). In \cite{noether2016ring}, there are certain flaws in the proofs of security for MLSAG signatures that need correction, but in the construction of the threshold signature security proofs, we must first establish the security of the MLSAG signatures and then generalize to the threshold setting. Due to this, the corrected RingCT proofs are now part-and-parcel with the threshold multisignature paper.
-    
-    
-\section{Threshold multisignatures} 
-
-We are fleshing out an implementation proposed by former contributor \texttt{shen} of $t$-of-$n$ threshold MLSAG multisignatures in Monero. The details of this implementation have been available to the community for months, and vetting those implementations and developing security proofs has been one of the more pressing areas of work for \texttt{surae}, especially in the past six weeks. We currently have a partial draft of MRL Research Bulletin MRL-0006 detailing the implementation in preparation (see the MRL github for a current copy). However, this is only partial because completing this document requires novel security models against insider attacks, where an adversary may corrupt a subthreshold number of private keys. Novel security models require novel security proofs, and so we are ``in the weeds'' on that right now. We hoped this would be accomplished before the end of August but the novelty of the security models have taken MRL a little by surprise. A delightful, surprise, but a surprise nonetheless: the novelty of these results may lead to a peer-reviewed publication on behalf of MRL!
-    
-    
-On a related note, \texttt{surae} began in June approaching the threshold multisignature scheme as a mere problem of \textit{computing private keys jointly}, and this was a complete misunderstanding of the problem at hand, which is to \textit{compute signatures without directly computing the private key.} Consequently, our work on this topic was initially unified with our work on the sub-address scheme described by \texttt{kenshi84} and \texttt{knaccc}, by considering these both as problems involving revamping Monero's addressing schemes. This is also one of the reasons that MRL-R001 failed to elaborate upon the sub-address scheme. Once this mis-understanding was clarified to us (after several very educational and helpful conversations with \texttt{luigi} and \texttt{kenshi84}), MRL is once again approaching these two topics separately. We anticipate an MRL Research Bulletin on the sub-address scheme very soon after MRL-0006 describing threshold signatures is released; security proofs for the sub-address scheme are (ostensibly) remarkably easier than in the threshold case.
-    
-\section{Recent criticisms} 
-
-Critics have claimed the Monero blockchain is traceable, as in \cite{miller2017empirical} and \cite{kumar2017traceability}; these papers make use of the \emph{distributional problem} mentioned in the first roadmap together with a few other routes of analysis. Some of the concerns and claims made in these papers are irrelevant because they only apply to pre-RingCT Monero outputs. Some of the concerns are relevant and related to the so-called EABE attack (see next item).
-    
-    
-    
-\section{Churning, EABE Attack, Large Rings}
-
-Detailed by \texttt{knaccc} in \cite{knaccc2017}, the EABE (Eve-Alice-Bob-Eve) attack is described. A merchant, Bob, and his customer, Alice, use an exchange, Eve, to convert cryptocurrency to fiat and back again. If Eve sends some moneroj to Alice, who uses it to purchase items from the merchant Bob several times, and if Bob immediately converts all cryptocurrency to fiat after each transaction to limit his exposure to the volatility of cryptocurrency-to-fiat exchange rates, then Bob unintentionally provides information Eve needs to determine the purchasing habits of Alice. This problem is exacerbated if Eve is a know-your-customer exchange. Urgency on this problem is higher than our original estimation: most merchants who accept cryptocurrency enact this behavior, most users do not churn to avoid this problem, and moreover churning transactions can leave a statistical signal (in the sense of the Miller and Kumar criticisms) that is quite undesirable.  
-    
-This work dovetailed nicely with our road map item \textbf{hardness of blockchain analysis}.  In the study of this (as well as the Miller and Kumar criticisms), \texttt{surae} established three separate probabilistic models of transaction output ownership in a ring signature setting in analyzing this problem. None of these models will see publication soon, however, because each one, a refinement of the previous, is insufficient to describe the problem at hand. We do, however, anticipate some explanatory details to be made public over the coming months. MRL has been reluctant to provide more details, as we stated very clearly in our first MRL Roadmap, \emph{we will not comment thoroughly on these criticisms until our review is complete for security reasons.} We will take as much time as necessary for this, and we recognize that issues such as this one are urgent.
-    
-In the current CryptoNote framework, an elegant solution would be to simply increase ring sizes dramatically. This seems impractical, however, unless ring signatures can be made small (perhaps sub-linearly sized with respect to the number of ring members) which leads us to the next item.
-    
-\section{Signature Size and RingCT}
-
-Blockchain bloat can be mitigated with efficient signatures. MRL was made aware of research by two separate international teams of researchers (see Section \ref{sec:academ}) making progress on compact Ring Confidental Transactions. One scheme (put forth by Sun, Au, Liu, and Yuen) is very efficient and fast but requires a trusted set-up. Another scheme (put forth by Ruffing,  Thyagarajan, Ronge, and Schr{\"o}der, or RTRS) does not use a trusted set-up, but experiences a trade-off since the computation and verification times are quite beastly. An RTRS RingCT may contain thousands of ring members and take up the space of a classic RingCT signature with only a few dozen ring members, but the RTRS RingCT could take hours, days, or more to compute. We believe verification time may be optimized to an extent, but it is also quite slow. Currently, \texttt{knaccc} is working with \texttt{surae} and \texttt{sarang} on a Java prototype of the implementation for testing purposes, and discussions with \texttt{smooth}, \texttt{moneromooo}, and \texttt{luigi} on the practicalities of implementation are constant. MRL anticipates that the scheme may be made sufficiently stream-lined to include in Monero for a moderate increase ring size that was previously unreasonable, but not the epic increase initially hoped for.
-    
-    
-\section{Zero-knowledge Lit Review} 
-
-We began communication with Jeffrey Quesnelle, a computer science graduate student at the University of Michigan at Dearborn, at the start of this quarter. Jeffrey wrote an extremely helpful and detailed literature review on zero-knowledge schemes with an eye toward ZK-SNARKS. We listed this zero-knowledge literature review first in MRL-R001 because it was rather low-hanging fruit... but it also did not present a high priority compared to practical implementation issues (threshold signatures, sub-addresses) or security issues (the EABE attack, see below). Our original date for pushing this out was the end of August 2017, which has come and gone. To be clear, this work has not come to a stop, it is merely delayed; now that \texttt{sarang} has joined MRL, \texttt{surae} has more time to put into finishing this project. MRL anticipates movement on this document before the end of September (in fact, the first week of September).
-    
-    
-\section{Future-proofing Monero} 
-
-Unlike the above topics, this is actually a constant ``in-the-background'' thing to keep in mind. For example, when we use Pedersen commitments, we have certain hiding and binding properties, but when we use El Gamal commitments, which are similar, these properties change and the commitments are no longer sufficiently hiding against adversaries with quantum computing. Making decisions such as these throughout algorithm design is a constant issue to be considered. Consequently, this item will be removed from future MRL road maps, as it is more of a design philosophy.
-    
-\section{New stuff}
-
-We have put effort into projects not initially on the MRL Roadmap either due to merit of those projects or urgency. Something related to these items will each make it onto the next MRL Roadmap.
-
-\begin{enumerate}[i.]
-\item \textbf{Viewkey solutions}. Since the CryptoNote framework is not \emph{unlinkable} in the sense of the original CryptoNote whitepaper, an adversary can infer much information about whether a certain address has received transactions without knowing the associated viewkey (as in the EABE scenario). Moreover, viewkeys lack functionality. For example, users may desire revocable viewkeys, or viewkeys only valid for certain periods of time, or may desire viewkeys that grant visibility to outgoing transactions (which should also be revocable). Discussions on viewkey solutions have begun between contributors \texttt{endogenic}, \texttt{knaccc}, \texttt{moneromooo}, \texttt{surae}, and  \texttt{fluffypony}.
-
-\item \textbf{Zidechains}. Even with very large ring sizes, since the CryptoNote framework is not zero-knowledge, information is leaked with each transaction by definition. One method proposed by \texttt{fluffypony} to mitigate this is to construct a zero-knowledge sidechain to peg to the Monero blockchain which we are tentatively calling \textit{zidechains}.
-
-\item \textbf{Blacklisting provably spent outputs}. Wallet software should avoid including provably-spent outputs in ring signatures if possible, because doing so reduces the relative signer ambiguity of the signature, degrades Monero's claims toward untraceability, and degrades the fungibility of all other Monero outputs. Recently, \texttt{fluffypony} had a conversation with \texttt{gmaxwell} on maintaining curated blacklists of provably spent outputs, and \texttt{surae} has begun work on algorithms for finding provably-spent transaction outputs.
-\end{enumerate}
-
-
-\section{Dead Items}
-
-Recall that the items deeper on the MRL Roadmap were items of lower priority. We did not have an opportunity to make progress on the following issues, all of which are very long-term, in terms of priority. These items are worthwhile side hustles for future research, but do not have a lot of immediate pay-off.
-
-\begin{enumerate}[i.]
-    \item \textbf{Testing Blockchain Dynamics with Population-driven Modeling.} 
-    
-    \item \textbf{Blockchain Design}.
-    
-    \item \textbf{Traceability, extending RingCT to obscure transaction time.}
-\end{enumerate}
-
-\section{Academic Engagement}\label{sec:academ}
-
-In the past three months, Monero Research Lab has had some great interaction with the broader academic community, briefly mentioned above. We wish to highlight the following, which is big news!
-
-\begin{enumerate}[(i)]
-
-\item Shi-Feng Sun at Hong Kong Polytechnic University, Man Ho Au at Shanghai Jiao Tong University, Joseph K Liu at Monash University, and Tsz Hon Yuen at Huawei Technologies wrote ``RingCT 2.0: A Compact Accumulator-Based (Linkable Ring Signature) Protocol for Blockchain Cryptocurrency Monero,'' a paper proposing a much more efficient and speedy implementation of Ring Confidential Transactions. These researchers have been instrumental in ID-based cryptography and ring signatures, so their contribution directly to Monero, literally mentioning us in their paper title was surprising, exciting, and a huge honor!
-
-\item  Nearly at the same time, Tim Ruffing at Saarlang University together with Sri Aravinda Thyagarajan, Viktoria Ronge, and Dominique Schr{\"o}der at Friedrich-Alexander-Universit{\"a}t contacted us directly with a separate Ring Confidental Transaction scheme, with a very different Ring Confidential Transaction scheme (see below). We have had a few conversations with him about implementation choices; thanks to hard work by \texttt{knaccc} and \texttt{surae}, we have a nearly-working prototype (to Ruffing's surprise! \texttt{knaccc} works quick).
-
-\item In implementing the Ruffing scheme, Monero Research Lab has also been in contact with Jonathan Bootle at University College in London about a set-up presented in one of his papers used in the Ruffing scheme; not only are we the first (to his knowledge) to implement his set-ups, but we also identified a small mistake in the notation of his paper that will be corrected.
-
-\item Thanks to community donations to the Forum Funding System, hired Sarang Noether! He recently graduated with his Ph.D.\ in Computational Physics (and has a strong background in pure and applied mathematics, computer science, and network security) and was a contributor to MRL several years back. We are already enjoying his contribution to our work. We are extremely grateful that the community has welcomed him; he was facing several competitive offers for some very interesting and varied jobs in a few different engineering sectors, so we are lucky to have sniped him away from the traditional economy!
-
-\end{enumerate}
-
-
-
-
-\section{Conclusion}
-
-We request members of the community contribute their opinions on our above work and ideas they would like to see added. Please do not hesitate to contact us.  We will make the current threshold MRL Bulletin (which will be MRL-0006) available on the MRL github upon publication of this quarterly update so that contributors and community members can monitor our progress on that front. 
-
-In the next four weeks, we anticipate MRL-R002 roadmap to be put out, the second draft of the zero-knowledge literature review with Jeffrey Quesnelle to be made available to the community, and MRL-0006 to be completed and put out (unless the novelty of the security proofs becomes a rabbit hole of uknown depth). We also anticipate that the RTRS Ring Confidential Transaction scheme to be finished prototyping and beginning testing very soon. Once MRL-0006 is finished, we will begin an MRL Research Bulletin describing the sub-address scheme invented by \texttt{kenshi84} and \texttt{knaccc} to be fleshed out (MRL-0007).
-
-
-
-
-\section{Special Thanks} 
-
-We would like to issue a special thanks to the members of the Monero community who used the GetMonero.org Forum Funding System to support the Monero Research Lab. Readers may also regard this as a statement of conflict of interest, since our funding is denominated in Monero and provided directly by members of the Monero community by the Forum Funding System.
-
-\medskip{}
-
-\bibliographystyle{plain}
-\bibliography{biblio.bib}
-
-\end{document}

publications/research-roadmaps/MRL-R001 Priorities for Monero Research Lab/biblio.bib

@@ -1,208 +0,0 @@
-@article{nakamoto2008bitcoin,
-  title={{B}itcoin: {A} peer-to-peer electronic cash system},
-  author={Nakamoto, Satoshi}
-}
-
-@techreport{grenander1981abstract,
-  title={Abstract {I}nference},
-  author={Grenander, Ulf and Ulf, Grenander},
-  year={1981}
-}
-
-@article{massey1996estimating,
-  title={{E}stimating the parameters of a nonhomogeneous {P}oisson process with linear rate},
-  author={Massey, William A and Parker, Geraldine A and Whitt, Ward},
-  journal={Telecommunication Systems},
-  volume={5},
-  number={2},
-  pages={361--388},
-  year={1996},
-  publisher={Springer}
-}
-
-@inproceedings{decker2013information,
-  title={{I}nformation propagation in the {B}itcoin network},
-  author={Decker, Christian and Wattenhofer, Roger},
-  booktitle={Peer-to-Peer Computing (P2P), 2013 IEEE Thirteenth International Conference on},
-  pages={1--10},
-  year={2013},
-  organization={IEEE}
-}
-
-@article{sompolinsky2013accelerating,
-  title={Accelerating {B}itcoin's Transaction Processing. Fast Money Grows on Trees, Not Chains.},
-  author={Sompolinsky, Yonatan and Zohar, Aviv},
-  journal={IACR Cryptology ePrint Archive},
-  volume={2013},
-  pages={881},
-  year={2013}
-}
-
-@article{macheta2014counterfeiting,
-  title={Counterfeiting via Merkle Tree Exploits within Virtual Currencies Employing the {C}ryptoNote Protocol},
-  author={Macheta, Jan and Noether, Sarang and Noether, Surae and Smooth, Javier},
-  year={2014}
-}
-
-@incollection{eyal2014majority,
-  title={Majority is not enough: {B}itcoin mining is vulnerable},
-  author={Eyal, Ittay and Sirer, Emin G{\"u}n},
-  booktitle={Financial Cryptography and Data Security},
-  pages={436--454},
-  year={2014},
-  publisher={Springer}
-}
-
-
-@article{kraft2015difficulty,
-  title={Difficulty Control for Blockchain-Based Consensus Systems},
-  author={Kraft, Daniel},
-  year={2015}
-}
-
-@book{serfozo2009basics,
-  title={Basics of applied stochastic processes},
-  author={Serfozo, Richard},
-  year={2009},
-  publisher={Springer Science \& Business Media}
-}
-
-@article{miller2017empirical,
-  title={An Empirical Analysis of Linkability in the {M}onero Blockchain},
-  author={Miller, Andrew and M{\"o}ser, Malte and Lee, Kevin and Narayanan, Arvind},
-  journal={arXiv preprint arXiv:1704.04299},
-  year={2017}
-}
-
-@inproceedings{au2006constant,
-  title={Constant-size {ID}-based linkable and revocable-iff-linked ring signature},
-  author={Au, Man Ho and Liu, Joseph K and Susilo, Willy and Yuen, Tsz Hon},
-  booktitle={International Conference on Cryptology in India},
-  pages={364--378},
-  year={2006},
-  organization={Springer}
-}
-
-@inproceedings{au2006event,
-  title={Event-oriented k-times revocable-iff-linked group signatures},
-  author={Au, Man Ho and Susilo, Willy and Yiu, Siu-Ming},
-  booktitle={Australasian Conference on Information Security and Privacy},
-  pages={223--234},
-  year={2006},
-  organization={Springer}
-}
-
-@inproceedings{chandran2007ring,
-  title={Ring signatures of sub-linear size without random oracles},
-  author={Chandran, Nishanth and Groth, Jens and Sahai, Amit},
-  booktitle={International Colloquium on Automata, Languages, and Programming},
-  pages={423--434},
-  year={2007},
-  organization={Springer}
-}
-
-@article{kumar2017traceability,
-  title={A Traceability Analysis of {M}onero's Blockchain},
-  author={Kumar, Amrit and Fischer, Cl{\'e}ment and Tople, Shruti and Saxena, Prateek},
-  year={2017}
-}
-
-@misc{knaccc2017,
-  author = {knaccc},
-  title = {Potential Privacy Leaks in {M}onero and Churning},
-  year = {2017},
-  publisher = {GitHub},
-  journal = {GitHub repository},
-  howpublished = {\url{https://github.com/monero-project/monero/issues/1673#issuecomment-278509986}}
-}
-
-@misc{kenshi2017,
-  author = {kenshi84},
-  title = {Monero Subaddresses},
-  year = {2017},
-  publisher = {GitHub},
-  journal = {GitHub repository},
-  howpublished = {\url{https://github.com/monero-project/monero/pull/2056}}
-}
-
-@misc{mcElrathBraid,
-  author = {Bob McElrath},
-  title = {Braiding the Blockchain},
-  year = {2017},
-  howpublished = {\url{https://scalingbitcoin.org/hongkong2015/presentations/DAY2/2_breaking_the_chain_1_mcelrath.pdf}}
-}
-
-@article{noether2016ring,
-  title={Ring Confidential Transactions},
-  author={Noether, Shen and Mackenzie, Adam and others},
-  journal={Ledger},
-  volume={1},
-  pages={1--18},
-  year={2016}
-}
-
-@article{T-1955,
-doi	= {10.2307/166755},
-title	= {Applications of Game Theory in Fighter versus Bomber Combat},
-author	= {T. E. Caywood and C. J. Thomas},
-journal	= {Journal of the Operations Research Society of America},
-issnp	= {0096-3984},
-issne	= {2326-3229},
-year	= {1955},
-month	= {11},
-volume	= {3},
-issue	= {4},
-page	= {402--411},
-url =       {http://gen.lib.rus.ec/scimag/index.php?s=10.2307/166755},
-}
-
-@book{strogatz2014nonlinear,
-  title={Nonlinear dynamics and chaos: with applications to physics, biology, chemistry, and engineering},
-  author={Strogatz, Steven H},
-  year={2014},
-  publisher={Westview press}
-}
-
-@article{doob1942topics,
-  title={Topics in the theory of {M}arkoff chains},
-  author={Doob, Joseph L},
-  journal={Transactions of the American Mathematical Society},
-  volume={52},
-  number={1},
-  pages={37--64},
-  year={1942},
-  publisher={JSTOR}
-}
-
-@article{doob1945markoff,
-  title={{M}arkoff chains--denumerable case},
-  author={Doob, Joseph L},
-  journal={Transactions of the American Mathematical Society},
-  volume={58},
-  number={3},
-  pages={455--473},
-  year={1945},
-  publisher={JSTOR}
-}
-
-@article{gillespie1977exact,
-  title={Exact stochastic simulation of coupled chemical reactions},
-  author={Gillespie, Daniel T},
-  journal={The journal of physical chemistry},
-  volume={81},
-  number={25},
-  pages={2340--2361},
-  year={1977},
-  publisher={ACS Publications}
-}
-
-@article{gillespie1976general,
-  title={A general method for numerically simulating the stochastic time evolution of coupled chemical reactions},
-  author={Gillespie, Daniel T},
-  journal={Journal of computational physics},
-  volume={22},
-  number={4},
-  pages={403--434},
-  year={1976},
-  publisher={Elsevier}
-}

publications/roadmaps/MRL-R002/MRL-R002.bib

@@ -0,0 +1,27 @@
+@article{noether2016ring,
+  title={Ring Confidential Transactions},
+  author={Noether, Shen and Mackenzie, Adam and others},
+  journal={Ledger},
+  volume={1},
+  pages={1--18},
+  year={2016}
+}
+
+@Inbook{Bootle2015,
+author="Bootle, Jonathan
+and Cerulli, Andrea
+and Chaidos, Pyrros
+and Ghadafi, Essam
+and Groth, Jens
+and Petit, Christophe",
+editor="Pernul, G{\"u}nther
+and Y A Ryan, Peter
+and Weippl, Edgar",
+title="Short Accountable Ring Signatures Based on DDH",
+bookTitle="Computer Security -- ESORICS 2015: 20th European Symposium on Research in Computer Security, Vienna, Austria, September 21-25, 2015, Proceedings, Part I",
+year="2015",
+publisher="Springer International Publishing",
+address="Cham",
+pages="243--265"
+}
+

publications/roadmaps/MRL-R002/MRL-R002.tex

@@ -0,0 +1,408 @@
+\documentclass[12pt,english]{mrl}
+\usepackage{graphicx}
+\usepackage{listings}
+\usepackage{cite}
+\usepackage{amsthm}
+
+\usepackage[toc,page]{appendix}
+
+\renewcommand{\familydefault}{\rmdefault}
+\usepackage[T1]{fontenc}
+\usepackage[latin9]{inputenc}
+\usepackage{color}
+\usepackage{babel}
+\usepackage{verbatim}
+\usepackage{float}
+\usepackage{url}
+\usepackage{amsthm}
+\usepackage{amsmath}
+\usepackage{amssymb}
+\usepackage[unicode=true,pdfusetitle, bookmarks=true,bookmarksnumbered=false,bookmarksopen=false,  breaklinks=false,pdfborder={0 0 1},backref=false,colorlinks=true]{hyperref}
+\usepackage{breakurl}
+\usepackage{todonotes}
+
+
+\usepackage{amsmath}
+\usepackage{amsfonts}
+\usepackage{amssymb,enumerate}
+\usepackage{amsthm}
+\usepackage{cite}
+\usepackage{comment}
+\usepackage[all]{xy}
+%\usepackage[notref,notcite]{showkeys}
+\usepackage{hyperref}
+\usepackage{todonotes}
+
+% THEOREM ENVIRONMENTS
+\newtheorem*{example}{Example}
+\theoremstyle{definition}
+\newtheorem{lem}{Lemma}[section]
+\newtheorem{cor}[lem]{Corollary}
+\newtheorem{prop}[lem]{Proposition}
+\newtheorem{thm}[lem]{Theorem}
+\newtheorem{soln}[]{Solution}
+\newtheorem{conj}[lem]{Conjecture}
+\newtheorem{Defn}[lem]{Definition}
+\newtheorem{Ex}[lem]{Example}
+\newtheorem{Question}[lem]{Question}
+\newtheorem{Property}[lem]{Property}
+\newtheorem{Properties}[lem]{Properties}
+\newtheorem{Discussion}[lem]{Remark}
+\newtheorem{Construction}[lem]{Construction}
+\newtheorem{Notation}[lem]{Notation}
+\newtheorem{Fact}[lem]{Fact}
+\newtheorem{Notationdefinition}[lem]{Definition/Notation}
+\newtheorem{Remarkdefinition}[lem]{Remark/Definition}
+\newtheorem{rem}[lem]{Remark}
+\newtheorem{Subprops}{}[lem]
+\newtheorem{Para}[lem]{}
+\newtheorem{Exer}[lem]{Exercise}
+\newtheorem{Exerc}{Exercise}
+
+\newenvironment{defn}{\begin{Defn}\rm}{\end{Defn}}
+\newenvironment{ex}{\begin{Ex}\rm}{\end{Ex}}
+\newenvironment{question}{\begin{Question}\rm}{\end{Question}}
+\newenvironment{property}{\begin{Property}\rm}{\end{Property}}
+\newenvironment{properties}{\begin{Properties}\rm}{\end{Properties}}
+\newenvironment{notation}{\begin{Notation}\rm}{\end{Notation}}
+\newenvironment{fact}{\begin{Fact}\rm}{\end{Fact}}
+\newenvironment{notationdefinition}{\begin{Notationdefinition}\rm}{\end{Notationdefinition}}
+\newenvironment{remarkdefinition}{\begin{Remarkdefinition}\rm}{\end{Remarkdefinition}}
+\newenvironment{subprops}{\begin{Subprops}\rm}{\end{Subprops}}
+\newenvironment{para}{\begin{Para}\rm}{\end{Para}}
+\newenvironment{disc}{\begin{Discussion}\rm}{\end{Discussion}}
+\newenvironment{construction}{\begin{Construction}\rm}{\end{Construction}}
+\newenvironment{exer}{\begin{Exer}\rm}{\end{Exer}}
+\newenvironment{exerc}{\begin{Exerc}\rm}{\end{Exerc}}
+
+\newtheorem{intthm}{Theorem}
+\renewcommand{\theintthm}{\Alph{intthm}}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
+\floatstyle{ruled}
+\newfloat{algorithm}{tbp}{loa}
+\providecommand{\algorithmname}{Algorithm}
+\floatname{algorithm}{\protect\algorithmname}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.
+\numberwithin{equation}{section}
+\numberwithin{figure}{section}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% User specified LaTeX commands.
+\usepackage{algpseudocode}
+
+\usepackage{subcaption}
+
+\numberwithin{equation}{section}
+
+
+\makeatletter
+
+
+\makeatletter
+
+\newcommand{\h}{\mathcal{H}}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
+\floatstyle{ruled}
+\newfloat{algorithm}{tbp}{loa}
+\providecommand{\algorithmname}{Algorithm}
+\floatname{algorithm}{\protect\algorithmname}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.
+\numberwithin{equation}{section}
+\numberwithin{figure}{section}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% User specified LaTeX commands.
+\usepackage{algpseudocode}
+
+\makeatother
+
+\begin{document}
+\begin{frontmatter}
+
+\begin{fmbox}
+\hfill\setlength{\fboxrule}{0px}\setlength{\fboxsep}{5px}\fbox{\includegraphics[width=2in]{moneroLogo.png}}
+\dochead{Research Road-map \hfill MRL-R002}
+\title{Priorities for Monero Research Lab}
+\date{September 9, 2017}
+\author[
+   addressref={mrl},
+   email={bggoode@g.clemson.edu}
+]{\fnm{Brandon} \snm{Goodell}}
+\author[
+   addressref={mrl},
+   email={sarang.noether@protonmail.com}
+]{\fnm{Sarang} \snm{Noether}}
+
+
+\address[id=mrl]{
+  \orgname{Monero Research Lab}
+}
+\end{fmbox}
+
+\begin{abstractbox}
+\begin{abstract}
+We outline the various ideas currently under investigation by the Monero Research Lab, provide context for each task, and present some informative sources regarding each task. \end{abstract}
+\end{abstractbox}
+\end{frontmatter}
+
+
+This bulletin serves as an update to the Monero community about the recent work, current priorities, and intended future work of the Monero Research Lab (MRL) team. A particular focus of this bulletin is also providing general history and information for the community about the particular types of research problems that are the foci of the Lab, especially since many projects are related. For each topic, we indicate a non-binding but reasonable time line for completion. At the end, we reserve discussion for items that were on the first road map that require reconsideration.
+
+\section{A few brief announcements...}
+
+\textit{On a personnel note,} the Lab is pleased to announce that Sarang Noether joined the team as a full-time researcher under a Forum Funding System proposal. Many thanks to the generous supporters who funded his work for the next few months.
+
+\textit{Coming soon!} Monero Research Labs is scheduling bi-monthly \textit{research meetings} to alternate with bi-monthly \textit{office hours} on freenode. At research meetings, contributors can describe their progress, challenges, and bring questions up about their projects. At office hours, any member of the Monero community can come on down and ask any questions they like. Right now we are considering every Monday at 17:00-18:00 UTC, pending feedback from the community, to alternate between research meetings and office hours. Official times and dates will be posted soon.
+
+\textit{On another note,} Monero Research Lab would also like to thank contributor \texttt{knaccc} for volunteering his time for three straight weeks to get RTRS RingCT off the ground. Thanks to his efforts, we now have a Ring Confidential Transaction scheme with sub-linear space complexity in the number of signers! This is extremely great news, and \texttt{knaccc} deserves a pat on the back.
+
+
+\vspace{0.1in}
+
+\section{Signature sizes and confidential transactions} \label{secOne}
+
+\subsection{Summary:} 
+
+We have completed an implementation of a sub-linearly-sized Ring Confidential Transaction scheme (RTRS Ring CT) with operational Java code and slightly-out-of-date pseudo-code at \url{https://github.com/monero-project/research-lab}. We are investigating the security models, the consequences of implementation, and the possibility of extending the scheme to a Schnorr-like threshold multisignature scheme. In the process of verifying the security of the new Ring CT scheme, we are correcting old proofs for the current MLSAG Ring CT scheme.
+
+\subsection{Timing and Urgency:} 
+
+This project is of moderate urgency. We anticipate a significantly greater understanding of the ramifications of implementing RTRS Ring CT by the end of October 2017 and we anticipate our recommendations for or against implementation in the Spring 2018 hard fork before the end of November 2017. If a Schnorr-like generalization toward threshold multisignatures is possible, we anticipate an MRL Research Bulletin on the matter before the Spring 2018 hard fork.
+
+\subsection{History and Details:} 
+
+The size of signatures has been an ongoing subject of intense discussion, growing concern, and research for the MRL team. Blockchain bloat is directly affected by the size of ring signatures, and research toward traceability analyses for CryptoNote has demonstrated that larger ring sizes improve resistance to traceability. However, it is critical that increased ring sizes not be tied to excessive blockchain bloat. Additionally, any signature scheme that permits large rings should also ensure efficient verification times. Hence there are two (often competing) factors: signature size and verification time.
+
+The current Monero protocol uses multi-layered linkable spontaneous anonymous group signatures (MLSAGs), described in \cite{noether2016ring}, to implement a ring signature version of Confidential Transactions first proposed by Greg Maxwell. We call this scheme the MLSAG Ring CT scheme. In the MLSAG Ring CT scheme, transaction amounts (with multiple inputs and outputs) are replaced by commitments to those amounts. This approach masks both the spender and the amounts, while still allowing any party to verify that the transaction balances without double spending. The set-up increases privacy of Monero (compared to the reference CryptoNote protocol which did not mask transaction amounts), but comes equipped with drawbacks. First, the presented security proofs contains flaws, and second, the size of the signatures increases linearly with the size of the ring: doubling ring sizes leads to doubling the weight of the blockchain.  We are informally confident that the security definitions are satisfied despite the incorrect proofs and are working to correct the old proofs. Additionally, we are constantly seeking more efficient schemes.
+
+A paper was shared with MRL by Tim Ruffing, Sri Aravinda Thyagarajan, Viktoria Ronge, and Dominique Schr{\"o}der, (Ruffing et.\ al., personal communication, August 2017) proposing a novel construction of Ring CT together with new security definitions. The proposal modifies previous work on ring signatures by Jonathan Bootle, Andrea Cerulli, Pyrros Chaidos, Essam Ghadafi, Jens Groth, and Christophe Petit \cite{bootle2015short}. We are formally calling this scheme the RTRS Ring CT.  
+
+Space complexity for RTRS Ring CT is logarithmic in the size of the ring, so the limiting factor in large ring sizes has shifted to verification time, which is linear in the ring size. One of the authors, Tim Ruffing, also posted a proof that the verification time for any secure ring signature scheme is linear in the ring size. The RTRS Ring CT scheme uses keys that are twice as large as the MLSAG scheme, resulting in (asymptotically) twice the verification time as the MLSAG scheme. In this sense, the MLSAG Ring CT protocol is as fast as we can reasonably expect verification to proceed, in terms of number of operations. The only remaining possible optimization therefore would involve changing elliptic curves, using different implementations of elliptic curve arithmetic, using specialized hardware specifically for signature verification, or implementing amortization by re-using rings. The RTRS scheme doubles verification time complexity in exchange for logarithmic space complexity.
+
+The development of the prototype in Java (which went under the super-top-secret tongue-in-cheek title RuffCT) was done by \texttt{knaccc} with the assistance of \texttt{surae} and \texttt{sarang}. Each of these contributors were instrumental. The Lab has verified that RuffCT does, in fact, produce and verify signatures as claimed and we have produced a working implementation in Java (available at \url{https://github.com/monero-project/research-lab}). 
+
+We have moved onto investigating the presented security models and proofs, and investigating the ramifications of implementing RTRS Ring CT into Monero: how large can we make our rings and still keep our transaction verification time on the order of a few seconds? Associated ongoing projects include: (i) the proper inclusion of fees in an RTRS Ring CT in a secure manner, (ii) the process of converting to the new addressing system, (iii) threshold multisignature versions of the RTRS Ring CT, and (iv) various methods to improve average verification time (constrained by the theoretical minima previously described). This topic is considered to be of moderate priority. We expect a more complete understanding of the differences between MLSAG and RTRS Ring CT by the end of October 2017.
+
+
+
+
+
+
+
+
+\section{Threshold multisignatures} 
+
+\subsection{Summary:} 
+
+We are in the midst of completing our analysis of the Schnorr-like threshold multisignature implementation of MLSAG Ring CT as described in \cite{noether2016ring} and our comparison to the code produced by contributor \texttt{luigi}. Demonstrating security requires appropriate (novel) security models and definitions. In the process of constructing security proofs (and overlapping with our work on RTRS Ring CT above), we are correcting old proofs for the current MLSAG Ring CT scheme as we go.
+
+\subsection{Timing and Urgency:} 
+
+This project is of high urgency, as the scheme is already implemented and would provide additional security features to users immediately. The novelty of our security schemes delayed our previous estimate as completing this by the end of August 2017. We anticipate an MRL Research Bulletin describing the scheme and presenting security proofs by the end of November 2017 at the latest.
+
+\subsection{History and Details:} 
+
+In \cite{noether2016ring}, Shen Noether proposed a $t$-of-$N$ threshold multisignature approach for MLSAG ring signatures where the number of participants in the signature generation is not discernible from the signature. We are currently investigating security models for such signature schemes, in particular for $N$-of-$N$ and $(N-1)$-of-$N$ cases, for multi-factor authentication purposes. Good security models for ring signatures are tough to come by, and we believe that we must incorporate novel definitions in the analysis. In particular, we are currently looking into expanding the definitions presented in \cite{bender2006ring} to account for threshold multisignature schemes.
+
+In particular, attacks involving a corruption of a sub-threshold number of keys by an attacker must be considered. The goal is to ensure that given an adversary with the ability to corrupt honest user key pairs as well as the ability to maliciously generate their own key pairs, even if they generate or corrupt up to $(t-1)$ keys by an attacker, the security of our $t$-of-$N$ threshold multisignature is not reduced. This is akin to the security guaranteed by a classical Shamir secret-sharing scheme \cite{shamir1979share}, where an attacker must control a ``critical mass'' of keys before gaining any secret information from honest participants.
+
+In order to ensure correct security proofs of the threshold scheme, work is also underway to complete proofs of security for the original $N$-of-$N$ MLSAG multisignature scheme. Errors must be addressed for a proper extension to the threshold model. We consider this topic to be of high priority and intend that the scheme is demonstrated to be sufficiently secure for live implementation in wallet software before the end of November 2017.
+
+
+
+
+\section{Sub-addresses}
+
+
+\subsection{Summary:} 
+
+We are in the midst of completing our analysis of the sub-address scheme first described by contributors \texttt{knaccc} and \texttt{kenshi84}. This scheme allows for a single ``master'' key pair to generate a family of Monero addresses, all of which share a common view key. We are taking care to verify that the security of either the MLSAG Ring CT or the RTRS Ring CT schemes are not compromised using these schemes.
+
+\subsection{Timing and Urgency:} 
+
+This project is of high urgency, as the scheme is mostly implemented and would provide additional convenience features to users immediately. The Lab has begun a more complete review of the proposal. We expect an MRL Research Bulletin detailing the sub-address scheme by the end of November 2017, with inclusions of the necessary proofs to show that the scheme is at least as secure as previous implementations. The goal is to release both the sub-address and threshold multisignature papers at or around the same time.
+
+\subsection{History and Details:} 
+
+A sub-address scheme addresses solves the problem of address reuse. In such a scheme, a user maintains a ``master'' key pair from which she generates new addresses as needed. Unlike an approach where the user simply generates independent key pairs, sub-addresses should not require that the user verify every incoming transaction with each of her view keys. Instead, the construction of sub-addresses should permit single transaction verification and hence not scale poorly. With such an approach, a user can publish as many addresses as she wishes and be assured that a third party cannot link the addresses. 
+
+A implementation proposal has been submitted (by researchers \texttt{kenshi84} and \texttt{knaccc}) that claims compatibility with existing key structure and multiple outputs, solving initial concerns about issuing change. The Lab has begun a more complete review of the proposal. Any Ring CT scheme using these sub-addresses should enjoy at least the same security properties as the address scheme in the CryptoNote standards. 
+
+The proof that the sub-addressing scheme as currently described does not degrade security is very close to trivial. Unfortunately, the triviality is not so simple that we may leave the proof to the reader, so we are presenting the formal security definitions and proof in our write-up. We expect a white paper detailing the sub-address scheme by the end of November 2017, with inclusions of the necessary proofs to show that the scheme is at least as secure as previous implementations.
+
+
+
+
+
+\section{Range proofs} 
+
+\subsection{Summary:} 
+
+Work on range proofs is going in two simultaneous directions: compact, fast-to-verify proofs, and utilizing the space complexity of range proofs for storing cipher texts.
+
+\subsection{Timing and Urgency:} 
+
+This project is of medium urgency; the increased utility of the Monero blockchain is balanced by other issues with greater urgency regarding security. We anticipate a review of different implementations of range proofs and a sketch of an encrypt-then-authenticate scheme utilizing range proofs by Spring 2018.
+
+\subsection{History and Details:} 
+
+An essential component to confidential transactions is a range proof. A naive confidential transaction scheme might only ensure that transaction amounts balance, but this introduces the possibility of attacks using negative values or modular wrapping. A range proof offers assurances that each input is in a numerical range appropriate for the transaction, while not compromising the confidentiality of the amounts involved. Unfortunately, range proofs are larger than is preferable in both space and verification-time complexity. Rather than perceiving this as a drawback (or rather, as a waste of space on the blockchain), utilizing this extra space to store cipher texts has been suggested; together with a strongly unforgeable ring signature scheme, this would qualify as an encrypt-then-authenticate scheme (satisfying the gold standard of security models). Hence, we have two directions that do not directly conflict: improve the space and time efficiency of range proofs or use the large space complexity to add utility to the blockchain as more than a ledger.
+
+The matter is somewhat complicated because ring signatures are a fundamental component to the working of our current range proof implementations. Hence, any progress on ring signatures has consequences for range proofs. Work is ongoing to produce range proof constructions that are both efficient and secure; for example \texttt{luigi} is working on implementing a change of base that should improve space complexity, and both \texttt{sarang} and \texttt{surae} are constantly on the lookout for new schemes. The recent introduction of the RTRS Ring CT test implementation (discussed above) brought with it new proofs involving commitments that may be applicable to range proofs. This reduces the space available for encryption and increases verification time. Improving the space and verification-time complexity of range proofs now faces similar trade-offs as those described in Section \ref{secOne}, and so any optimization made in that area (as in choice of elliptic curve or more efficient elliptic curve arithmetic implementation) will also improve this area. 
+
+Currently, the Lab is under the impression that we should be rather satisfied by large but fast-to-verify range proofs together with small but slow-to-verify Ring CT schemes (i.e.\ the Borromean ring signatures from the original MLSAG Ring CT description acting as range proofs, and the RTRS Ring CT acting as ring signatures). 
+
+
+
+
+
+\section{Blockchain Pruning and Generalizations}
+
+\subsection{Summary:} 
+
+We are currently investigating methods of blockchain pruning and generalizations of blockchain-like data structures that may lead to different properties. 
+
+\subsection{Timing and Urgency:} 
+
+This project is of moderate urgency; the increased utility of the Monero blockchain is balanced by other issues with greater urgency regarding security, and we are not anticipating immediate progress.
+
+\subsection{History and Details:} 
+
+We are investigating the abstract data structure of a blockchain. Some of this includes different methods of forming blockchains, and some of this includes blockchain pruning. Pruning of the blockchain is deeply connected to minimizing the information necessary to protect against double-spends and malicious blockchain rewrites.
+
+In terms of pruning, we hope to implement blockchain pruning to reduce the amount of information needed in the blockchain. It is of critical importance that any method of pruning the blockchain only negligibly degrades protection against double spends and only negligibly influences an adversary's advantage in traceability analyses. To be precise, we seek a data structure asymptotically smaller than the Monero blockchain, such that an adversary in control of a fixed proportion $p$ of network nodes can successfully execute a double-spend attack with a probability of success at most $f(p)$ where $f$ is some function that is negligible in some security parameter. 
+
+A naive implementation of such a rule, for example, would be to discard any blocks from more than $10$ years in the past. In this scenario, any double-spend attack might require referencing invalid transactions from more than $10$ years ago and, unless an adversary has control over a high proportion of the network for most of those $10$ years, other miners would have probably discovered the invalid transactions some time in the previous decade. You'll notice these previous two sentences are filled with hedging words ``naive,'' ``might,'' ``high proportion,'' ``most,'' and ``probably.'' The point is we have not yet finished formalizing these notions, and yet all these notions can be quantified and made precise yielding straightforward analysis. Although all of the above seems reasonable, the math is going to determine exactly whether this decision is prudent and fruitful.
+
+These issues were high priority in the last road map. These are being downgraded to a lower priority since, with access to RTRS Ring CT, the limiting factor in the efficiency of the Monero blockchain is time, not space. Our primary concern for any blockchain pruning method or any alternative implementation of the blockchain is, therefore, to improve verification time (especially for new nodes catching up to the tip).
+
+
+
+\section{Monero Traceability Analyses}
+
+\subsection{Summary:} 
+
+We are currently investigating previous criticisms of Monero's traceability, as in \cite{miller2017empirical} and \cite{kumar2017traceability}, and the attack detailed by \texttt{knaccc}  where an AML/KYC exchange knows ownership information of some of their customer's one-time addresses and can use this to determine the flow of money between their customers.
+
+\subsection{Timing and Urgency:} 
+
+This project is of high urgency due to concern in the community, but we are not self-imposing a deadline on our analysis. Our assessment of these security concerns will be made available when we are confident in the correctness of our analysis.
+
+\subsection{History and Details:} 
+
+For any two incoming transactions, if all possible senders are equiprobable then we say that set-up is \textit{untraceable}. It is known that Monero is not strictly untraceable, which was a result we exploited when investigating chain reactions in \cite{noether2014note}, and is exploited in \cite{miller2017empirical} and \cite{kumar2017traceability}. The claims in each of these documents were made before MLSAG Ring CT was implemented; as of the most recent hard fork, MLSAG Ring CT signatures are now required for all Monero transactions and many of the routes of degrading Monero's untraceability presented are no longer relevant. Although the specific criticisms presented in these papers are (mostly) no longer directly relevant to Monero in particular, they present interesting heuristics and approaches that MRL finds sufficiently important to study in some detail.
+
+To ease concerns in the community, we first show how Monero may be regarded as traceable, and then we explain some of the mitigating properties that the protocol enjoys. To see how Monero may be regarded as traceable, consider the first case: a transaction appears whose ring $T$ has transaction output public keys $T = \left\{T_1, T_2\right\}$ where the key $T_1$ appears in $N_1$ other ring signatures elsewhere on the blockchain and $T_2$ appears in $N_2$ other ring signatures. If $N_1 = 1$ and $N_2 = 10^5$, the \textit{a priori} likelihood that $T_1$ has been spent is much lower than the likelihood that $T_2$ has been spent. After all, $T_2$ has had $10,000$ different possible outgoing transactions reference it, but $T_1$ has only had one. Hence, if we receive a transaction with ring $T$, without any additional information, we can be reasonably sure that $T_1$ and $T_2$ are not equiprobable as possible senders of the transaction. Consider the second case: if two transactions both have ring signatures with the same ring $T  = \left\{T_1, T_2\right\}$, it is impossible that both $T_1$ and $T_2$ remain unspent, allowing an adversary to be able to determine spent transactions.
+
+Nevertheless, these examples also demonstrate the inherent problem with these approaches, especially when the mitigating properties of Monero are taken into account. The use of one-time addresses ensures that the \textit{sensitivity and specificity} of these tests are not both directly estimable (direct estimation would require unmasking the one-time addresses). Sensitivity and specificity are both critically important to assessing the goodness of any test.  To see the relevance of this in the first case, note that we can \textit{estimate} the differences in likelihood that $T_1$ or $T_2$ has been spent, but we cannot be sure and we have no reasonable way of measuring the goodness of our estimate. If a malicious user wishes to frame an innocent user in an illegal transaction, they could simply use one of their own transaction outputs that has appeared in many rings to perform an illegal transaction filled with ostensibly innocent public keys. Hence, in isolation, such analyses are unsuitable for establishing anything except circumstantial association between addresses, although they can be leveraged together to provide rather interesting analyses. 
+
+Note that the use of ring signatures also brings a combinatorial explosion to the problem of analyzing traceability, and this is exacerbated as ring sizes improve. Due to this, in the second case, although we can tell that both $T_1$ and $T_2$ have been spent, we cannot determine, for example, which was spent first. This provides two possible states ($T_1$ was spent first or not). In this case, we have two outputs, so we have two possibilities; if minimum ring sizes are $N$, then we end up with $N$ possibilities, and repeated transactions leads to an $N$-ary tree of possibilities. To establish the chain of ownership of $M$ transactions long would therefore require exploration of a space of $N^M$ possibilities. The above approaches would allow us to assign a priori likelihoods to each of these possibilities, but it is clear that a large chain of transactions (say $86$ or more transactions) with large ring sizes (say $10$) will lead to more possibilities than there are fundamental particles in the universe.
+
+We here at the Lab previously thought that one possible solution to \texttt{knaccc}'s described attack would be \textit{churning}, where one sends funds to oneself multiple times before using at a merchant. Unfortunately, this leads to chains of self-referential transactions, which leave an undesirable and identifiable statistical signal.  Investigating and improving the untraceability in Monero is a high urgency but never-ending problem. We have reason to believe that the hardness of analyzing the Monero blockchain currently is sufficient to protect user security in the short-term, especially if we implement larger ring sizes using RTRS Ring CT.
+
+
+
+
+\section{Federated ZK-Side Chains}
+
+
+\subsection{Summary:} 
+
+We at the lab are looking into temporally-restricted federated side chains running ZK-SNARK technology to improve the traceability issues described above. 
+
+\subsection{Timing and Urgency:} 
+
+This project is of unknown urgency and has been presented to us by \texttt{fluffypony} only recently. If traceability analyses seem to improve, the urgency will become quite high.
+
+\subsection{History and Details:} 
+
+Zero knowledge succinct non-interactive arguments of knowledge (ZK-SNARKs) use a trusted set-up to ensure proof against double-spend attacks. Monero does not require a trusted set-up to ensure against double-spend attacks, but suffers some traceability criticisms made as in \cite{miller2017empirical} and \cite{kumar2017traceability}. One possible solution is to run side chains utilizing zk-snark technology with finite lifespans; funds would be ``deposited'' from the Monero blockchain to the zero-knowledge side chain (zidechain), transactions on the zidechain would proceed in zero-knowledge, and then users can ``withdraw'' from the zidechain back to the main Monero blockchain before the zidechain self destructs. Double spend protection in Monero would provide users confidence that any trusted set-up used in the construction of the zidechain would not allow for double spends making it back onto the Monero blockchain \textit{without detection}; if any double-spends are detected, the zidechain can be terminated early and begun again.
+
+Some questions have been raised about the feasibility of zero knowledge succinct transparent non-interactive arguments of knowledge (ZK-STARKSs). While such constructions remove the requirement for a trusted set-up, they are currently not available in a usable and well-reviewed form. However, once rigorously-tested ZK-STARK technologies become more generally accessible, the Lab would investigate a transition from temporary ZK-SNARK zidechains toward more permanent ZK-STARK constructions.
+
+
+
+\section{New Cryptoschemes}
+
+
+\subsection{Summary:} 
+
+The Lab is constantly on the lookout for new cryptoschemes that may be useful in the Monero protocol.
+
+\subsection{Timing and Urgency:} 
+
+This project is of low to moderate urgency, but is a constant area of research with no particular goal in mind. 
+
+\subsection{History and Details:} 
+
+Before RTRS Ring CT and before Ruffing's linearity proof, the primary focus of this area was to find more efficient signatures; this is an ongoing area of research (rather than a to-do-list item) that \textit{produces new areas of research}. Every element of the Monero protocol must be considered for possible replacement in the event that various cryptoschemes are broken or if new security models are made available. 
+ 
+ 
+\section{Long-term ASIC Proofing}
+
+\subsection{Summary:}
+
+The Lab is composing a plan of action in the case that devices are manufactured that are many orders of magnitude more power-efficient at executing proof of work with our current cryptographic hash function, CryptoNight, than current computers. Our plan includes investigating alternative problems that may be helpful for a Nakamoto Proof of Work model of blockchain write access, and includes looking into variations on the Nakamoto Proof of Work model.
+
+\subsection{Timing and Urgency:}
+
+Like many other projects, this one is low to moderate urgency. We plan on having a sketch of an ASIC-proofing plan for Monero by the end of Spring 2018.
+
+\subsection{History and Details:}
+
+One of the unspoken elements of the CryptoNote white paper was a dedication to a social contract of decentralized currency. To this end, the CryptoNote creators manufactured their own memory-hard cryptographic hash function for use in Proof-of-Work; due to the access of this hash function to the L3 cache, modern computer architecture ensures that making CryptoNight ASICs will be difficult for at least several more years. However, contingency plans are great to have.
+
+The Lab is currently investigating other memory-hard problems not involving cryptographic hash functions that would be suitable for Proof of Work; we have our eye on problems that provide some utility to global economies or scientific pursuits, so that the Monero blockchain becomes not only a record of transactions but a record of solutions to difficult-to-solve problems. We are also investigating alternatives to proof of work itself, such as Proof of Storage.
+
+
+
+
+\section{Technical Papers}
+
+\subsection{Summary:}
+
+The Lab has several technical papers in preparation, some for peer review, some for internal usage at Monero, and some intended as white papers to be made public.
+
+\subsection{Timing and Urgency:}
+
+Varies by paper.
+
+\subsection{Details:}
+In addition to the items above, the following upcoming technical papers are also in the works:
+\begin{enumerate}[(i)]
+\item \textbf{Updating the CryptoNote Standards}: While the Monero code is (now) well-documented, the protocol has moved above and beyond the original CryptoNote 2.0 white paper. Especially with the advent of Ring CT, sub-addresses, and threshold multisignatures, and with the possibility of implementing RTRS Ring CT in the coming months, the need for a complete, accurate technical document is becoming quite clear. Moreover, we wish to include certain technical standards in future implementations that we should codify sooner rather than later.  As a low-level urgency project, we will be writing a new white paper (or a sequence of them) describing the current Monero protocol in detail for completion by late spring or middle summer 2018.
+
+\item \textbf{Zero-knowledge Lit Review}: This document is still in progress.  Jeffrey Quesnelle, a computer science graduate student at the University of Michigan at Dearborn is pursuing his thesis and has decided this includes some work with Monero Research Lab. He wrote a literature review of zero knowledge schemes and their application in cryptocurrencies, for submission for peer review (journal to be determined). We initially expected this to be done by the end of August 2017, but there have been delays. We will make available a pre-print on ArXiV after a few revisions. Currently, this is one of the two top priorities for \texttt{surae} and he hopes to have a draft ready for submission before the end of September 2017.
+
+\item \textbf{The Distributional Problem}: Most of the time, the true signer of a ring signature in Monero is the owner of the newest transaction in that signature. How should the distribution for mix-ins depend on transaction age? This corresponds to certain interesting approximation problems in statistics, but also certain game-theoretic questions reminiscent of \cite{T-1955}, for example. As a matter of user privacy, the urgency of this problem is rather low, due to the one-time addresses in Monero, but this problem may have some interesting low-hanging fruit. This item is identical to the previous road map and we do not anticipate significant progress on this before Spring 2018.
+
+\end{enumerate}
+
+\section{Back burner}
+
+In MRL-R001, we were ambitious and listed many projects that we anticipated movement on and thought could be fun. Unfortunately, many of these have seen no movement, because they are of low urgency. These include \textbf{testing blockchain dynamics with population-driven modeling} and \textbf{hardness of blockchain analysis} (see above about combinatorial explosions). Many late undergraduate math and computer science students may be able to assist us with these. Interested contributors with (i) experience in coding and differential equations or (ii) experience in numerical analysis can contact Monero Research Lab at \href{mailto:sarang.noether@protonmail.com}{\texttt{sarang.noether@protonmail.com}} in the interest of collaboration.
+
+In MRL-R0001, we also included the idea of future-proofing Monero, which is more of a design philosophy when approaching new schemes rather than a specific active area of research. Consequently, we are removing this as a specific item on the list and incorporating this as an attitude in our design philosophy.
+
+
+
+\section*{Conclusion}
+
+As always, the MRL team strives to provide thorough research to the community, balancing cutting-edge research with user trust, community transparency, and security of funds. The team thanks the Monero community for its support and guidance, and looks forward to continuing its mission with precision and passion. Monero remains the strongest, most innovative, and sexiest coin we know, and the Lab is proud to support its future.
+
+We request members of the community contribute their opinions on this list and ideas they would like to see added. Areas of research, possible vulnerabilities to the Monero system, new cryptographic schemes, new models, and new insights are always welcome. Please do not hesitate to contact us.  
+
+The Monero Research Lab wishes to state emphatically that our concern is to report our findings on Monero, which is an open source project, as honestly and transparently as possible. Our goal is not to persuade, re-assure, or enrich speculators or investors; our goal is to assist the Monero community and the Monero Core Team in the design of a robust and strong cryptocurrency with an emphasis on user privacy.  Consequently, all findings will \textit{eventually} be responsibly disclosed to the Monero community. Responsible disclosure may involve maintaining secrecy regarding security flaws for a period of time before disclosure to the public, which provides the development team time to correct known issues and protect our users. This also provides time to discreetly contact the developers of other cryptocurrencies so they, also, may protect their users.
+
+Some members of the Lab are supported financially by the community through the Forum Funding System and are paid in Monero for their work. Readers may view this as a conflict of interest. However, researchers are not paid for particular projects or implementations of proposals, offering some separation from direct outside influence.
+
+
+\medskip{}
+
+\bibliographystyle{plain}
+\bibliography{biblio.bib}
+
+\end{document}

source-code/RuffCT-java/src/how/monero/hodl/crypto/PointPair.java

@@ -1,37 +0,0 @@
-package how.monero.hodl.crypto;
-
-import org.nem.core.crypto.ed25519.arithmetic.Ed25519GroupElement;
-
-import static how.monero.hodl.util.ByteUtil.*;
-
-public class PointPair {
-  public Ed25519GroupElement P1;
-  public Ed25519GroupElement P2;
-  public PointPair(Ed25519GroupElement P1, Ed25519GroupElement P2) {
-    this.P1 = P1;
-    this.P2 = P2;
-  }
-  public byte[] toBytes() {
-    return concat(P1.encode().getRaw(), P2.encode().getRaw());
-  }
-  public PointPair add(PointPair a) {
-    return new PointPair(P1.toP3().add(a.P1.toP3().toCached()), P2.toP3().add(a.P2.toP3().toCached()));
-  }
-  public PointPair subtract(PointPair a) {
-    return new PointPair(P1.toP3().subtract(a.P1.toCached()), P2.toP3().subtract(a.P2.toCached()));
-  }
-  public PointPair multiply(Scalar n) {
-    return new PointPair(P1.toP3().scalarMultiply(n), P2.toP3().scalarMultiply(n));
-  }
-
-  public boolean equals(PointPair obj) {
-    return P1.toP3().equals(obj.P1.toP3()) && P2.toP3().equals(obj.P2.toP3());
-  }
-
-  @Override
-  public String toString() {
-    return "(P1: " + bytesToHex(P1.encode().getRaw()) + ", P2: " + P2 + ")";
-  }
-
-}
-

source-code/RuffCT-java/src/how/monero/hodl/cursor/BootleRuffingCursor.java

@@ -1,38 +0,0 @@
-package how.monero.hodl.cursor;
-
-import how.monero.hodl.crypto.PointPair;
-import how.monero.hodl.crypto.Scalar;
-import org.nem.core.crypto.ed25519.arithmetic.Ed25519EncodedFieldElement;
-import org.nem.core.crypto.ed25519.arithmetic.Ed25519EncodedGroupElement;
-import org.nem.core.crypto.ed25519.arithmetic.Ed25519FieldElement;
-import org.nem.core.crypto.ed25519.arithmetic.Ed25519GroupElement;
-
-public class BootleRuffingCursor extends Cursor {
-  public byte[] data;
-
-  public BootleRuffingCursor(byte[] data) {
-    super(data);
-  }
-
-  public Ed25519GroupElement readGroupElement() {
-    return new Ed25519EncodedGroupElement(readBytes(32)).decode();
-  }
-  public Ed25519FieldElement readFieldElement() {
-    return new Ed25519EncodedFieldElement(readBytes(32)).decode();
-  }
-  public PointPair[] readPointPairArray(int len) {
-    PointPair[] result = new PointPair[len];
-    for(int i=0; i<len; i++) result[i] = new PointPair(readGroupElement(), readGroupElement());
-    return result;
-  }
-  public Scalar[][] readScalar2DArray(int m, int n) {
-    Scalar[][] result = new Scalar[m][n];
-    for(int j=0; j<m; j++) {
-      for(int i=0; i<n; i++) {
-        result[j][i] = readScalar();
-      }
-    }
-    return result;
-  }
-
-}

source-code/StringCT-java/src/how/monero/hodl/crypto/CryptoUtil.java

@@ -6,7 +6,6 @@ import org.apache.commons.pool2.BasePooledObjectFactory;
 import org.apache.commons.pool2.PooledObject;
 import org.apache.commons.pool2.impl.DefaultPooledObject;
 import org.apache.commons.pool2.impl.GenericObjectPool;
-import org.nem.core.crypto.ed25519.arithmetic.*;
 
 import java.math.BigInteger;
 import java.security.SecureRandom;
@@ -14,7 +13,6 @@ import java.util.HashMap;
 import java.util.Map;
 import java.util.Random;
 
-import static how.monero.hodl.crypto.HashToPoint.hashToPoint;
 import static how.monero.hodl.util.ByteUtil.*;
 
 public class CryptoUtil {
@@ -32,12 +30,6 @@ public class CryptoUtil {
     }
   });
 
-  public static final Ed25519GroupElement G = Ed25519Group.BASE_POINT;
-  public static final Ed25519GroupElement H = new Ed25519EncodedGroupElement(hexToBytes("8b655970153799af2aeadc9ff1add0ea6c7251d54154cfa92c173a0dd39c1f94")).decode();
-  static {
-    H.precomputeForScalarMultiplication();
-  }
-
   public static Scalar hashToScalar(byte[] a) {
     return new Scalar(scReduce32(fastHash(a)));
   }
@@ -89,21 +81,15 @@ public class CryptoUtil {
   }
 
   public static final Random random = new SecureRandom();
-  public static byte[] randomPointAsBytes() {
-    return randomPoint().encode().getRaw();
-  }
-  public static Ed25519GroupElement randomPoint() {
-    return Ed25519Group.BASE_POINT.scalarMultiply(Scalar.randomScalar());
-  }
   public static byte[] randomMessage(int len) {
     byte[] m = new byte[len];
     random.nextBytes(m);
     return m;
   }
 
-  public static byte[] toBytes(Ed25519GroupElement[] a) {
+  public static byte[] toBytes(Curve25519Point[] a) {
     byte[] r = new byte[0];
-    for(Ed25519GroupElement ai : a) r = concat(r, ai.encode().getRaw());
+    for(Curve25519Point ai : a) r = concat(r, ai.toBytes());
     return r;
   }
 
@@ -115,40 +101,39 @@ public class CryptoUtil {
 
 
 
-  public static PointPair COMeg(Scalar xAmount, Scalar rMask) {
-    return new PointPair(G.scalarMultiply(xAmount).add(getHpnGLookup(1).scalarMultiply(rMask).toCached()), G.scalarMultiply(rMask));
+  public static Curve25519PointPair COMeg(Scalar xAmount, Scalar rMask) {
+    return new Curve25519PointPair(Curve25519Point.G.scalarMultiply(xAmount).add(getHpnGLookup(1).scalarMultiply(rMask)), Curve25519Point.G.scalarMultiply(rMask));
   }
 
-  public static Ed25519GroupElement COMp(Scalar xAmount, Scalar rMask) {
-    return G.scalarMultiply(xAmount).add(getHpnGLookup(1).scalarMultiply(rMask).toCached());
+  public static Curve25519Point COMp(Scalar xAmount, Scalar rMask) {
+    return Curve25519Point.G.scalarMultiply(xAmount).add(getHpnGLookup(1).scalarMultiply(rMask));
   }
 
-  public static Ed25519GroupElement COMb(Scalar[][] x, Scalar r) {
+  public static Curve25519Point COMb(Scalar[][] x, Scalar r) {
     int m = x.length;
     int n = x[0].length;
-    Ed25519GroupElement A = G.scalarMultiply(r);
+    Curve25519Point A = Curve25519Point.G.scalarMultiply(r);
     for(int j=0; j<m; j++) {
       for(int i=0; i<n; i++) {
-        A = A.toP3().add(getHpnGLookup(j * n + i + 1).scalarMultiply(x[j][i]).toCached());
+        A = A.add(getHpnGLookup(j * n + i + 1).scalarMultiply(x[j][i]));
       }
     }
     return A;
   }
 
 
-  public static Map<Integer, Ed25519GroupElement> HpnGLookup = new HashMap<>();
+  public static Map<Integer, Curve25519Point> HpnGLookup = new HashMap<>();
 
-  public static Ed25519GroupElement getHpnGLookup(int n) {
+  public static Curve25519Point getHpnGLookup(int n) {
     if(!HpnGLookup.containsKey(n)) {
-      Ed25519GroupElement HpnG = hashToPoint(G.scalarMultiply(Scalar.intToScalar(n)));
-      //HpnG.precomputeForScalarMultiplication(); // try precomputed vs non-precomputed to check best performance
+      Curve25519Point HpnG = Curve25519Point.hashToPoint(Curve25519Point.G.scalarMultiply(Scalar.intToScalar(n)));
       HpnGLookup.put(n, HpnG);
     }
     return HpnGLookup.get(n);
   }
 
-  public static PointPair ENCeg(Ed25519GroupElement X, Scalar r) {
-    return new PointPair(getHpnGLookup(1).scalarMultiply(r).toP3().add(X.toCached()), G.scalarMultiply(r));
+  public static Curve25519PointPair ENCeg(Curve25519Point X, Scalar r) {
+    return new Curve25519PointPair(getHpnGLookup(1).scalarMultiply(r).add(X), Curve25519Point.G.scalarMultiply(r));
   }
 
 

source-code/StringCT-java/src/how/monero/hodl/crypto/Curve25519Point.java

@@ -0,0 +1,98 @@
+package how.monero.hodl.crypto;
+
+import org.bouncycastle.jce.ECNamedCurveTable;
+import org.bouncycastle.jce.provider.BouncyCastleProvider;
+import org.bouncycastle.jce.spec.ECParameterSpec;
+import org.bouncycastle.math.ec.ECPoint;
+
+import java.security.Security;
+
+import java.util.Arrays;
+import java.util.Map;
+import java.util.Optional;
+import java.util.TreeMap;
+
+import static how.monero.hodl.crypto.CryptoUtil.hashToScalar;
+import static how.monero.hodl.util.ByteUtil.bytesToHex;
+
+public class Curve25519Point {
+
+  public static ECParameterSpec ecsp;
+
+  static {
+    try {
+      Security.addProvider(new BouncyCastleProvider());
+      ecsp = ECNamedCurveTable.getParameterSpec("curve25519");
+    }
+    catch (Exception e) {
+      throw new RuntimeException(e);
+    }
+  }
+
+  public ECPoint point;
+  public Curve25519Point(ECPoint point) {
+    this.point = point;
+  }
+  public Curve25519Point(byte[] a) {
+    this.point = ecsp.getCurve().decodePoint(a);
+  }
+
+  public static Curve25519Point randomPoint() {
+    return BASE_POINT.scalarMultiply(Scalar.randomScalar());
+  }
+  public Curve25519Point scalarMultiply(Scalar a) {
+    scalarMults++;
+    if(this==BASE_POINT) scalarBaseMults++;
+
+    if(enableLineRecording) {
+       Optional<StackTraceElement> optionalCaller = Arrays.stream(new Exception().getStackTrace()).filter(e -> e.getFileName().equals(lineRecordingSourceFile)).findFirst();
+       if (optionalCaller.isPresent()) {
+         StackTraceElement caller = optionalCaller.get();
+         lineNumberCallFrequencyMap.putIfAbsent(caller.getLineNumber(), 0);
+         lineNumberCallFrequencyMap.computeIfPresent(caller.getLineNumber(), (key, oldValue) -> oldValue + 1);
+       }
+     }
+
+    return new Curve25519Point(point.multiply(a.toBigInteger()));
+  }
+  public Curve25519Point add(Curve25519Point a) {
+    return new Curve25519Point(point.add(a.point));
+  }
+  public Curve25519Point subtract(Curve25519Point a) {
+    return new Curve25519Point(point.subtract(a.point));
+  }
+  public byte[] toBytes() {
+    return point.getEncoded(true);
+  }
+  public boolean satisfiesCurveEquation() {
+    return true;
+  }
+  public static Curve25519Point hashToPoint(byte[] a) {
+    return BASE_POINT.scalarMultiply(hashToScalar(a));
+  }
+  public static Curve25519Point hashToPoint(Curve25519Point a) {
+    return hashToPoint(a.toBytes());
+  }
+
+  @Override
+  public String toString() {
+    return bytesToHex(toBytes());
+  }
+
+  public static Curve25519Point ZERO = new Curve25519Point(ecsp.getCurve().getInfinity());
+  public static Curve25519Point BASE_POINT = new Curve25519Point(ecsp.getG());
+  public static Curve25519Point G = BASE_POINT;
+
+  public static int scalarMults = 0;
+ 	public static int scalarBaseMults = 0;
+
+  public static String lineRecordingSourceFile = null;
+  public static boolean enableLineRecording = false;
+ 	public static Map<Integer, Integer> lineNumberCallFrequencyMap = new TreeMap<>((a, b)->a.compareTo(b));
+
+
+  @Override
+  public boolean equals(Object obj) {
+    return point.equals(((Curve25519Point) obj).point);
+  }
+}

source-code/StringCT-java/src/how/monero/hodl/crypto/Curve25519PointPair.java

@@ -0,0 +1,35 @@
+package how.monero.hodl.crypto;
+
+import static how.monero.hodl.util.ByteUtil.*;
+
+public class Curve25519PointPair {
+  public Curve25519Point P1;
+  public Curve25519Point P2;
+  public Curve25519PointPair(Curve25519Point P1, Curve25519Point P2) {
+    this.P1 = P1;
+    this.P2 = P2;
+  }
+  public byte[] toBytes() {
+    return concat(P1.toBytes(), P2.toBytes());
+  }
+  public Curve25519PointPair add(Curve25519PointPair a) {
+    return new Curve25519PointPair(P1.add(a.P1), P2.add(a.P2));
+  }
+  public Curve25519PointPair subtract(Curve25519PointPair a) {
+    return new Curve25519PointPair(P1.subtract(a.P1), P2.subtract(a.P2));
+  }
+  public Curve25519PointPair multiply(Scalar n) {
+    return new Curve25519PointPair(P1.scalarMultiply(n), P2.scalarMultiply(n));
+  }
+
+  public boolean equals(Curve25519PointPair obj) {
+    return P1.equals(obj.P1) && P2.equals(obj.P2);
+  }
+
+  @Override
+  public String toString() {
+    return "(P1: " + bytesToHex(P1.toBytes()) + ", P2: " + P2 + ")";
+  }
+
+}
+

source-code/StringCT-java/src/how/monero/hodl/cursor/StringCTCursor.java

@@ -0,0 +1,32 @@
+package how.monero.hodl.cursor;
+
+import how.monero.hodl.crypto.Curve25519Point;
+import how.monero.hodl.crypto.Curve25519PointPair;
+import how.monero.hodl.crypto.Scalar;
+
+public class StringCTCursor extends Cursor {
+  public byte[] data;
+
+  public StringCTCursor(byte[] data) {
+    super(data);
+  }
+
+  public Curve25519Point readGroupElement() {
+    return new Curve25519Point(readBytes(32));
+  }
+  public Curve25519PointPair[] readPointPairArray(int len) {
+    Curve25519PointPair[] result = new Curve25519PointPair[len];
+    for(int i=0; i<len; i++) result[i] = new Curve25519PointPair(readGroupElement(), readGroupElement());
+    return result;
+  }
+  public Scalar[][] readScalar2DArray(int m, int n) {
+    Scalar[][] result = new Scalar[m][n];
+    for(int j=0; j<m; j++) {
+      for(int i=0; i<n; i++) {
+        result[j][i] = readScalar();
+      }
+    }
+    return result;
+  }
+
+}

source-code/StringCT-java/src/how/monero/hodl/ringSignature/Multisignature.java

@@ -1,7 +1,7 @@
 package how.monero.hodl.ringSignature;
 
+import how.monero.hodl.crypto.Curve25519Point;
 import how.monero.hodl.crypto.Scalar;
-import org.nem.core.crypto.ed25519.arithmetic.Ed25519GroupElement;
 
 import java.util.*;
 
@@ -12,10 +12,10 @@ import static how.monero.hodl.crypto.CryptoUtil.*;
 
 public class Multisignature {
 
-  public static Ed25519GroupElement[] lexicographicalSort(Ed25519GroupElement[] X) {
-    SortedMap<String, Ed25519GroupElement> hexToPoint = new TreeMap<>();
-    for(Ed25519GroupElement Xi : X) hexToPoint.put(bytesToHex(Xi.encode().getRaw()), Xi);
-    return hexToPoint.values().stream().toArray(Ed25519GroupElement[]::new);
+  public static Curve25519Point[] lexicographicalSort(Curve25519Point[] X) {
+    SortedMap<String, Curve25519Point> hexToPoint = new TreeMap<>();
+    for(Curve25519Point Xi : X) hexToPoint.put(bytesToHex(Xi.toBytes()), Xi);
+    return hexToPoint.values().stream().toArray(Curve25519Point[]::new);
   }
 
   /*
@@ -25,18 +25,18 @@ public class Multisignature {
         2) For each i=1,2,...,n, compute c[i] = Hs(X[i], R, L*, M)
         3) Accept if and only if sG = R + c[1]*X[1] + ... + c[n]*X[n]
    */
-  public static boolean verify(byte[] M, Ed25519GroupElement[] X, Signature signature) {
+  public static boolean verify(byte[] M, Curve25519Point[] X, Signature signature) {
     int n = X.length;
 
     Scalar XAsterisk = hashToScalar(toBytes(lexicographicalSort(X)));
 
     Scalar[] c = new Scalar[n];
     for(int i=0; i<n; i++) {
-      c[i] = hashToScalar(concat(X[i].encode().getRaw(), signature.R.encode().getRaw(), XAsterisk.bytes, M));
+      c[i] = hashToScalar(concat(X[i].toBytes(), signature.R.toBytes(), XAsterisk.bytes, M));
     }
-    Ed25519GroupElement sG = G.scalarMultiply(signature.s);
-    Ed25519GroupElement sG1 = signature.R;
-    for(int i=0; i<n; i++) sG1 = sG1.toP3().add(X[i].scalarMultiply(c[i]).toCached());
+    Curve25519Point sG = Curve25519Point.G.scalarMultiply(signature.s);
+    Curve25519Point sG1 = signature.R;
+    for(int i=0; i<n; i++) sG1 = sG1.add(X[i].scalarMultiply(c[i]));
     return sG.equals(sG1);
   }
 
@@ -53,12 +53,12 @@ public class Multisignature {
       5) Compute s = s[1] + ... + s[n].
       6) Output the signature sigma = (R, s)
    */
-  public static Signature sign(byte[] M, Scalar[] x, Ed25519GroupElement[] X) {
+  public static Signature sign(byte[] M, Scalar[] x, Curve25519Point[] X) {
     int n = x.length;
     if(X==null) {
-      X = new Ed25519GroupElement[n];
+      X = new Curve25519Point[n];
       for(int i=0; i<n; i++) {
-        X[i] = G.scalarMultiply(x[i]);
+        X[i] = Curve25519Point.G.scalarMultiply(x[i]);
       }
 
     }
@@ -68,11 +68,11 @@ public class Multisignature {
     for(int i=0; i<n; i++) rArray[i] = randomScalar();
     Scalar r = sumArray(rArray);
 
-    Ed25519GroupElement R = G.scalarMultiply(r);
+    Curve25519Point R = Curve25519Point.G.scalarMultiply(r);
     Scalar[] c = new Scalar[n];
     Scalar[] sArray = new Scalar[n];
     for(int i=0; i<n; i++) {
-      c[i] = hashToScalar(concat(X[i].encode().getRaw(), R.encode().getRaw(), XAsterisk.bytes, M));
+      c[i] = hashToScalar(concat(X[i].toBytes(), R.toBytes(), XAsterisk.bytes, M));
       sArray[i] = rArray[i].add(x[i].mul(c[i]));
     }
     Scalar s = sumArray(sArray);
@@ -80,13 +80,13 @@ public class Multisignature {
   }
 
   public static class Signature {
-    Ed25519GroupElement R;
+    Curve25519Point R;
     Scalar s;
-    public Signature(Ed25519GroupElement R, Scalar s) {
+    public Signature(Curve25519Point R, Scalar s) {
       this.R = R; this.s = s;
     }
     public byte[] toBytes() {
-      return concat(R.encode().getRaw(), s.bytes);
+      return concat(R.toBytes(), s.bytes);
     }
   }
 
@@ -96,13 +96,13 @@ public class Multisignature {
    */
   public static KeyPair keygen() {
     Scalar x = randomScalar();
-    Ed25519GroupElement X = G.scalarMultiply(x);
+    Curve25519Point X = Curve25519Point.G.scalarMultiply(x);
     return new KeyPair(x, X);
   }
   public static class KeyPair {
     public Scalar x;
-    public Ed25519GroupElement X;
-    public KeyPair(Scalar x, Ed25519GroupElement X) {
+    public Curve25519Point X;
+    public KeyPair(Scalar x, Curve25519Point X) {
       this.x = x; this.X = X;
     }
   }

source-code/StringCT-java/src/how/monero/hodl/ringSignature/SpendParams.java

@@ -1,16 +1,16 @@
 package how.monero.hodl.ringSignature;
 
-import how.monero.hodl.crypto.PointPair;
+import how.monero.hodl.crypto.Curve25519Point;
+import how.monero.hodl.crypto.Curve25519PointPair;
 import how.monero.hodl.crypto.Scalar;
-import org.nem.core.crypto.ed25519.arithmetic.Ed25519GroupElement;
 
 public class SpendParams {
 
   public int iAsterisk;
-  public PointPair[][] pk;
-  public BootleRuffing.SK[] sk;
-  public Ed25519GroupElement[] ki;
-  public Ed25519GroupElement[] co;
+  public Curve25519PointPair[][] pk;
+  public StringCT.SK[] sk;
+  public Curve25519Point[] ki;
+  public Curve25519Point[] co;
   public byte[] M;
   public Scalar s;
   public int decompositionBase;

source-code/StringCT-java/src/how/monero/hodl/ringSignature/StringCT.java

@@ -1,23 +1,20 @@
 package how.monero.hodl.ringSignature;
 
-import how.monero.hodl.crypto.PointPair;
+import how.monero.hodl.crypto.Curve25519Point;
+import how.monero.hodl.crypto.Curve25519PointPair;
 import how.monero.hodl.crypto.Scalar;
-import how.monero.hodl.cursor.BootleRuffingCursor;
+import how.monero.hodl.cursor.StringCTCursor;
 import how.monero.hodl.util.VarInt;
-import org.nem.core.crypto.ed25519.arithmetic.*;
 
 import java.math.BigInteger;
-import java.util.HashMap;
-import java.util.Map;
 
 import static how.monero.hodl.crypto.CryptoUtil.*;
-import static how.monero.hodl.crypto.HashToPoint.hashToPoint;
 import static how.monero.hodl.crypto.Scalar.bigIntegerArrayToScalarArray;
 import static how.monero.hodl.crypto.Scalar.randomScalar;
 import static how.monero.hodl.util.ByteUtil.*;
 
 
-public class BootleRuffing {
+public class StringCT {
 
   public static class SK {
     public Scalar r;
@@ -34,39 +31,39 @@ public class BootleRuffing {
 
   public static KeyGenResult KEYGEN() {
     SK sk = new SK(randomScalar(), randomScalar());
-    Ed25519GroupElement ki = G.scalarMultiply(sk.r1);
-    PointPair pk = ENCeg(ki, sk.r);
+    Curve25519Point ki = Curve25519Point.G.scalarMultiply(sk.r1);
+    Curve25519PointPair pk = ENCeg(ki, sk.r);
     return new KeyGenResult(sk, ki, pk);
   }
   public static class KeyGenResult {
     public SK sk;
-    public Ed25519GroupElement ki;
-    public PointPair pk = null;
-    public KeyGenResult(SK sk, Ed25519GroupElement ki, PointPair pk) {
+    public Curve25519Point ki;
+    public Curve25519PointPair pk = null;
+    public KeyGenResult(SK sk, Curve25519Point ki, Curve25519PointPair pk) {
       this.sk = sk; this.ki = ki; this.pk = pk;
     }
 
     @Override
     public String toString() {
-      return "sk: " + sk.toString() + ", ki: " + bytesToHex(ki.encode().getRaw()) + ", pk: " + (pk==null ? "(no pk)" : "pk: " + pk);
+      return "sk: " + sk.toString() + ", ki: " + bytesToHex(ki.toBytes()) + ", pk: " + (pk==null ? "(no pk)" : "pk: " + pk);
     }
   }
 
   public static class F {
-    public Ed25519GroupElement[] ki;
-    public PointPair[][] pk;
-    public Ed25519GroupElement[] co;
-    public Ed25519GroupElement co1;
+    public Curve25519Point[] ki;
+    public Curve25519PointPair[][] pk;
+    public Curve25519Point[] co;
+    public Curve25519Point co1;
     byte[] M;
-    public F(Ed25519GroupElement[] ki, PointPair[][] pk, Ed25519GroupElement[] co, Ed25519GroupElement co1, byte[] M) {
+    public F(Curve25519Point[] ki, Curve25519PointPair[][] pk, Curve25519Point[] co, Curve25519Point co1, byte[] M) {
       this.ki = ki; this.pk = pk; this.co = co; this.co1 = co1; this.M = M;
     }
     byte[] toBytes() {
       byte[] r = new byte[0];
-      for(int i=0; i<ki.length; i++) r = concat(r, ki[i].encode().getRaw());
+      for(int i=0; i<ki.length; i++) r = concat(r, ki[i].toBytes());
       for(int i=0; i<pk.length; i++) for(int j=0; j<pk[i].length; j++) r = concat(r, pk[i][j].toBytes());
-      for(int i=0; i<co.length; i++) r = concat(r, co[i].encode().getRaw());
-      r = concat(r, co1.encode().getRaw());
+      for(int i=0; i<co.length; i++) r = concat(r, co[i].toBytes());
+      r = concat(r, co1.toBytes());
       r = concat(r, M);
       return r;
     }
@@ -75,16 +72,16 @@ public class BootleRuffing {
   public static SpendSignature SPEND(SpendParams sp) {
 
     int iAsterisk = sp.iAsterisk;
-    PointPair[][] pk = sp.pk;
+    Curve25519PointPair[][] pk = sp.pk;
     SK[] sk = sp.sk;
-    Ed25519GroupElement[] ki = sp.ki;
-    Ed25519GroupElement[] co = sp.co;
+    Curve25519Point[] ki = sp.ki;
+    Curve25519Point[] co = sp.co;
     byte[] M = sp.M;
     Scalar s = sp.s;
     int decompositionBase = sp.decompositionBase;
     int decompositionExponent = sp.decompositionExponent;
 
-    Ed25519GroupElement co1 = G.scalarMultiply(s);
+    Curve25519Point co1 = Curve25519Point.G.scalarMultiply(s);
     F f = new F(ki, pk, co, co1, M);
     SubResult cf1 = SUB(f);
     Scalar s1 = s;
@@ -101,20 +98,20 @@ public class BootleRuffing {
   public static class SpendSignature {
     public int decompositionBase;
     public int decompositionExponent;
-    public Ed25519GroupElement co1;
+    public Curve25519Point co1;
     public Proof2 sigma1;
     Multisignature.Signature sigma2;
-    public SpendSignature(int decompositionBase, int decompositionExponent, Ed25519GroupElement co1, Proof2 sigma1, Multisignature.Signature sigma2) {
+    public SpendSignature(int decompositionBase, int decompositionExponent, Curve25519Point co1, Proof2 sigma1, Multisignature.Signature sigma2) {
       this.decompositionBase = decompositionBase; this.decompositionExponent = decompositionExponent; this.co1 = co1; this.sigma1 = sigma1; this.sigma2 = sigma2;
     }
     public byte[] toBytes() {
       byte[] result;
       result = concat(VarInt.writeVarInt(decompositionBase), VarInt.writeVarInt(decompositionExponent));
-      result = concat(result, co1.encode().getRaw(), sigma1.toBytes(decompositionBase, decompositionExponent), sigma2.toBytes());
+      result = concat(result, co1.toBytes(), sigma1.toBytes(decompositionBase, decompositionExponent), sigma2.toBytes());
       return result;
     }
     public static SpendSignature fromBytes(byte[] a) {
-      BootleRuffingCursor cursor = new BootleRuffingCursor(a);
+      StringCTCursor cursor = new StringCTCursor(a);
       int decompositionBase = (int) cursor.readVarInt();
       int decompositionExponent = (int) cursor.readVarInt();
       return new SpendSignature(decompositionBase, decompositionExponent,
@@ -131,15 +128,15 @@ public class BootleRuffing {
   public static SubResult SUB(F fin) {
     int L = fin.pk.length; // inputs
     int N = fin.pk[0].length; // ring size
-    PointPair[] pkz = new PointPair[L];
+    Curve25519PointPair[] pkz = new Curve25519PointPair[L];
     Scalar[] f = new Scalar[L];
     for(int j=0; j<L; j++) {
-      pkz[j] = new PointPair(fin.ki[j], Ed25519Group.ZERO_P3);
-      f[j] = hashToScalar(concat(fin.ki[j].encode().getRaw(), fin.toBytes(), longToLittleEndianUint32ByteArray(j)));
+      pkz[j] = new Curve25519PointPair(fin.ki[j], Curve25519Point.ZERO);
+      f[j] = hashToScalar(concat(fin.ki[j].toBytes(), fin.toBytes(), longToLittleEndianUint32ByteArray(j)));
     }
-    PointPair[] c = new PointPair[N];
+    Curve25519PointPair[] c = new Curve25519PointPair[N];
     for(int i=0; i<N; i++) {
-      c[i] = new PointPair(fin.co[i], fin.co1);
+      c[i] = new Curve25519PointPair(fin.co[i], fin.co1);
       for(int j=0; j<L; j++) {
         c[i] = c[i].add( (fin.pk[j][i].subtract(pkz[j])).multiply(f[j]) );
       }
@@ -147,9 +144,9 @@ public class BootleRuffing {
     return new SubResult(c, f);
   }
   public static class SubResult {
-    public PointPair[] c;
+    public Curve25519PointPair[] c;
     public Scalar[] f;
-    public SubResult(PointPair[] c, Scalar[] f) {
+    public SubResult(Curve25519PointPair[] c, Scalar[] f) {
       this.c = c; this.f = f;
     }
   }
@@ -177,7 +174,7 @@ public class BootleRuffing {
       }
     }
 
-    Ed25519GroupElement A = COMb(a, rA);
+    Curve25519Point A = COMb(a, rA);
 
     Scalar[][] c = new Scalar[m][n];
     Scalar[][] d = new Scalar[m][n];
@@ -188,10 +185,10 @@ public class BootleRuffing {
       }
     }
 
-    Ed25519GroupElement C = COMb(c, rC);
-    Ed25519GroupElement D = COMb(d, rD);
+    Curve25519Point C = COMb(c, rC);
+    Curve25519Point D = COMb(d, rD);
 
-    Scalar x = hashToScalar(concat(A.encode().getRaw(), C.encode().getRaw(), D.encode().getRaw()));
+    Scalar x = hashToScalar(concat(A.toBytes(), C.toBytes(), D.toBytes()));
 
     Scalar[][] f = new Scalar[m][n];
     for(int j=0; j<m; j++) {
@@ -214,20 +211,20 @@ public class BootleRuffing {
   }
 
   public static class Proof1 {
-    public Ed25519GroupElement A;
-    public Ed25519GroupElement C;
-    public Ed25519GroupElement D;
+    public Curve25519Point A;
+    public Curve25519Point C;
+    public Curve25519Point D;
     private Scalar[][] fTrimmed;
     private Scalar zA;
     private Scalar zC;
     public transient Scalar[][] a;
 
-    private Proof1(Ed25519GroupElement A, Ed25519GroupElement C, Ed25519GroupElement D, Scalar[][] fTrimmed,
+    private Proof1(Curve25519Point A, Curve25519Point C, Curve25519Point D, Scalar[][] fTrimmed,
                   Scalar zA, Scalar zC, Scalar[][] a) {
       this.A = A; this.C = C; this.D = D; this.fTrimmed = fTrimmed; this.zA = zA; this.zC = zC; this.a = a;
     }
     private byte[] toBytes(int decompositionBase, int decompositionExponent) {
-      byte[] result = concat(A.encode().getRaw(), C.encode().getRaw(), D.encode().getRaw());
+      byte[] result = concat(A.toBytes(), C.toBytes(), D.toBytes());
       for(int j=0; j<decompositionExponent; j++) {
         for(int i=0; i<decompositionBase-1; i++) {
           result = concat(result, fTrimmed[j][i].bytes);
@@ -238,7 +235,7 @@ public class BootleRuffing {
     }
   }
 
-  public static Proof2 PROVE2(PointPair[] co, int iAsterisk, Scalar r, int inputs, int decompositionBase, int decompositionExponent) {
+  public static Proof2 PROVE2(Curve25519PointPair[] co, int iAsterisk, Scalar r, int inputs, int decompositionBase, int decompositionExponent) {
 
     int ringSize = (int) Math.pow(decompositionBase, decompositionExponent);
 
@@ -256,22 +253,22 @@ public class BootleRuffing {
       }
     }
 
-    Ed25519GroupElement B = COMb(d, rB);
+    Curve25519Point B = COMb(d, rB);
 
     Proof1 P = PROVE1(d, rB);
 
     Scalar[][] coefs = COEFS(P.a, iAsterisk);
 
-    PointPair[] G = new PointPair[decompositionExponent];
+    Curve25519PointPair[] G = new Curve25519PointPair[decompositionExponent];
 
     for(int k=0; k<decompositionExponent; k++) {
-      G[k] = ENCeg(Ed25519Group.ZERO_P3, u[k]);
+      G[k] = ENCeg(Curve25519Point.ZERO, u[k]);
       for (int i = 0; i < ringSize; i++) {
         G[k] = G[k].add(co[i].multiply(coefs[i][k]));
       }
     }
 
-    byte[] bytes = concat(P.A.encode().getRaw(), P.C.encode().getRaw(), P.D.encode().getRaw());
+    byte[] bytes = concat(P.A.toBytes(), P.C.toBytes(), P.D.toBytes());
     Scalar x1 = hashToScalar(bytes);
 
     Scalar z = r.mul(x1.pow(decompositionExponent));
@@ -284,11 +281,11 @@ public class BootleRuffing {
 
   public static class Proof2 {
     Proof1 P;
-    public Ed25519GroupElement B;
-    public PointPair[] G;
+    public Curve25519Point B;
+    public Curve25519PointPair[] G;
     public Scalar z;
 
-    private Proof2(Proof1 P, Ed25519GroupElement B, PointPair[] G, Scalar z) {
+    private Proof2(Proof1 P, Curve25519Point B, Curve25519PointPair[] G, Scalar z) {
       this.P = P;
       this.B = B;
       this.G = G;
@@ -297,8 +294,8 @@ public class BootleRuffing {
 
     private byte[] toBytes(int decompositionBase, int decompositionExponent) {
       byte[] bytes;
-      bytes = concat(P.toBytes(decompositionBase, decompositionExponent), B.encode().getRaw());
-      for(PointPair g : G) bytes = concat(bytes, g.toBytes());
+      bytes = concat(P.toBytes(decompositionBase, decompositionExponent), B.toBytes());
+      for(Curve25519PointPair g : G) bytes = concat(bytes, g.toBytes());
       bytes = concat(bytes, z.bytes);
       return bytes;
     }
@@ -321,7 +318,7 @@ public class BootleRuffing {
     return r;
   }
 
-  public static boolean VALID1(Ed25519GroupElement B, Proof1 P) {
+  public static boolean VALID1(Curve25519Point B, Proof1 P) {
     boolean abcdOnCurve =
       P.A.satisfiesCurveEquation()
       && B.satisfiesCurveEquation()
@@ -342,7 +339,7 @@ public class BootleRuffing {
       }
     }
 
-    Scalar x = hashToScalar(concat(P.A.encode().getRaw(), P.C.encode().getRaw(), P.D.encode().getRaw()));
+    Scalar x = hashToScalar(concat(P.A.toBytes(), P.C.toBytes(), P.D.toBytes()));
 
     for(int j=0; j<m; j++) {
       f[j][0] = x;
@@ -369,11 +366,11 @@ public class BootleRuffing {
       }
     }
 
-    if(!B.toP3().scalarMultiply(x).toP3().add(P.A.toP3().toCached()).equals(COMb(f, P.zA))) {
+    if(!B.scalarMultiply(x).add(P.A).equals(COMb(f, P.zA))) {
       System.out.println("VALID1: FAILED xB + A == COMp(f[0][0], ..., f[m-1][n-1]; z[A])");
       return false;
     }
-    if(!P.C.toP3().scalarMultiply(x).toP3().add(P.D.toP3().toCached()).equals(COMb(f1, P.zC))) {
+    if(!P.C.scalarMultiply(x).add(P.D).equals(COMb(f1, P.zC))) {
       System.out.println("VALID1: FAILED xC + D == COMp(f'[0][0], ..., f'[m-1][n-1]; z[C])");
       return false;
     }
@@ -382,7 +379,7 @@ public class BootleRuffing {
 
   }
 
-  public static boolean VALID2(int decompositionBase, Proof2 P1, PointPair[] co) {
+  public static boolean VALID2(int decompositionBase, Proof2 P1, Curve25519PointPair[] co) {
 
     boolean abcdOnCurve =
       P1.P.A.satisfiesCurveEquation()
@@ -399,7 +396,7 @@ public class BootleRuffing {
       return false;
     }
 
-    Scalar x1 = hashToScalar(concat(P1.P.A.encode().getRaw(), P1.P.C.encode().getRaw(), P1.P.D.encode().getRaw()));
+    Scalar x1 = hashToScalar(concat(P1.P.A.toBytes(), P1.P.C.toBytes(), P1.P.D.toBytes()));
 
     int decompositionExponent = P1.P.fTrimmed.length;
     Scalar[][] f = new Scalar[decompositionExponent][decompositionBase];
@@ -411,9 +408,9 @@ public class BootleRuffing {
 
     int ringSize = (int) Math.pow(decompositionBase, decompositionExponent);
 
-    PointPair c = ENCeg(Ed25519Group.ZERO_P3, P1.z);
+    Curve25519PointPair c = ENCeg(Curve25519Point.ZERO, P1.z);
 
-    Scalar x = hashToScalar(concat(P1.P.A.encode().getRaw(), P1.P.C.encode().getRaw(), P1.P.D.encode().getRaw()));
+    Scalar x = hashToScalar(concat(P1.P.A.toBytes(), P1.P.C.toBytes(), P1.P.D.toBytes()));
     for(int j=0; j<decompositionExponent; j++) {
       f[j][0] = x;
       for(int i=1; i<decompositionBase; i++) {
@@ -427,7 +424,7 @@ public class BootleRuffing {
       g[0] = g[0].mul(f[j][0]);
     }
 
-    PointPair c1 = co[0].multiply(g[0]);
+    Curve25519PointPair c1 = co[0].multiply(g[0]);
     for(int i=1; i<ringSize; i++) {
       int[] iSequence = nAryDecompose(decompositionBase, i, decompositionExponent);
       g[i] = f[0][iSequence[0]];
@@ -445,14 +442,14 @@ public class BootleRuffing {
     boolean result = c1.equals(c);
     if(!result) {
       System.out.println("VALID2: FAILED: c' != c");
-      System.out.println("c:  (" + bytesToHex(c.P1.encode().getRaw()) + ", " + bytesToHex(c.P2.encode().getRaw()));
-      System.out.println("c': (" + bytesToHex(c1.P1.encode().getRaw()) + ", " + bytesToHex(c1.P2.encode().getRaw()));
+      System.out.println("c:  (" + bytesToHex(c.P1.toBytes()) + ", " + bytesToHex(c.P2.toBytes()));
+      System.out.println("c': (" + bytesToHex(c1.P1.toBytes()) + ", " + bytesToHex(c1.P2.toBytes()));
     }
     return result;
 
   }
 
-  public static boolean VER(Ed25519GroupElement[] ki, PointPair[][] pk, Ed25519GroupElement[] co, Ed25519GroupElement co1, byte[] M, SpendSignature spendSignature) {
+  public static boolean VER(Curve25519Point[] ki, Curve25519PointPair[][] pk, Curve25519Point[] co, Curve25519Point co1, byte[] M, SpendSignature spendSignature) {
 
     F f = new F(ki, pk, co, co1, M);
 
@@ -473,11 +470,11 @@ public class BootleRuffing {
 
   public static class Output {
     public SK sk;
-    public Ed25519GroupElement ki;
-    public PointPair pk;
+    public Curve25519Point ki;
+    public Curve25519PointPair pk;
 
     public Scalar mask;
-    public Ed25519GroupElement co;
+    public Curve25519Point co;
     public BigInteger amount;
     public static Output genRandomOutput(BigInteger amount) {
       Output o = new Output();