History of the Monero development
We wrote full story which will allow you to know about CryptoNote and Monero intricacies.
A brief history of the Monero development
Part I
Part I
or a struggle for anonymity and confidentiality of transaction blockchain
The issues of privacy of electronic currency faced researchers and developers for a long time, long before Bitcoin. In 1991, Tatsuaki Okamoto and Kazuo Ohta from the NTT research laboratory (Japan's largest telecommunications company) introduced 6 criteria for an ideal e-currency, including privacy: "relationship between the user and his purchases must be untraceable by anyone". Nicholas van Saberhagen, an anonymous author behind the work on the CryptoNote protocol, which formed the basis of Monero, in December 2012 summarized these 6 criteria to two specific properties:
Untraceability: for every incoming transaction, all possible senders are equally likely.
Unlinkability: for any two outgoing transactions, it is impossible to prove that they were sent to the same person.
None of the other properties are characteristic of Bitcoin, since all transactions are broadcasted publicly. Of course, by the time this work was written, various tumblers made it possible to combine outputs of several transactions and send them through some intermediate address. Also, by that time, some protocols based on the zero-knowledge proof were known, but at that time such evidence was large enough to make them impractical to use.
What was proposed to tackle the issues: firstly, each transaction was signed on behalf of the group, not the individual, as in BTC. To do this, we used the option of an electronic digital signature called "Ring Signature" (further development of the so-called "Group Signature"). However, when implementing a completely anonymous ring signature, a (very high) probability of double spending of coins arose, and therefore the so-called linkable anonymity primitive was taken, which was implemented through a one-time-key mechanism (i.e., when creating each new transaction, the group key changes).
Essentially, although it's certainly worth noting that the CryptoNote implementation used a different scheme of elliptical curves (EdDSA instead of ECDSA, as a result, an elliptic curve with a different equation was used, etc.).
Untraceability: for every incoming transaction, all possible senders are equally likely.
Unlinkability: for any two outgoing transactions, it is impossible to prove that they were sent to the same person.
None of the other properties are characteristic of Bitcoin, since all transactions are broadcasted publicly. Of course, by the time this work was written, various tumblers made it possible to combine outputs of several transactions and send them through some intermediate address. Also, by that time, some protocols based on the zero-knowledge proof were known, but at that time such evidence was large enough to make them impractical to use.
What was proposed to tackle the issues: firstly, each transaction was signed on behalf of the group, not the individual, as in BTC. To do this, we used the option of an electronic digital signature called "Ring Signature" (further development of the so-called "Group Signature"). However, when implementing a completely anonymous ring signature, a (very high) probability of double spending of coins arose, and therefore the so-called linkable anonymity primitive was taken, which was implemented through a one-time-key mechanism (i.e., when creating each new transaction, the group key changes).
Essentially, although it's certainly worth noting that the CryptoNote implementation used a different scheme of elliptical curves (EdDSA instead of ECDSA, as a result, an elliptic curve with a different equation was used, etc.).
Anonymity achieved, but what about privacy? RingCT to the rescue
You know how it happens: everything seems to be there, but something is missing. The problem with the original CryptoNote protocol was that the user balances were not hidden, and thus, it was possible to analyze the blockchain and deanonymize the members of the group who signed the transaction. An additional problem with hiding balances is that with simple encryption of balances, it is not possible to reach a consensus on whether coins were produced from the thin air or not.
To solve this problem, the developer Shen Noether from Monero Research Lab proposed the use of the Pederson Commitment, which allows the prover to calculate the obligation for the amount without disclosing it and being unable to change it.
Short explanation from Monero Wiki:
To solve this problem, the developer Shen Noether from Monero Research Lab proposed the use of the Pederson Commitment, which allows the prover to calculate the obligation for the amount without disclosing it and being unable to change it.
Short explanation from Monero Wiki:
As long as the encrypted output amounts created, which include an output for the recipient and a change output back to the sender, and the unencrypted transaction fee is equal to the sum of the inputs that are being spent, it is a legitimate transaction and can be confirmed to not be creating Monero out of thin air.
Thus, it is possible to obtain a ring confidential transaction (hence the name). And, the inquisitive reader will ask, what is wrong this time?
The problem is one, but twofold. On the one hand, the size of the transaction increases with RingCT, which does not have the best effect on scalability and transaction fees. Besides, again, due to the large size of the signature, the number of possible subscribers n is limited. So, the n value in the official software of Monero wallet is from 5 to 20 by default. As a result, the sender anonymity for RingCT1.0 is at most 1 out of 20.
The problem is one, but twofold. On the one hand, the size of the transaction increases with RingCT, which does not have the best effect on scalability and transaction fees. Besides, again, due to the large size of the signature, the number of possible subscribers n is limited. So, the n value in the official software of Monero wallet is from 5 to 20 by default. As a result, the sender anonymity for RingCT1.0 is at most 1 out of 20.
A brief history of the Monero development
Part I I
Part I I
or a pursuit for transaction size
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.
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.
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.
Official CUTcoin dev team wallet for donations! You're welcome cutb9vuXgqtS2fDGRRptm8QHdQb4NQv1ZWBDhUCzQAjYcCggvgTcvSsZX6WetiXw1p3HpTgAhTdmniSRwzqKNPDW4mUQt5FZsW
Official CUTcoin dev team wallet for donations! You're welcome :)
cutb9vuXgqtS2fDGRRptm8QHdQb4NQv1ZWBDhUCzQAjYcCggvgTcvSsZX6WetiXw1p3HpTgAhTdmniSRwzqKNPDW4mUQt5FZsW