A brief history of the Monero development

Part 2
After the hard fork, on January 10, 2017, the RingCT protocol, which we described in the previous part, was included in Monero transactions, starting from block 1220516. By default, transactions included a RingCT signature, but before the hard fork in September 2017 it was still possible to create them without RingCT. In the first month after the implementation, it was reported that approximately 50-60% of the transfers contained RingCT, so users appreciated its benefits.

As mentioned in the previous part, one of the main problems in implementing RingCT was the large transaction size. Despite the fact that after the introduction of RingCT, there was no need to denominate the transfer amount to fragments with a fixed denomination, the size of the transactions as a whole remained large (~ 12.6kB for a typical transaction with one input and two outputs). This has become one of the motivations in the search for a new, more advanced protocol.

In August 2017, the work of RingCT 2.0 was presented by authors from a number of universities in China, the University of Melbourne, as well as an employee of Huawei. The authors set two tasks: determining strict security criteria for the RingCT protocol and all its future versions, as well as developing a new version of the protocol in which the size of the signature does not depend on the number of groups of accounts participating in the transaction. Here and after, we are more interested in solving the second problem.

RingCT 2.0 is based on simpler concepts, such as Pederson's obligation (we know from the previous part), as well as a one-way domain accumulator and a signature of knowledge related to this accumulator. Together, they serve as a linkable ring signature. A detailed description of the interpretation of RingCT 2.0 used in Monero and a Python demo code with examples are given here.

Let's get it right.
A one-way accumulator was first proposed in 1994 by Josh Benalo and Michael de Mare of Clarkson University and Giordano Automation. The authors were among the first to propose a decentralized alternative to digital signature. In fact, an accumulator is a one-way function, confirming that something belongs to a certain group, without revealing individual members of the group. An important property of the battery is that the structure with the contents of the commit received as a result of the algorithm has a constant size.

Surprisingly enough, in 2013, in one work known in narrow circles, it was proposed to use an accumulator to confirm that the transaction is valid and not created from a thin air. Thus, at the current stage of development, Monero and coins based on the Zerocoin protocol are, if not the closest, then at least some relatives.

An important point about Zerocoin: in the original protocol there was one condition, namely:

Our application requires specific properties from the accumulator. With no trusted parties, the accumulator and its associated witnesses must be publicly computable and verifiable (though we are willing to relax this requirement to include a single, trusted setup phase in which parameters are generated).

This point will be important soon, but for now we are returning to RingCT 2.0.

Signature of knowledge was proposed in 1997 by Swiss researchers from ETH Zurich (Higher Technical School) and UBS Bank. Their work was devoted to group signatures, and solved the problem of the linear dependence of the size of the public key on the size of the group. In order not to create confusion with proof of knowledge, zero-knowledge proof, etc., and also to emphasize that the proof created can be used as a signature, it was decided to name signature of knowledge.

How does it all work together?

An accumulator with a one-way domain is used to reduce Pederson's commitment size compared to the commitments of RingCT 1.0 version (the obtained value does not depend on the number of account groups), and signature of knowledge is used to reduce the Multilayered Linkable Spontaneous Anonymous Group Signature, which is used in RingCT 1.0. In fact, almost the entire CryptoNote family no longer uses classic ring signatures, it has been replaced by MLSAG, a version of similar single-layer ring signatures adapted for several inputs, LSAG.

In all of this, as the observant reader will note, there is one thing but: since the accumulator uses "trusted setup", the nodes must trust each other at the initial stage. For this reason, at the first stage in the Monero community, they refused to use RingCT 2.0. The main problem is that there may be an insider in the "ring", which, by indirect signs, thanks to the "trusted setup", can figure out who signed the transaction.

The story, as it seems, did not end there — the same team of authors, having joined the ranks by colleagues from Shanghai Jiao Tong University, in 2019 released work on RingCT 3.0. The authors present the most compact in size (according to their assurance) ring signature in history without a "trusted setup". Since this upgrade did not happen on the Monero network at the time of writing (and there are no plans, as far as we know), we will not consider this case. Instead, we would like to approach the topic that is most relevant to us — Bulletproof technology, and how we at CUTcoin Labs use it to create tokens with unprecedented anonymity, which opens up great opportunities for tokenizing any assets, as well as developing a DeFi application.

We will write about this in the next article. Stay tuned.