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.