In this article, we tried to answer the question of what privacy is and how it can be achieved in Bitcoin and other digital currencies. In addition, here you will learn about specific mechanisms for achieving confidentiality, as well as how they are applied in practice. The topic will be of interest to those who directly work with cryptocurrencies, as well as to fans of protocols that increase the level of user privacy.
The concept of privacy includes two main components: untraceability and anonymity. Untraceability, or non-traceability, implies the inability to attribute a group of actions to a certain user on the network. Anonymity, or anonymity, is associated with the inability to reliably identify a user on this network.
Let's say that for each incoming payment or change, the user creates a new address. In this case, the auditor analyzing the transaction graph can no longer reliably connect specific facts that relate to the actions of users and the distribution of currency between them. But even in this situation, privacy is not as secure as it might seem.
Typically, in the Bitcoin network, your privacy depends on your counterparties. The one who accepts the payment knows the history of the coins, and the one who sends the coins knows where he is transferring them. Moreover, there is a number of metadata that may be available to outsiders: the nature of the transaction, wallet data, user location data, etc.
What transaction data should be hidden first of all in order to ensure the maximum level of confidentiality? This includes information about the origin of coins, which relates to the property of interchangeability, or fungibility. It is very important for any money and valuables. At the Bitcoin protocol level, this property is ensured (all coins are the same and the rules for their processing are common to all), but in practice fungibility is easy to break. For example, some merchants may analyze the origin history of accepted coins and reject payments if they have doubts about it.
The next thing that makes sense to hide is the amount of transfers, sender and recipient addresses in the transaction body. It is also important to hide the network addresses of users, which is usually achieved using darknets that use protocols such as Freenet, TOR and I2P. How to hide amounts, history and addresses?
This idea was first proposed by Gregory Maxwell in 2013 on the popular BitcoinTalk forum. Since then, many modifications of this method have been proposed and developed. Each of them improved certain payment properties. Let's talk about how CoinJoin works in its pure form, and then look at some of its most interesting modifications.
They create one transaction for three inputs, one from each user, three outputs, one for each online store. In addition, three more exits are created for change. Next, all outputs are randomly mixed together. Each user double-checks the received transaction and signs the corresponding entry. If successful, the transaction is considered correct, propagated to the network and received confirmation.
Above is a graph where each transaction has one or two outputs, and below the transactions already have three outputs. The lower graph is more confusing and more difficult to analyze. When CoinJoin is put into practice in a Bitcoin wallet, a large group of users is formed. Then transactions can have dozens of inputs and outputs (sometimes more). Depicted on a plane, the graph of such transactions will turn out to be very confusing. A coin that has gone through a chain of such transactions has thousands of possible origins. It is difficult to find the real one among all the options.
The user pre-blinds the data before transmitting it to the operator. When the operator signs this data, he does not see the actual content. The signed data is returned to the user, after which he removes the blinding and everything looks like a regular electronic signature.
How does the interaction between the user and the operator occur when forming an overall transaction? Each user prepares in advance an input where his coins are spent, an address for receiving change, and a blinded address for sending a payment, after which he combines this data into one sequence and transmits it to the operator.
The operator verifies the input and payment amount, signs the output address and returns the signature to the user. In this case, the operator does not see the address to which the user wants to send the payment, since he is blinded. Next, the user removes the blinding from the output address, anonymously reconnects to the operator and transfers the signed output address to him. The operator, in turn, verifies that he actually signed this address with his key and that he already has the corresponding input, but he cannot know which input corresponds to which output. Once all users have completed such actions, they are anonymously reconnected to the operator again and provide signatures that confirm ownership of the coins at the input of the overall transaction. The completed transaction can be distributed to the network for confirmation.
In this case, neither users nor the operator itself can de-anonymize coins at output addresses. And under normal conditions, generating a transaction takes no more than one minute. User interaction should be carried out through anonymous data networks, which can be TOR, I2P or Bitmessage.
Among the users there may be unscrupulous participants whose goal is to disrupt the process of creating a common transaction by any means. There is a whole list of possible user behavior scenarios, including fraudulent ones. A number of protection mechanisms have been developed to counter unfavorable scenarios that allow honest users to be guaranteed to form the final transaction. Protection mechanisms use timeouts, tracking unspent outputs, etc. You can learn more about all scenarios and protection mechanisms separately. Now let's look at the next modification of CoinJoin, which is called CoinShuffle.
Directional encryption is used here, where a pair of keys (public and private) is used. The message is encrypted using the public key, and only the owner of the private key can decrypt it. The DiceMix protocol is used for communication between participants, and opposition to violators is also provided.
Imagine a small group of users: cunning Alice, wise Bob, bearded Charlie and orange Dave. Each of them has one unspent coin on the Bitcoin blockchain at addresses A, B, C and D respectively. Everyone wants to spend a coin and hide the history of its origin. For this purpose, each group member learns the address to which coin A, B, C, or D should be sent, respectively, but does not disclose this address to the other members.
Next, everyone generates a new pair of keys for directed encryption, after which the group members exchange public keys for encryption among themselves, with the new public key signed by the private key that corresponds to the address with the unspent coin. All messages from participants during subsequent interactions will be signed in the same way. This was the first stage.
Participants mix and form a queue. Alice will be first because she is cunning, Bob will be second because he is wise, etc. Now Alice takes A' and encrypts towards Dave, using Dave's public key accordingly. Alice encrypts the resulting ciphertext again, and directed at Charlie. This ciphertext is encrypted again, but this time directed at Bob. Alice sends the encryption result to Bob. Bob decrypts the received message with his private key. Then it takes B' and encrypts it towards Dave, then towards Charlie and adds it to the list. He randomly shuffles this list and gives it to Charlie. Charlie, in turn, decrypts the list elements with his private key, adds C', encrypted towards Dave, to the list, and shuffles all the list elements randomly. The list is passed to Dave, who decrypts it, receives the open data of addresses for sending coins, adds address D', mixes it randomly, and based on these addresses, known transaction inputs and amounts, forms a general transaction.
Dave distributes the transaction template to the rest of the group. Next, everyone carefully checks whether the transaction output contains the address they need and whether the amount matches. If all is well, the participant signs the transaction, confirming ownership of their entry coins. Participants exchange signatures and if the transaction receives all the necessary signatures, it can be distributed to the network for confirmation.
If one of the participants begins to deviate from the main interaction scenario, then the rest can jointly analyze the history of interaction and remove the offenders from the group in order to repeat everything without them. This is an important feature.
Note that ready-made implementations of CoinShuffle already exist. And in practice, they work effectively even on groups of several dozen users. Currently, integration of this protocol into some Bitcoin wallets, including mobile ones, is expected.
This became possible thanks to the use of zero-knowledge proof - this is cryptographic proof of knowledge of a certain secret, but without disclosing the latter. To prove that the sum of the outputs does not exceed the sum of the inputs, Petersen Commitment is used, which is based on transformations in a group of points on an elliptic curve. In order to combat the uncontrolled emission of coins, this scheme necessarily uses proof of the use of valid amounts at the output of the transaction. To check that non-negative amounts have been used that do not exceed the order of the base point, so-called Range Proofs are applied.
And everything would be fine, but creating these same Range Proofs is very expensive in terms of computing resources. In addition, they have a very large volume. Theoretically, it is possible to integrate Confidential Transactions into the Bitcoin protocol, but no one is in a hurry to do this due to their large volume. However, there are already working accounting systems where Confidential Transactions are successfully used.
The use of ring signatures in this way was first proposed in the CryptoNote protocol, on which several cryptocurrencies operate. Ring Confidential Transactions use CT. They allow you to create transactions with multiple inputs and outputs, where the origin of each input cannot be clearly traced, the transfer amounts are hidden, and interaction with other users is not required to create a transaction.
The sender uses its key pair and your public key to calculate a new one-time public key, which will already be specified in the transaction as an address. It turns out that the address to which the coins are sent can only be known by the sender and the recipient. To an outside observer, the relationship between the user ID and the transaction output address cannot be established.
The Bitshares team was one of the first to implement CT in conjunction with Stealth Addresses, not only for the base currency, but also for tokens that can be issued on the platform. The Monero cryptocurrency supports ring signatures and Stealth Addresses to ensure a high level of privacy. In January 2017, the team implemented RingCT, and with the September 2017 update, the use of RingCT became strictly mandatory. It is also worth noting the Mimblewimble protocol, which uses a modified version of CT, which is currently under active development, but we will talk about it later.
There is a project called ZeroLink, which is a framework for creating confidential wallets based on the Chaumian CoinJoin methodology. Remarkably, it can work on Bitcoin without requiring any changes to the protocol itself.
Yes, you can use them now; no protocol update is required. But for a wider adaptation of this functionality, it is necessary to strictly specify the order of calculations and data formats so that all wallets can work with each other and, accordingly, add this function to the wallets themselves. Peter Todd has already created a separate BIP to introduce this specification, but it is still under review.
— Is it effective to use CoinJoin in its pure form for Bitcoins?
No, in its pure form it is ineffective, because such transactions can be easily analyzed based on the transfer amounts. Alternatively, you can use the same amounts for all participants, while avoiding trusted mixers who can either steal coins or violate confidentiality.
— Is it possible to apply the techniques discussed above to ensure privacy in digital currencies such as Ethereum, Ripple and Stellar?
No, that's not true. Ethereum, Ripple and Stellar use a completely different transaction model and a different way of accounting for coins to which such privacy techniques cannot be applied. You can, of course, try to artificially integrate Stealth Addresses or Confidential Transactions, but this will be extremely ineffective in terms of currency performance. The reason is that Bitcoin accounts for unspent outputs (i.e. UTXOs), and these currencies use balances and accounts.
One of the lectures in the online course on Blockchain “Confidentiality in Cryptocurrencies” is devoted to this topic.
Let's define the terms
The topic of privacy and how to ensure it is quite extensive. The best place to start studying it is by understanding the basic definitions.The concept of privacy includes two main components: untraceability and anonymity. Untraceability, or non-traceability, implies the inability to attribute a group of actions to a certain user on the network. Anonymity, or anonymity, is associated with the inability to reliably identify a user on this network.
Privacy in Bitcoin by default
Bitcoin has the anonymity property, but it is very easy to lose in practice. The untraceability property is also not fully achieved. We can analyze the transaction graph and make a conclusion about their involvement in certain anonymous wallets. If at least one address has been compromised in the context of anonymity, then it is possible to establish the involvement of certain individuals. The simplest implementation of a Bitcoin wallet can only provide a minimal level of privacy.Let's say that for each incoming payment or change, the user creates a new address. In this case, the auditor analyzing the transaction graph can no longer reliably connect specific facts that relate to the actions of users and the distribution of currency between them. But even in this situation, privacy is not as secure as it might seem.
Typically, in the Bitcoin network, your privacy depends on your counterparties. The one who accepts the payment knows the history of the coins, and the one who sends the coins knows where he is transferring them. Moreover, there is a number of metadata that may be available to outsiders: the nature of the transaction, wallet data, user location data, etc.
What transaction data should be hidden first of all in order to ensure the maximum level of confidentiality? This includes information about the origin of coins, which relates to the property of interchangeability, or fungibility. It is very important for any money and valuables. At the Bitcoin protocol level, this property is ensured (all coins are the same and the rules for their processing are common to all), but in practice fungibility is easy to break. For example, some merchants may analyze the origin history of accepted coins and reject payments if they have doubts about it.
The next thing that makes sense to hide is the amount of transfers, sender and recipient addresses in the transaction body. It is also important to hide the network addresses of users, which is usually achieved using darknets that use protocols such as Freenet, TOR and I2P. How to hide amounts, history and addresses?
CoinJoin
The simplest method for obfuscating a transaction graph is called CoinJoin. That's where we'll start. Its essence is to create a joint transaction, as a result of which the origin of the coins sent becomes ambiguous. A group of users is formed who create a common transaction, within which several payments are made simultaneously. That is, users do not need to create separate transactions.This idea was first proposed by Gregory Maxwell in 2013 on the popular BitcoinTalk forum. Since then, many modifications of this method have been proposed and developed. Each of them improved certain payment properties. Let's talk about how CoinJoin works in its pure form, and then look at some of its most interesting modifications.
How CoinJoin works
Imagine a group of three users, in which everyone wants to purchase a product in an online store (each of them has their own store).
They create one transaction for three inputs, one from each user, three outputs, one for each online store. In addition, three more exits are created for change. Next, all outputs are randomly mixed together. Each user double-checks the received transaction and signs the corresponding entry. If successful, the transaction is considered correct, propagated to the network and received confirmation.
Differences between CoinJoin and a regular transaction
The diagram below shows the difference between regular transaction graphs and CoinJoin transactions.
Above is a graph where each transaction has one or two outputs, and below the transactions already have three outputs. The lower graph is more confusing and more difficult to analyze. When CoinJoin is put into practice in a Bitcoin wallet, a large group of users is formed. Then transactions can have dozens of inputs and outputs (sometimes more). Depicted on a plane, the graph of such transactions will turn out to be very confusing. A coin that has gone through a chain of such transactions has thousands of possible origins. It is difficult to find the real one among all the options.
Chaumian CoinJoin
We come to a modification of CoinJoin called Chaumian CoinJoin. And it was suggested by the same Gregory Maxwell. Here a centralized operator is involved and a blind signature is used. The operator is needed to perform the mixing of inputs and outputs, and then compose the final transaction. But the operator cannot steal coins or violate the confidentiality of mixing thanks to a blind signature.The user pre-blinds the data before transmitting it to the operator. When the operator signs this data, he does not see the actual content. The signed data is returned to the user, after which he removes the blinding and everything looks like a regular electronic signature.
How does the interaction between the user and the operator occur when forming an overall transaction? Each user prepares in advance an input where his coins are spent, an address for receiving change, and a blinded address for sending a payment, after which he combines this data into one sequence and transmits it to the operator.
The operator verifies the input and payment amount, signs the output address and returns the signature to the user. In this case, the operator does not see the address to which the user wants to send the payment, since he is blinded. Next, the user removes the blinding from the output address, anonymously reconnects to the operator and transfers the signed output address to him. The operator, in turn, verifies that he actually signed this address with his key and that he already has the corresponding input, but he cannot know which input corresponds to which output. Once all users have completed such actions, they are anonymously reconnected to the operator again and provide signatures that confirm ownership of the coins at the input of the overall transaction. The completed transaction can be distributed to the network for confirmation.
In this case, neither users nor the operator itself can de-anonymize coins at output addresses. And under normal conditions, generating a transaction takes no more than one minute. User interaction should be carried out through anonymous data networks, which can be TOR, I2P or Bitmessage.
Among the users there may be unscrupulous participants whose goal is to disrupt the process of creating a common transaction by any means. There is a whole list of possible user behavior scenarios, including fraudulent ones. A number of protection mechanisms have been developed to counter unfavorable scenarios that allow honest users to be guaranteed to form the final transaction. Protection mechanisms use timeouts, tracking unspent outputs, etc. You can learn more about all scenarios and protection mechanisms separately. Now let's look at the next modification of CoinJoin, which is called CoinShuffle.
CoinShuffle
A modification of CoinShuffle was proposed in 2014. There is no longer a central operator here and this has become an advantage. Users independently form a common transaction by communicating with each other. However, they still cannot violate the confidentiality of mixing output addresses. Another advantage of this technique is that users do not have to use additional networks to anonymize traffic, since all the necessary properties will be achieved using one P2P protocol for interaction between participants.Directional encryption is used here, where a pair of keys (public and private) is used. The message is encrypted using the public key, and only the owner of the private key can decrypt it. The DiceMix protocol is used for communication between participants, and opposition to violators is also provided.
Visually about CoinShuffle
Let's figure out how CoinShuffle works.
Imagine a small group of users: cunning Alice, wise Bob, bearded Charlie and orange Dave. Each of them has one unspent coin on the Bitcoin blockchain at addresses A, B, C and D respectively. Everyone wants to spend a coin and hide the history of its origin. For this purpose, each group member learns the address to which coin A, B, C, or D should be sent, respectively, but does not disclose this address to the other members.
Next, everyone generates a new pair of keys for directed encryption, after which the group members exchange public keys for encryption among themselves, with the new public key signed by the private key that corresponds to the address with the unspent coin. All messages from participants during subsequent interactions will be signed in the same way. This was the first stage.
Participants mix and form a queue. Alice will be first because she is cunning, Bob will be second because he is wise, etc. Now Alice takes A' and encrypts towards Dave, using Dave's public key accordingly. Alice encrypts the resulting ciphertext again, and directed at Charlie. This ciphertext is encrypted again, but this time directed at Bob. Alice sends the encryption result to Bob. Bob decrypts the received message with his private key. Then it takes B' and encrypts it towards Dave, then towards Charlie and adds it to the list. He randomly shuffles this list and gives it to Charlie. Charlie, in turn, decrypts the list elements with his private key, adds C', encrypted towards Dave, to the list, and shuffles all the list elements randomly. The list is passed to Dave, who decrypts it, receives the open data of addresses for sending coins, adds address D', mixes it randomly, and based on these addresses, known transaction inputs and amounts, forms a general transaction.
Dave distributes the transaction template to the rest of the group. Next, everyone carefully checks whether the transaction output contains the address they need and whether the amount matches. If all is well, the participant signs the transaction, confirming ownership of their entry coins. Participants exchange signatures and if the transaction receives all the necessary signatures, it can be distributed to the network for confirmation.
If one of the participants begins to deviate from the main interaction scenario, then the rest can jointly analyze the history of interaction and remove the offenders from the group in order to repeat everything without them. This is an important feature.
Note that ready-made implementations of CoinShuffle already exist. And in practice, they work effectively even on groups of several dozen users. Currently, integration of this protocol into some Bitcoin wallets, including mobile ones, is expected.
What are the disadvantages of the CoinJoin method?
Obviously, there is great complexity in off-chain interaction to form a transaction, i.e. it is necessary to organize the formation of groups and the interaction of participants with each other. But a more significant drawback is that CoinJoin in its pure form does not hide the amount of transfers. As a result, it is vulnerable to CoinJoin Sudoku analysis, which is based on matching the amounts of transaction outputs and allows you to unravel the history of the origin of coins after obfuscating it many times. Yes, you can combat this problem, for example, by using only certain amounts for transaction output values (0.1 BTC, 1 BTC, 10 BTC, etc.), but this creates additional difficulties and restrictions. Therefore, let's consider a completely different method that solves the problem of open transfer amounts - Confidential Transactions.Confidential Transactions
The peculiarity of the Confidential Transactions (CT) method is that it completely hides the actual amounts of transaction inputs and outputs from third parties. Anyone can check that the sum of all outputs does not exceed the sum of all inputs, which is already enough to validate this transaction.This became possible thanks to the use of zero-knowledge proof - this is cryptographic proof of knowledge of a certain secret, but without disclosing the latter. To prove that the sum of the outputs does not exceed the sum of the inputs, Petersen Commitment is used, which is based on transformations in a group of points on an elliptic curve. In order to combat the uncontrolled emission of coins, this scheme necessarily uses proof of the use of valid amounts at the output of the transaction. To check that non-negative amounts have been used that do not exceed the order of the base point, so-called Range Proofs are applied.
And everything would be fine, but creating these same Range Proofs is very expensive in terms of computing resources. In addition, they have a very large volume. Theoretically, it is possible to integrate Confidential Transactions into the Bitcoin protocol, but no one is in a hurry to do this due to their large volume. However, there are already working accounting systems where Confidential Transactions are successfully used.
Ring Confidential Transactions
The next technique is called Ring Confidential Transactions. To confuse the history of the origin of the coins, ring signatures are used here. The sender in the input of his transaction refers not to one specific output (UTXO), but to several at once. Next, using a ring signature, he proves that he owns the coins of one of several outputs, but which one is not disclosed. It follows from this that it is impossible to unambiguously trace the history of the origin of coins.The use of ring signatures in this way was first proposed in the CryptoNote protocol, on which several cryptocurrencies operate. Ring Confidential Transactions use CT. They allow you to create transactions with multiple inputs and outputs, where the origin of each input cannot be clearly traced, the transfer amounts are hidden, and interaction with other users is not required to create a transaction.
Stealth Addresses
This approach is a technique for secretly calculating the addresses to which coins will be sent. This idea was first described by Peter Todd. Public keys are used as user identifiers: if you want to accept payments, you need to disclose your public key.The sender uses its key pair and your public key to calculate a new one-time public key, which will already be specified in the transaction as an address. It turns out that the address to which the coins are sent can only be known by the sender and the recipient. To an outside observer, the relationship between the user ID and the transaction output address cannot be established.
Application in practice
Where are these methods used in practice?
The Bitshares team was one of the first to implement CT in conjunction with Stealth Addresses, not only for the base currency, but also for tokens that can be issued on the platform. The Monero cryptocurrency supports ring signatures and Stealth Addresses to ensure a high level of privacy. In January 2017, the team implemented RingCT, and with the September 2017 update, the use of RingCT became strictly mandatory. It is also worth noting the Mimblewimble protocol, which uses a modified version of CT, which is currently under active development, but we will talk about it later.
There is a project called ZeroLink, which is a framework for creating confidential wallets based on the Chaumian CoinJoin methodology. Remarkably, it can work on Bitcoin without requiring any changes to the protocol itself.
Let's move on to frequently asked questions
— Is it possible to use Stealth Addresses in Bitcoin?Yes, you can use them now; no protocol update is required. But for a wider adaptation of this functionality, it is necessary to strictly specify the order of calculations and data formats so that all wallets can work with each other and, accordingly, add this function to the wallets themselves. Peter Todd has already created a separate BIP to introduce this specification, but it is still under review.
— Is it effective to use CoinJoin in its pure form for Bitcoins?
No, in its pure form it is ineffective, because such transactions can be easily analyzed based on the transfer amounts. Alternatively, you can use the same amounts for all participants, while avoiding trusted mixers who can either steal coins or violate confidentiality.
— Is it possible to apply the techniques discussed above to ensure privacy in digital currencies such as Ethereum, Ripple and Stellar?
No, that's not true. Ethereum, Ripple and Stellar use a completely different transaction model and a different way of accounting for coins to which such privacy techniques cannot be applied. You can, of course, try to artificially integrate Stealth Addresses or Confidential Transactions, but this will be extremely ineffective in terms of currency performance. The reason is that Bitcoin accounts for unspent outputs (i.e. UTXOs), and these currencies use balances and accounts.
One of the lectures in the online course on Blockchain “Confidentiality in Cryptocurrencies” is devoted to this topic.
