Mutt
Professional
- Messages
- 1,459
- Reaction score
- 1,105
- Points
- 113
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 the specific mechanisms for achieving confidentiality, as well as how they are applied in practice. The topic will be interesting for those who directly work with cryptocurrencies, as well as for those who like protocols that increase the level of user privacy.
Let's define the terms
The topic of privacy (privacy) and how it is ensured is quite extensive. The best place to start is by understanding the basic definitions.
Privacy includes two main components: untraceability and anonymity. Untraceability, or non-traceability, implies the impossibility of assigning a group of actions to some user on the network. Anonymity, or anonymity, refers to the inability to reliably identify a user on this network.
Default Bitcoin privacy
Bitcoin has anonymity property, but it is very easy to lose it in practice. The property of untraceability is not fully achieved either. We can analyze the graph of transactions 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 Bitcoin wallet implementation is capable of providing only a minimal level of privacy.
Let's say the user creates a new address for each incoming payment or change. The auditor analyzing the transaction graph, in this case, can no longer reliably connect 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 reliable as it might seem.
Usually, on the Bitcoin network, your privacy depends on your 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 transfers them to. Moreover, there is a number of metadata that may be available to outsiders: the nature of the transaction, data about the wallet, data on the location of the user, etc.
What kind of transaction data should be hidden first of all in order to ensure the maximum level of confidentiality? This includes data on the origin of coins that relate to fungibility. It is very important for any money and value. At the level of the Bitcoin protocol, this property is provided (all coins are the same and the rules for their processing are common for all), but in practice, fungibility is easy to violate. For example, some merchants may analyze the origin history of accepted coins and reject payments if they have any doubts about it.
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 using darknets, which use protocols such as Freenet, TOR and I2P. How to hide amounts, history and addresses?
CoinJoin
The simplest method for obfuscating the transaction graph is called CoinJoin. We will start with it. Its essence is to create a joint transaction, as a result of which the origin of the sent coins 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 properties of payments. Let's talk about how CoinJoin works in its purest form, and then let's look at some of its most interesting modifications.
How CoinJoin works
Imagine a group of three users in which everyone wants to purchase an item in an online store (with their own store for each of them).
They create one transaction for three entrances, one from each user, three exits, one for each online store. In addition, three more exits are created for delivery. Further, all outputs are randomly mixed with each other. Each user double-checks the received transaction and signs the corresponding entry. If successful, the transaction is considered correct, propagates to the network and receives 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 transactions already have three outputs. The bottom graph is more confusing and more difficult to analyze. When CoinJoin is put into practice in 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 a real one among all the options.
Chaumian CoinJoin
We come to a modification of CoinJoin called Chaumian CoinJoin. And the same Gregory Maxwell offered it. It uses a centralized operator and uses a blind signature. The operator is needed to mix inputs and outputs, and then compose the final transaction. However, the operator cannot steal coins or violate the confidentiality of the mixing due to the blind signature.
The user pre-blinds the data before transferring 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 take place when forming a general transaction? Each user prepares in advance the entrance where the coins belonging to him are spent, the address for receiving change, as well as the blinded address for sending the payment, after which he combines this data into one sequence and transfers it to the operator.
The operator verifies the input and the payment amount, signs the output address and returns the signature to the user. At the same time, the operator does not see the address to which the user wants to send the payment, since he is blinded. Further, the user removes the glare from the exit address, anonymously reconnects to the operator and sends him the signed exit address. The operator, in turn, checks that he really signed this address with his key and that he already has the corresponding input, but at the same time he cannot know which input corresponds to which output. After all users have performed such actions, they reconnect anonymously to the operator again 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 users nor the operator himself can de-anonymize coins at the output addresses. And the formation of a transaction under normal conditions takes no more than one minute. User interaction should be carried out through anonymous data transmission networks, which can be TOR, I2P or Bitmessage.
Users may include dishonest participants whose purpose is to disrupt the process of creating a general transaction by any means. There is a whole list of possible scenarios for user behavior, including fraudulent ones. A variety of safeguards have been developed to counter adverse 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 the scenarios and protection mechanisms separately. Now let's look at the next modification of CoinJoin, which is called CoinShuffle.
CoinShuffle
The CoinShuffle modification was proposed in 2014. There is no longer a central operator and this has become an advantage. Users independently form a general transaction by communicating with each other. However, they still cannot violate the confidentiality of the shuffling of 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 interaction between participants.
Directional encryption is used here, where a key pair (public and private) is involved. 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, and 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. They each have 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. To this end, each member of the group learns the address to which the coin A, B, C or D should be sent, respectively, but does not disclose this address to the rest of the members.
Further, each generates a new key pair for directional encryption, after which the group members exchange the keys open for encryption with each other, and the new public key is signed with a private key that corresponds to the address with the unspent coin. In the same way, all messages of participants will be signed during subsequent interaction. This was the first stage.
Participants mix and form a queue. Alice will be the first because she is cunning, Bob the second because he is wise, and so on. Now Alice takes A 'and encrypts it towards Dave using Dave's public key accordingly. The resulting ciphertext Alice encrypts 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 he takes B 'and encrypts it towards Dave, then Charlie and adds it to the list. He randomly shuffles this list and passes it on to Charlie. Charlie, in turn, decrypts the elements of the list with his private key, adds C ', encrypted towards Dave, to the list and shuffles all the elements of the list at random. The list is passed to Dave, who decrypts it,
Dave distributes the transaction template to the rest of the group. Further, everyone carefully checks whether the transaction outputs contain the address he needs and whether the amount is the same. If all is well, then the participant signs the transaction, confirming the ownership of the coins of his entry. The 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 scenario of interaction, then the rest can jointly analyze the history of interaction and remove the violators from the group in order to repeat everything without them. This is an important feature.
Note that there are already ready-made CoinShuffle implementations. And in practice, they work effectively even for groups of several dozen users. It is currently expected to integrate this protocol into some bitcoin wallets, including mobile ones.
What are the disadvantages of the CoinJoin method?
Obviously, there is a great complexity of off-chain interaction for the formation of a transaction, that is, 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 the comparison of amounts at the outputs of transactions and allows you to unravel the history of the origin of coins after it is repeatedly obfuscated. Yes, you can fight this problem, for example, use only certain amounts for the output values of transactions (0.1 BTC, 1 BTC, 10 BTC, etc.), but this creates additional difficulties and restrictions. Therefore, 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 at the inputs and outputs of the transaction from third parties. Everyone 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 a cryptographic proof of knowledge of a secret, but without disclosing the latter. To prove that the sum of the outputs does not exceed the sum of the inputs, the 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 in this scheme, proof of the use of acceptable amounts at the output of the transaction is necessarily applied. To check that non-negative sums 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 the creation of these very Range Proofs is very expensive in terms of computing resources. Moreover, they have a very large volume. In theory, 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 have been used successfully.
Ring confidential transactions
The next technique is called Ring Confidential Transactions. Ring signatures are used here to obfuscate the origin story of the coins. The sender in the input of his transaction refers not to one specific output (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 outputs, but does not disclose which one. It follows from this that it is impossible to unambiguously trace the history of the origin of the 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 inputs and outputs, where it is impossible to unambiguously trace the origin of each input, the transfer amounts are hidden, and interaction with other users is not required to create a transaction.
Stealth addresses
This approach is a method of covertly 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, then you need to publish your public key.
The sender uses his 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 only the sender and the recipient can know the address to which the coins are sent. For an outside observer, the connection between the user ID and the address at the output of the transaction cannot be established.
Application in practice
Where are these methods applied 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. 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 has become strictly mandatory. It is 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 such a project ZeroLink, which is a framework for creating confidential wallets based on the Chaumian CoinJoin technique. It is noteworthy that it can work in Bitcoin without requiring any changes in 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 consideration.
- Is it effective to use CoinJoin in its pure form for bitcoins?
No, in its pure form it is ineffective, because such transactions lend themselves to a simple analysis of the amount of transfers. Alternatively, you can use the same amount for all participants, while avoiding trusted mixers that can either steal coins or violate privacy.
- Can the above techniques be applied to ensure privacy in digital currencies such as Ethereum, Ripple and Stellar?
No, it’s not like that. Ethereum, Ripple, and Stellar use a completely different transaction model and a different way of accounting for coins, which cannot be applied to such privacy practices. 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 in Bitcoin, accounting is based on unspent outputs (i.e. UTXOs), and these currencies use balances and accounts.
Let's define the terms
The topic of privacy (privacy) and how it is ensured is quite extensive. The best place to start is by understanding the basic definitions.
Privacy includes two main components: untraceability and anonymity. Untraceability, or non-traceability, implies the impossibility of assigning a group of actions to some user on the network. Anonymity, or anonymity, refers to the inability to reliably identify a user on this network.
Default Bitcoin privacy
Bitcoin has anonymity property, but it is very easy to lose it in practice. The property of untraceability is not fully achieved either. We can analyze the graph of transactions 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 Bitcoin wallet implementation is capable of providing only a minimal level of privacy.
Let's say the user creates a new address for each incoming payment or change. The auditor analyzing the transaction graph, in this case, can no longer reliably connect 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 reliable as it might seem.
Usually, on the Bitcoin network, your privacy depends on your 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 transfers them to. Moreover, there is a number of metadata that may be available to outsiders: the nature of the transaction, data about the wallet, data on the location of the user, etc.
What kind of transaction data should be hidden first of all in order to ensure the maximum level of confidentiality? This includes data on the origin of coins that relate to fungibility. It is very important for any money and value. At the level of the Bitcoin protocol, this property is provided (all coins are the same and the rules for their processing are common for all), but in practice, fungibility is easy to violate. For example, some merchants may analyze the origin history of accepted coins and reject payments if they have any doubts about it.
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 using darknets, which use protocols such as Freenet, TOR and I2P. How to hide amounts, history and addresses?
CoinJoin
The simplest method for obfuscating the transaction graph is called CoinJoin. We will start with it. Its essence is to create a joint transaction, as a result of which the origin of the sent coins 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 properties of payments. Let's talk about how CoinJoin works in its purest form, and then let's look at some of its most interesting modifications.
How CoinJoin works
Imagine a group of three users in which everyone wants to purchase an item in an online store (with their own store for each of them).
They create one transaction for three entrances, one from each user, three exits, one for each online store. In addition, three more exits are created for delivery. Further, all outputs are randomly mixed with each other. Each user double-checks the received transaction and signs the corresponding entry. If successful, the transaction is considered correct, propagates to the network and receives 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 transactions already have three outputs. The bottom graph is more confusing and more difficult to analyze. When CoinJoin is put into practice in 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 a real one among all the options.
Chaumian CoinJoin
We come to a modification of CoinJoin called Chaumian CoinJoin. And the same Gregory Maxwell offered it. It uses a centralized operator and uses a blind signature. The operator is needed to mix inputs and outputs, and then compose the final transaction. However, the operator cannot steal coins or violate the confidentiality of the mixing due to the blind signature.
The user pre-blinds the data before transferring 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 take place when forming a general transaction? Each user prepares in advance the entrance where the coins belonging to him are spent, the address for receiving change, as well as the blinded address for sending the payment, after which he combines this data into one sequence and transfers it to the operator.
The operator verifies the input and the payment amount, signs the output address and returns the signature to the user. At the same time, the operator does not see the address to which the user wants to send the payment, since he is blinded. Further, the user removes the glare from the exit address, anonymously reconnects to the operator and sends him the signed exit address. The operator, in turn, checks that he really signed this address with his key and that he already has the corresponding input, but at the same time he cannot know which input corresponds to which output. After all users have performed such actions, they reconnect anonymously to the operator again 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 users nor the operator himself can de-anonymize coins at the output addresses. And the formation of a transaction under normal conditions takes no more than one minute. User interaction should be carried out through anonymous data transmission networks, which can be TOR, I2P or Bitmessage.
Users may include dishonest participants whose purpose is to disrupt the process of creating a general transaction by any means. There is a whole list of possible scenarios for user behavior, including fraudulent ones. A variety of safeguards have been developed to counter adverse 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 the scenarios and protection mechanisms separately. Now let's look at the next modification of CoinJoin, which is called CoinShuffle.
CoinShuffle
The CoinShuffle modification was proposed in 2014. There is no longer a central operator and this has become an advantage. Users independently form a general transaction by communicating with each other. However, they still cannot violate the confidentiality of the shuffling of 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 interaction between participants.
Directional encryption is used here, where a key pair (public and private) is involved. 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, and 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. They each have 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. To this end, each member of the group learns the address to which the coin A, B, C or D should be sent, respectively, but does not disclose this address to the rest of the members.
Further, each generates a new key pair for directional encryption, after which the group members exchange the keys open for encryption with each other, and the new public key is signed with a private key that corresponds to the address with the unspent coin. In the same way, all messages of participants will be signed during subsequent interaction. This was the first stage.
Participants mix and form a queue. Alice will be the first because she is cunning, Bob the second because he is wise, and so on. Now Alice takes A 'and encrypts it towards Dave using Dave's public key accordingly. The resulting ciphertext Alice encrypts 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 he takes B 'and encrypts it towards Dave, then Charlie and adds it to the list. He randomly shuffles this list and passes it on to Charlie. Charlie, in turn, decrypts the elements of the list with his private key, adds C ', encrypted towards Dave, to the list and shuffles all the elements of the list at random. The list is passed to Dave, who decrypts it,
Dave distributes the transaction template to the rest of the group. Further, everyone carefully checks whether the transaction outputs contain the address he needs and whether the amount is the same. If all is well, then the participant signs the transaction, confirming the ownership of the coins of his entry. The 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 scenario of interaction, then the rest can jointly analyze the history of interaction and remove the violators from the group in order to repeat everything without them. This is an important feature.
Note that there are already ready-made CoinShuffle implementations. And in practice, they work effectively even for groups of several dozen users. It is currently expected to integrate this protocol into some bitcoin wallets, including mobile ones.
What are the disadvantages of the CoinJoin method?
Obviously, there is a great complexity of off-chain interaction for the formation of a transaction, that is, 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 the comparison of amounts at the outputs of transactions and allows you to unravel the history of the origin of coins after it is repeatedly obfuscated. Yes, you can fight this problem, for example, use only certain amounts for the output values of transactions (0.1 BTC, 1 BTC, 10 BTC, etc.), but this creates additional difficulties and restrictions. Therefore, 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 at the inputs and outputs of the transaction from third parties. Everyone 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 a cryptographic proof of knowledge of a secret, but without disclosing the latter. To prove that the sum of the outputs does not exceed the sum of the inputs, the 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 in this scheme, proof of the use of acceptable amounts at the output of the transaction is necessarily applied. To check that non-negative sums 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 the creation of these very Range Proofs is very expensive in terms of computing resources. Moreover, they have a very large volume. In theory, 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 have been used successfully.
Ring confidential transactions
The next technique is called Ring Confidential Transactions. Ring signatures are used here to obfuscate the origin story of the coins. The sender in the input of his transaction refers not to one specific output (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 outputs, but does not disclose which one. It follows from this that it is impossible to unambiguously trace the history of the origin of the 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 inputs and outputs, where it is impossible to unambiguously trace the origin of each input, the transfer amounts are hidden, and interaction with other users is not required to create a transaction.
Stealth addresses
This approach is a method of covertly 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, then you need to publish your public key.
The sender uses his 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 only the sender and the recipient can know the address to which the coins are sent. For an outside observer, the connection between the user ID and the address at the output of the transaction cannot be established.
Application in practice
Where are these methods applied 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. 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 has become strictly mandatory. It is 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 such a project ZeroLink, which is a framework for creating confidential wallets based on the Chaumian CoinJoin technique. It is noteworthy that it can work in Bitcoin without requiring any changes in 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 consideration.
- Is it effective to use CoinJoin in its pure form for bitcoins?
No, in its pure form it is ineffective, because such transactions lend themselves to a simple analysis of the amount of transfers. Alternatively, you can use the same amount for all participants, while avoiding trusted mixers that can either steal coins or violate privacy.
- Can the above techniques be applied to ensure privacy in digital currencies such as Ethereum, Ripple and Stellar?
No, it’s not like that. Ethereum, Ripple, and Stellar use a completely different transaction model and a different way of accounting for coins, which cannot be applied to such privacy practices. 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 in Bitcoin, accounting is based on unspent outputs (i.e. UTXOs), and these currencies use balances and accounts.
