Privacy, anonymity, or confidentiality?
More often than not, the words “privacy”, “anonymity” and “confidentiality” get confused or used interchangeably. The consequence is that websites, platforms, or social networks are labelled private even when they are actually not. This can bring extremely dangerous consequences to the security of our own personal data. Our private information is collected, tracked and shared, and in a heartbeat everyone (or more people than we would want to share it with) has access to our most private information.
As mentioned in the previous article, the imposition of GDPR requirements compliance in 2018 has largely helped containing the issue. However, to really protect our own data, it is extremely important for everyone to have a clear idea of the correct, comprehensive meaning of “private” when we are surfing the web.
This article, third in a series dedicated to privacy, decentralized identity and data protection, tries to provide a comprehensive and easily understandable set of definitions of anonymity, privacy, and confidentiality, by applying the concept to blockchain solutions and by means of a short explanation of a real-life example named MimbleWimble. Finally, it will engage in a brief discussion on the highly debated concept of online privacy, by mentioning some of the points today being found for and against it.
Aren’t blockchains always private?
The short answer to the above question is no. To mention a well-known example, it is often said that Bitcoin is not private. However, it could be argued that Bitcoin does not reveal the names of the transactors, nor their passport IDs. So why is it not private? To provide a comprehensive explanation to why it is so, it is obviously quite crucial to start defining what it is meant by privacy.
In order to grant the validity of transactions and avoid issues like double spending, Bitcoin simply cannot be private. This is due to the fact that Bitcoin gives up on both confidentiality and anonymity, the two properties that make a transaction actually private. Let’s give a brief definition of the two terms:
- Anonymity refers to the ability of a platform to hide the identities of both the sender(s) and the recipient(s) in a transaction. Bitcoin is pseudonymous, not anonymous. As a matter of fact, addresses of users on the Bitcoin platform are permanent and, as the transactions made by users are registered on the blockchain, there exists a history of transactions. This means that if you have enough tech skills and computer processing capacity, you may as well be able to trace back a transaction history to the point that you dig out the real identity of a transacting node.
- Confidentiality refers instead to the ability of the protocol to hide the amount that is being transacted at any given point. However, in order to avoid double spending problems, amounts of the transactions on Bitcoin shall be made public.
In summary, it can be argued that a blockchain platform may be defined private if and only if it fulfils two requirements, i.e. anonymity and confidentiality. By the same token, any tool that is either anonymous, or confidential, but not both, cannot be defined to be private.
Now that privacy has been defined, we can try to answer a next question: why is it so important?
We mentioned before data protection. When transactions completely hide both our identities and what we are transacting (i.e. what is happening and who is making it happen), no one viewing the blockchain can trace any piece of information back to us. Our data gets fully protected. Therefore, no leakage or theft of data can be performed, for example, by outsider companies to draw our consumer profiles and shoot us with marketing interventions. Our data is something we own. We should have the right and ability to share it if and only if we pose our consent. This also greatly increases safety for us as both citizens and consumers.
Next, it is of common understanding that decentralization is one of the main features characterizing blockchain, i.e. one of the characteristics that make blockchain truly valuable. What decentralization embeds is the inability of any one honeypot to be the core responsible agent of your private data.When translating this concept to data protection, this, in turn, implies that No One Else Than Yourself is responsible for your own data. When your data is not private, it means that someone other than you can see it. And this implies, by the above reasoning, that the blockchain shall not be defined to be fully decentralized, which, funnily enough, shall be the very core feature of a blockchain.
Privacy has been a huge field of research in the past couple of years, and some private platforms, protocols, and coins have been given birth to around the globe. Among the most relevant, the following are worth mentioning:
Although there are many more names that may be quoted, the above are the most relevant for our “privacy in blockchain” saga. In this article, we will focus specifically on MimbleWimble, which is the protocol on which Grin and Beam implementations are built.
A Little Bit of History about MimbleWimble
In July 2016, some user in a blockchain chat room going under the pseudonym os Tom Elvis Jedusor, i.e. the French name of Voldemort in the Harry Potter saga, published a stunningly ground-breaking paper. The whitepaper was entitled “MimbleWimble”, just like the Harry Potter’s book tongue-tying spell used by the magicians, which could prevent any person from talking about any given topic.
Despite being fun and quite engaging, the chosen name was far from being casual. As a matter of fact, MimbleWimble protocol is designed to prevent its users from “talking about” the senders, the receivers, and the amounts of the transactions which take place at any given time on the blockchain. In other words, MimbleWimble preserves the two crucial features our dear Satoshi Nakamoto had to give up on, i.e. confidentiality and anonymity.
How does MimbleWimble achieves what other protocols before tried to obtain and did not succeed in doing? To give a very short preview of what will be discussed in the coming paragraphs, MimbleWimble utilizes Confidential Transactions and CoinJoin. Among many tools available on the market , MimbleWimble chooses two known methods, both from 2013,to which it implements some changes to achieve the purposes of confidentiality and anonymity. Confidentiality, i.e. hiding the transaction amounts, is achieved via the use of Confidential Transactions, while anonymity, to hide the senders and the recipients in any given transaction, is achieved through the use of CoinJoin.
Confidentiality: Pedersen Commitments and Confidential Transactions
Confidential Transactions as a tool were proposed by Adam Back on Bitcointalk forum in 2013. They allowed the senders to encrypt the values being transacted via the use of blinding factors, which are random encrypting values chosen by the sender. This feature is what allows to really achieve confidentiality. The blinding factors, which we can define as random strings, get multiplied by all inputs and all outputs of any given transaction, and therefore values get obscured.
A major pillar on which Confidential Transactions build is what we refer to as Pedersen Commitments, which belong to the family of cryptographic primitives called Commitments. Commitments, in general, shall satisfy two properties:
Binding ensures that commitments cannot be changed later on, after they have been agreed upon, while hiding makes sure that adversaries are prevented from finding the original transaction amounts.
A commitment scheme may be constructed using a cryptographic hash, by hashing together the data and a blinding factor, and then revealing the hash in order to allow for verifiability of the scheme. By the same token, the cryptographic primitive ensures that the operation cannot be reversed to display the original data.
The line below shows an example of commitment equation. A blinding factor is concatenated with the data and then encrypted with an encrypting function.
commitment = SHA256(blinding_factor||data)
The blinding factor must be included because, without one, the data could potentially be guessed (if it’s simple and small), by comparing the guess to the commitment.
Now that we have introduced cryptographic Commitments, let’s now turn to our real focus: Pedersen Commitments.
A Pedersen Commitment works exactly like what has been described in the above paragraphs, with an additional property, i.e. commitments can be added to each other. The addition of the commitments in a Pedersen Commitment shall equal the commitment to the sum of the data, with a blinding key set as the sum of the blinding keys.
The line below displays what this means in practice:
C(BF1, data1) + C(BF2, data2) == C(BF1 + BF2, data1 + data2)
Pedersen Commitments in MimbleWimble
What is ground-breaking about MimbleWimble here is that Mr. Jedusor realized that Pedersen Commitments to 0 can be plotted as elliptic curves, which are known tools for holding massively important implementations in cryptography. (As an example, elliptic curves allow for the development of extremely fast and secure cryptographic signatures, such as Schnorr or BLS signatures).
The idea of summing up commitments to zero traces back to our good old friend the UTXO system, which Bitcoin implements, whereby the sum of all the inputs and all the outputs of a transaction shall always sum up to zero for validity of the transaction to be granted. This ensures that when a transaction is engaged in, no new coins are created out of thin air.
Anonymity: CoinJoin blending properties
Now that we have explored how MimbleWimble achieves confidentiality, let’s turn our focus to how the protocol achieves anonymity.
In order to allow for anonymity, i.e. the identities of the sender and the receiver in a transaction are hidden, MimbleWimble adopts the concept of CoinJoin, an idea brought up by the well-known Gregory Maxwell in 2013, in order to fill in the privacy gap created by Bitcoin.
The basic idea behind CoinJoin is that payments from multiple spenders, i.e. all imputs and outputs belonging to the transactions of multiple users that decided to merge, get combined to form a single transaction. This makes it very difficult to determine which payment is destined to which recipient, because any outsider will be completely prevented from definitely matching which inputs in the transaction correspond to which outputs. To a certain extent, CoinJoin may resemble a big blender. Once you put all the ingredients inside, it is really hard to determine the exact content of your smoothie.
Why is MimbleWimble good, though?
But why so much hype around MimbleWimble? MimbleWimble satisfies three fundamental properties, via the use of some strong cryptographic primitives that allow it to achieve privacy, fungibility, and scalability.
- Privacy refers to the ability of the protocol to grant both anonymity and confidentiality to all users on the chain. As the topic has been thoroughly covered in the previous paragraphs, no further exaplanation shall be made here;
- Fungibility refers to the ability of one unit of currency to be exchanged for another unit without loss of value. While a MimbleWimble-based coin is always worth the same, dirty Bitcoins are tainted, and as they may be no longer accepted by merchants they lose some of their value. This is due to the fact that bitcoins always have a history, while MimbleWimble protocol establishes that, at each transaction, the amount of coins at stake is burned and minted fresh again;
- Scalability refers to the ability of a protocol to host a high number of transactions. Bitcoin is sadly known for handling 4TPS and having a block size limit of 1KB. MimbleWimble, on the other hand, implements a number of features that largely contribute to shrinking the block size and making the protocol much more scalable than Bitcoin. Some of these features are the following:
- Elliptic curve cryptography that requires smaller keys than other cryptography types;
- MimbleWimble’s cut-through allows the protocol to aggregate intermediary inputs and outputs to shrink block size. A block in MimbleWimble would then contain the following elements: block header, list of all inputs after the cut through, list of all the outputs after the cut through, transaction kernel, kernel offset. A transaction kernel ensures ownership of the money, as it contains the public key, the signature, and the transaction fee that has been paid. The kernel offset is instead a blinding factor included in the block to prevent it from being reconstructed by malicious actors.
Privacy, not only in blockchain but in most online environments, has been a heavily studied field of research during the past years. First and foremost, privacy in online contexts is undeoubtedly an essential source for granting the protection of our own sensitive data. Furthermore, online privacy could allow for true freedom of speech and expression, above governments, or just the bias given by our own identity, as we may sometimes be reluctant to speak up for the fear of hurting someone we know.
Nevertheless, the concept is also highly debated. While the above is undoubtedly a contribution to fair points in favor of privacy, some relevant issues arise when identities and transaction amounts become completely hidden. Among the greatest points against full privacy implementation in online contexts, regulatory entities have mentioned taxation law, criminal activity, and anti-terroristic practices. However other important problems are also feared under the sky of privacy. To mention one simple example, think of the threat that may be posed by cyberbullying under such circumstances, when bullies have their identities completely hidden and their real-life indentities therefore cannot be traced.
To conclude, privacy could bring out both the best and the worst of us. In practice, while, on the one hand, privacy may represent a threat to regulators and government entities, the size of the market for private coins may be reasonably expected to subtantially grow in the coming years, last but not least given the likely approval from EU authorities of Zero-Knowledge Proofs as a means to achieve privacy and subsequent exemption from GDPR requirements. Nevertheless, the knot of privacy has not been untied yet, and lengthy discussions on the matter are still yet to come. What will be decided is still unknown. Stay tuned and wait for the next articles to know more about the topic!
To learn more about MimbleWimble, or just for a more graphic interface, you can click on the following link to the YouTube video: