Cryptocurrency privacy
In this article, we tried to answer the question of what confidentiality 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 interesting to those who work directly with cryptocurrencies, as well as lovers of protocols that increase the level of user privacy.
The topic of privacy (privacy) and how to ensure it is quite voluminous. It’s best to start learning from an understanding of basic definitions.
The concept of privacy includes two main components: untraceability and anonymity. Untraceability, or non-traceability, implies the impossibility of assigning a group of actions to a certain user on the network. Anonymity, or anonymity, is associated with the inability to reliably identify the user on this network.
Anonymity is present in Bitcoin, but it is very easy to lose in practice. The untraceability property is 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 involvement in certain individuals. The simplest implementation of a bitcoin wallet is able to provide only a minimal level of confidentiality.
Suppose a user creates a new address for each incoming payment or deposit. The auditor analyzing the transaction graph in this case can no longer reliably relate specific facts that relate to the actions of users and the distribution of currency between them. But even in such a situation, confidentiality is not as secure as it may seem.
Usually in the Bitcoin network, your privacy depends on counterparties. The one who accepts the payment knows the history of the origin of the coins, and the one who sends the coins knows where he sends them. Moreover, there are a number of metadata that may be available to outsiders: the nature of the transaction, the data on the wallet, the data on the user's location, etc.
What kind of transaction data should I hide first to ensure maximum privacy? This includes data on the origin of coins, which relate to the property of interchangeability, or fungibility. It is very important for any money and values. At the level of the Bitcoin protocol, this property is provided (all coins are the same and the rules for their processing are common to all), but in practice it’s easy to break fungibility. For example, some merchants can analyze the history of the origin of accepted coins and reject payments if it causes them doubts.
The next thing that makes sense to hide is the sum of transfers, sender and recipient addresses in the body of the transaction. It is also important to hide the network addresses of users, which is usually achieved by using darknets, where protocols such as Freenet, TOR and I2P are used. How to hide amounts, history and addresses?
The easiest method to confuse a transaction graph is called CoinJoin. We will begin with it. Its essence consists in creating a joint transaction, as a result of which the origin of the coins being sent becomes ambiguous. A group is formed of users who create a common transaction, within which several payments are made simultaneously. That is, users do not need to create separate transactions.
For the first time such an idea was 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 properties of payments. Let's talk about how CoinJoin works in its pure form, and then consider some of the most interesting of its modifications.
Imagine a group of three users, in which everyone wants to purchase goods in the online store (with each store having its own).
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. Further, all exits are randomly intermixed. Each user rechecks the received transaction and signs the corresponding input. In case of success, the transaction is considered correct, is distributed to the network and receives confirmation.
The diagram below shows the difference between the graphs of ordinary transactions and CoinJoin transactions.
Above is the graph, where each transaction has one or two exits, and from the bottom, transactions already have three exits. The lower graph is more complicated and more difficult to analyze. When CoinJoin is put into practice in the bitcoin wallet, a large group of users is formed. Then transactions can have dozens of inputs and outputs (sometimes more). Pictured 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.
We come to a modification of CoinJoin, which is called Chaumian CoinJoin. And he offered her the same Gregory Maxwell. Here a centralized operator is activated and a blind signature is used. The operator is needed to perform the mixing of inputs and outputs, and then draw up the final transaction. But the operator cannot steal coins or violate confidentiality of mixing due to blind signatures.
The user previously blinds the data before they are transmitted to the operator. When the operator signs this data, he does not see the actual content. 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 during the formation of a general transaction? Each user prepares in advance the input where the coins belonging to him, the address for receiving the change, as well as the blinded address for sending the payment are spent, and then combines this data into one sequence and transmits it to the operator.
The operator checks 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 a payment, because he is blinded. Further, the user removes blinding from the output address, anonymously reconnects to the operator and sends him the signed output address. The operator in turn checks that he really signed this address with his key and he already has the corresponding input, but he cannot know which input corresponds to which output. After all users have completed such actions, they again anonymously reconnect to the operator and provide signatures that confirm ownership of the coins at the entrance of the general transaction. The finished transaction can be distributed to the network for confirmation.
In this case, neither the users nor the operator himself can deanonymize the coins on the output addresses. And the formation of a transaction under normal conditions takes no more than one minute. The interaction of users should be carried out through anonymous data networks, which can be used as TOR, I2P or Bitmessage.
There may be unscrupulous members among users whose purpose is to disrupt the process of creating a common transaction by any means. There is a whole list of possible scenarios of user behavior, including fraudulent. A number of security mechanisms have been developed to counter adverse scenarios that allow honest users to form a final transaction. Protection mechanisms use timeouts, tracking of unspent exits, etc. You can learn more about all the scenarios and protection mechanisms separately. Now consider the following modification of CoinJoin, which is called CoinShuffle.
Modification of CoinShuffle was proposed in 2014. There is no longer a central operator and this has become an advantage. Users independently form a common transaction, communicating with each other. However, they still can not violate the confidentiality of mixing the output addresses. Another advantage of this technique is that users do not need to use additional networks to anonymize traffic, since all the necessary properties will be achieved using a single P2P protocol for the interaction of participants.
Here, directional encryption is applied, where a pair of keys is used (public and private). The message is encrypted using the public key, and only the owner of the private key can decrypt it. For communication between the participants, the DiceMix protocol is used, opposition to violators is also provided.
Let's see how CoinShuffle works.
Imagine a small group of users: sly Alice, wise Bob, bearded Charlie and orange Dave. Each of them has one unspent coin in the Bitcoin blockchain at addresses A, B, C and D, respectively. Everyone wants to spend a coin and hide the history of its origin. To this end, each member of the group finds out the address to which the coin A, B, C or D should be sent, respectively, but does not disclose this address to the other participants.
Next, each generates a new key pair for directional encryption, after which the group members exchange open encryption keys among themselves, and the new public key is signed with a private key that corresponds to an address with an unspent coin. In the same way all messages of participants will be signed at the subsequent interaction. This was the first stage.
Participants shuffle and form a queue. Alice will be the first because she is sly, Bob is the second because he is wise, and so on. Now Alice takes A 'and encrypts it with Dave, using Dave’s public key, respectively. The resulting ciphertext Alice encrypts again, and directed at Charlie. This ciphertext is encrypted again, but already directed at Bob. Alice transmits the encryption result to Bob. Bob decrypts the received message with his private key. Then he takes B 'and encrypts it directed at Dave, then at Charlie and adds it to the list. This list he mixes randomly and transmits to Charlie. Charlie, in turn, decrypts the list items with his private key, adds C ', encrypted sent to Dave, to the list and shuffles all the elements of the list randomly. The list is transmitted to Dave, who decrypts it,
Dave distributes the transaction stub to the rest of the group. Next, each person carefully checks to see if the transaction has the address he needs and if the amount is the same. If all is well, the participant signs the transaction, confirming possession of the coins of his entry. Participants exchange signatures and if the transaction collects 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 interaction history and remove the violators 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 effectively work even on groups of several dozen users. At the moment, this protocol is expected to be integrated into some bitcoin wallets, including mobile ones.
Obviously, there is a greater complexity of off-chain interaction for the formation of a transaction, i.e. it is necessary to organize the formation of groups and the interaction of participants among themselves. 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 a comparison of the amounts at the outputs of transactions and allows you to unravel the history of the origin of the coins after its multiple entanglement. Yes, this problem can be dealt with, for example, using only certain amounts for the output transaction values (0.1 BTC, 1 BTC, 10 BTC, etc.), but this creates additional difficulties and limitations. Therefore, we consider a completely different method that solves the problem of open transfer amounts, the Confidential Transactions.
A feature of the Confidential Transactions (CT) method is that it completely hides the actual amounts at the inputs and outputs of the transaction from third parties. Everyone can verify that the sum of all outputs does not exceed the sum of all inputs, which is enough to validate this transaction.
This was made possible through the use of zero-knowledge proof - this is a cryptographic proof of the knowledge of some 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 the group of points on the elliptic curve. In order to combat the uncontrolled issue of coins in this scheme, proof of the use of permissible amounts at the exit of a transaction is necessarily used. To verify that non-negative amounts were used that do not exceed the order of the base point, the so-called Range Proofs are used.
And everything would be fine, but the creation of these most Range Proofs is very expensive in terms of computing resources. In addition, they have a very large volume. Theoretically, it is possible to integrate the Confidential Transactions into the Bitcoin protocol, but no one is particularly in a hurry to do this because of their large volume. Nevertheless, there are already working accounting systems where Confidential Transactions are successfully applied.
The following technique is called Ring Confidential Transactions. To confuse the history of the origin of coins, ring signatures are used here. The sender in the input of his transaction refers not to one specific exit (UTXO), but to several at once. Further, with the help of a ring signature, he proves that he owns the coins of one of several exits, but does not disclose which particular. From this it follows that it is impossible to unambiguously track the history of the origin of coins.
The use of ring signatures in this way was first proposed in the CryptoNote protocol, on the basis of which several cryptocurrencies operate. Ring Confidential Transactions use CT. They allow you to create transactions with multiple entries and exits, where it is impossible to unambiguously track the origin of each entry, transfer amounts are hidden, and interaction with other users is not required to create a transaction.
This approach is a method of hidden calculation of 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 announce your public key.
The sender uses his key pair and your public key to calculate the new one-time public key, which will already be specified in the transaction as an address. It turns out that only the sender and recipient can know the address to which the coins are sent. For a third-party observer, the connection between the user ID and the output address of the transaction cannot be established.
Where are these methods used in practice?
The Bitshares team was one of the first to implement CT in conjunction with the Stealth Addresses, not only for the base currency, but also for the tokens that can be issued on the platform. Cryptocurrency Monero supports ring signatures and Stealth Addresses to ensure a high level of privacy. In January 2017, the team implemented RingCT, and with the update in September 2017, the use of RingCT became strictly mandatory. It should be noted and the Mimblewimble protocol, which uses a modified version of CT, which is currently under active development, but we'll talk about it later.
There is such a project ZeroLink, which is a framework for creating confidential wallets based on the method of Chaumian CoinJoin. It is noteworthy that it can work in Bitcoin, without requiring any changes in the protocol itself.
- Is it possible to use Stealth Addresses in Bitcoin?
Yes, you can use them right now, no protocol updates are 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. To introduce this specification, Peter Todd has already created a separate BIP, but it is still under consideration.
- Is CoinJoin purely effective for bitcoins?
No, in its pure form it is ineffective, because such transactions are amenable to simple analysis of the amount of transfers. Alternatively, you can use the same amount for all participants, and you should avoid trusted mixers that can either steal coins or violate confidentiality.
- Can the above techniques be applied to ensure confidentiality in digital currencies such as Ethereum, Ripple and Stellar?
No, it is not. Ethereum, Ripple and Stellar use a completely different transaction model and another way to count coins to which such confidentiality techniques cannot be applied. Of course, you can try to artificially integrate Stealth Addresses or Confidential Transactions, but this will be extremely inefficient in terms of currency performance. The reason is that in Bitcoin, accounting is done on the basis of unspent exits (that is, UTXO), and these currencies use balances and accounts.
One of the Blockchain online cryptocurrency courses is devoted to this topic .
We define the terms
The topic of privacy (privacy) and how to ensure it is quite voluminous. It’s best to start learning from an understanding of basic definitions.
The concept of privacy includes two main components: untraceability and anonymity. Untraceability, or non-traceability, implies the impossibility of assigning a group of actions to a certain user on the network. Anonymity, or anonymity, is associated with the inability to reliably identify the user on this network.
Default Bitcoin Privacy
Anonymity is present in Bitcoin, but it is very easy to lose in practice. The untraceability property is 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 involvement in certain individuals. The simplest implementation of a bitcoin wallet is able to provide only a minimal level of confidentiality.
Suppose a user creates a new address for each incoming payment or deposit. The auditor analyzing the transaction graph in this case can no longer reliably relate specific facts that relate to the actions of users and the distribution of currency between them. But even in such a situation, confidentiality is not as secure as it may seem.
Usually in the Bitcoin network, your privacy depends on counterparties. The one who accepts the payment knows the history of the origin of the coins, and the one who sends the coins knows where he sends them. Moreover, there are a number of metadata that may be available to outsiders: the nature of the transaction, the data on the wallet, the data on the user's location, etc.
What kind of transaction data should I hide first to ensure maximum privacy? This includes data on the origin of coins, which relate to the property of interchangeability, or fungibility. It is very important for any money and values. At the level of the Bitcoin protocol, this property is provided (all coins are the same and the rules for their processing are common to all), but in practice it’s easy to break fungibility. For example, some merchants can analyze the history of the origin of accepted coins and reject payments if it causes them doubts.
The next thing that makes sense to hide is the sum of transfers, sender and recipient addresses in the body of the transaction. It is also important to hide the network addresses of users, which is usually achieved by using darknets, where protocols such as Freenet, TOR and I2P are used. How to hide amounts, history and addresses?
Coinjoin
The easiest method to confuse a transaction graph is called CoinJoin. We will begin with it. Its essence consists in creating a joint transaction, as a result of which the origin of the coins being sent becomes ambiguous. A group is formed of users who create a common transaction, within which several payments are made simultaneously. That is, users do not need to create separate transactions.
For the first time such an idea was 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 properties of payments. Let's talk about how CoinJoin works in its pure form, and then consider some of the most interesting of its modifications.
How CoinJoin Works
Imagine a group of three users, in which everyone wants to purchase goods in the online store (with each store having its own).
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. Further, all exits are randomly intermixed. Each user rechecks the received transaction and signs the corresponding input. In case of success, the transaction is considered correct, is distributed to the network and receives confirmation.
Differences CoinJoin from the usual transaction
The diagram below shows the difference between the graphs of ordinary transactions and CoinJoin transactions.
Above is the graph, where each transaction has one or two exits, and from the bottom, transactions already have three exits. The lower graph is more complicated and more difficult to analyze. When CoinJoin is put into practice in the bitcoin wallet, a large group of users is formed. Then transactions can have dozens of inputs and outputs (sometimes more). Pictured 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, which is called Chaumian CoinJoin. And he offered her the same Gregory Maxwell. Here a centralized operator is activated and a blind signature is used. The operator is needed to perform the mixing of inputs and outputs, and then draw up the final transaction. But the operator cannot steal coins or violate confidentiality of mixing due to blind signatures.
The user previously blinds the data before they are transmitted to the operator. When the operator signs this data, he does not see the actual content. 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 during the formation of a general transaction? Each user prepares in advance the input where the coins belonging to him, the address for receiving the change, as well as the blinded address for sending the payment are spent, and then combines this data into one sequence and transmits it to the operator.
The operator checks 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 a payment, because he is blinded. Further, the user removes blinding from the output address, anonymously reconnects to the operator and sends him the signed output address. The operator in turn checks that he really signed this address with his key and he already has the corresponding input, but he cannot know which input corresponds to which output. After all users have completed such actions, they again anonymously reconnect to the operator and provide signatures that confirm ownership of the coins at the entrance of the general transaction. The finished transaction can be distributed to the network for confirmation.
In this case, neither the users nor the operator himself can deanonymize the coins on the output addresses. And the formation of a transaction under normal conditions takes no more than one minute. The interaction of users should be carried out through anonymous data networks, which can be used as TOR, I2P or Bitmessage.
There may be unscrupulous members among users whose purpose is to disrupt the process of creating a common transaction by any means. There is a whole list of possible scenarios of user behavior, including fraudulent. A number of security mechanisms have been developed to counter adverse scenarios that allow honest users to form a final transaction. Protection mechanisms use timeouts, tracking of unspent exits, etc. You can learn more about all the scenarios and protection mechanisms separately. Now consider the following modification of CoinJoin, which is called CoinShuffle.
Coinshuffle
Modification of CoinShuffle was proposed in 2014. There is no longer a central operator and this has become an advantage. Users independently form a common transaction, communicating with each other. However, they still can not violate the confidentiality of mixing the output addresses. Another advantage of this technique is that users do not need to use additional networks to anonymize traffic, since all the necessary properties will be achieved using a single P2P protocol for the interaction of participants.
Here, directional encryption is applied, where a pair of keys is used (public and private). The message is encrypted using the public key, and only the owner of the private key can decrypt it. For communication between the participants, the DiceMix protocol is used, opposition to violators is also provided.
Visually about CoinShuffle
Let's see how CoinShuffle works.
Imagine a small group of users: sly Alice, wise Bob, bearded Charlie and orange Dave. Each of them has one unspent coin in the Bitcoin blockchain at addresses A, B, C and D, respectively. Everyone wants to spend a coin and hide the history of its origin. To this end, each member of the group finds out the address to which the coin A, B, C or D should be sent, respectively, but does not disclose this address to the other participants.
Next, each generates a new key pair for directional encryption, after which the group members exchange open encryption keys among themselves, and the new public key is signed with a private key that corresponds to an address with an unspent coin. In the same way all messages of participants will be signed at the subsequent interaction. This was the first stage.
Participants shuffle and form a queue. Alice will be the first because she is sly, Bob is the second because he is wise, and so on. Now Alice takes A 'and encrypts it with Dave, using Dave’s public key, respectively. The resulting ciphertext Alice encrypts again, and directed at Charlie. This ciphertext is encrypted again, but already directed at Bob. Alice transmits the encryption result to Bob. Bob decrypts the received message with his private key. Then he takes B 'and encrypts it directed at Dave, then at Charlie and adds it to the list. This list he mixes randomly and transmits to Charlie. Charlie, in turn, decrypts the list items with his private key, adds C ', encrypted sent to Dave, to the list and shuffles all the elements of the list randomly. The list is transmitted to Dave, who decrypts it,
Dave distributes the transaction stub to the rest of the group. Next, each person carefully checks to see if the transaction has the address he needs and if the amount is the same. If all is well, the participant signs the transaction, confirming possession of the coins of his entry. Participants exchange signatures and if the transaction collects 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 interaction history and remove the violators 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 effectively work even on groups of several dozen users. At the moment, this protocol is expected to be integrated into some bitcoin wallets, including mobile ones.
What are the disadvantages of the CoinJoin method?
Obviously, there is a greater complexity of off-chain interaction for the formation of a transaction, i.e. it is necessary to organize the formation of groups and the interaction of participants among themselves. 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 a comparison of the amounts at the outputs of transactions and allows you to unravel the history of the origin of the coins after its multiple entanglement. Yes, this problem can be dealt with, for example, using only certain amounts for the output transaction values (0.1 BTC, 1 BTC, 10 BTC, etc.), but this creates additional difficulties and limitations. Therefore, we consider a completely different method that solves the problem of open transfer amounts, the Confidential Transactions.
Confidential transactions
A feature of the Confidential Transactions (CT) method is that it completely hides the actual amounts at the inputs and outputs of the transaction from third parties. Everyone can verify that the sum of all outputs does not exceed the sum of all inputs, which is enough to validate this transaction.
This was made possible through the use of zero-knowledge proof - this is a cryptographic proof of the knowledge of some 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 the group of points on the elliptic curve. In order to combat the uncontrolled issue of coins in this scheme, proof of the use of permissible amounts at the exit of a transaction is necessarily used. To verify that non-negative amounts were used that do not exceed the order of the base point, the so-called Range Proofs are used.
And everything would be fine, but the creation of these most Range Proofs is very expensive in terms of computing resources. In addition, they have a very large volume. Theoretically, it is possible to integrate the Confidential Transactions into the Bitcoin protocol, but no one is particularly in a hurry to do this because of their large volume. Nevertheless, there are already working accounting systems where Confidential Transactions are successfully applied.
Ring confidential transactions
The following technique is called Ring Confidential Transactions. To confuse the history of the origin of coins, ring signatures are used here. The sender in the input of his transaction refers not to one specific exit (UTXO), but to several at once. Further, with the help of a ring signature, he proves that he owns the coins of one of several exits, but does not disclose which particular. From this it follows that it is impossible to unambiguously track the history of the origin of coins.
The use of ring signatures in this way was first proposed in the CryptoNote protocol, on the basis of which several cryptocurrencies operate. Ring Confidential Transactions use CT. They allow you to create transactions with multiple entries and exits, where it is impossible to unambiguously track the origin of each entry, transfer amounts are hidden, and interaction with other users is not required to create a transaction.
Stealth addresses
This approach is a method of hidden calculation of 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 announce your public key.
The sender uses his key pair and your public key to calculate the new one-time public key, which will already be specified in the transaction as an address. It turns out that only the sender and recipient can know the address to which the coins are sent. For a third-party observer, the connection between the user ID and the output address of the transaction cannot be established.
Practical application
Where are these methods used in practice?
The Bitshares team was one of the first to implement CT in conjunction with the Stealth Addresses, not only for the base currency, but also for the tokens that can be issued on the platform. Cryptocurrency Monero supports ring signatures and Stealth Addresses to ensure a high level of privacy. In January 2017, the team implemented RingCT, and with the update in September 2017, the use of RingCT became strictly mandatory. It should be noted and the Mimblewimble protocol, which uses a modified version of CT, which is currently under active development, but we'll talk about it later.
There is such a project ZeroLink, which is a framework for creating confidential wallets based on the method of Chaumian CoinJoin. It is noteworthy that it can work in Bitcoin, without requiring any changes in the protocol itself.
Let's pass to frequently asked questions.
- Is it possible to use Stealth Addresses in Bitcoin?
Yes, you can use them right now, no protocol updates are 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. To introduce this specification, Peter Todd has already created a separate BIP, but it is still under consideration.
- Is CoinJoin purely effective for bitcoins?
No, in its pure form it is ineffective, because such transactions are amenable to simple analysis of the amount of transfers. Alternatively, you can use the same amount for all participants, and you should avoid trusted mixers that can either steal coins or violate confidentiality.
- Can the above techniques be applied to ensure confidentiality in digital currencies such as Ethereum, Ripple and Stellar?
No, it is not. Ethereum, Ripple and Stellar use a completely different transaction model and another way to count coins to which such confidentiality techniques cannot be applied. Of course, you can try to artificially integrate Stealth Addresses or Confidential Transactions, but this will be extremely inefficient in terms of currency performance. The reason is that in Bitcoin, accounting is done on the basis of unspent exits (that is, UTXO), and these currencies use balances and accounts.
One of the Blockchain online cryptocurrency courses is devoted to this topic .