The CashFusion protocol is a specific implementation of the CoinJoin method for mixing coins. It was developed by Jonald Fyookball and Mark B. Lundeberg. Chain analysis tools can be used to track coins on the blockchain. By making assumptions, these tools determine that certain coins are likely owned by the same person. For example, a transaction with two outputs is likely a payment and one of the two outputs is likely change. Change outputs are owned by the same person as the inputs. Likewise, all the inputs would belong to the same person. This gives evidence about the linkages between coins.
The CoinJoin method is used to make this analysis harder and enhance privacy on the blockchain. It works by creating multi-participant transactions. If each input into the transaction is from a different participant, then the assumption that all the inputs into the transaction are linked is invalidated. Similarly, the transaction outputs will not simply be a payment output and a change output. CoinJoin methods aim to make linking specific outputs to specific inputs as hard as possible.
CashShuffle Transactions
The predecessor to CashFusion is the CashShuffle protocol. CashShuffle uses the CoinShuffle protocol and adds a server to facilitate groups of participants to gather. In the CoinShuffle protocol, each user submits 1 input and 2 outputs. One of the two outputs is the mixed output and the other output is the change output. All the mixed outputs have the same value.
Since the mixed outputs all have the same value, it is not possible for chain analysis to determine which of the mixed outputs matches each of the inputs. The value of the change output associated with each input can be determined by subtracting the value of the mixed outputs from the input. This allows chain analysis to link the change output to the associated input. The linkages for an example transaction are shown in the image. In practice, due to fees, the sum of the outputs will be slightly less than the sum of the inputs.
CashShuffle has the property that privacy is never reduced by participating. Even if all linkages are revealed, the participant is no worse off than before. For example, if the linkages for the participant who owned the 1.1 input are revealed, that shows that they own a specific 1.0 output and their 0.1 change output. Before they participated in the CashShuffle, it was known that a person owned the 1.1 coin and afterwards, it is known that the same person owns two different outputs with a total value of 1.1. The only difference is that the value is split over 2 outputs instead of 1. This is less convenient but it isn’t less private.
The assumption that the mixed output is private may lead the participant to lose privacy due to other actions, but that loss of privacy happens when those actions are taken. If the participant buys something with the mixed coin, that purchase can be linked back to their original coin.
Each CashShuffle transaction increases the total number of outputs by breaking coins into smaller and smaller pieces. This is not sustainable indefinitely and is one of the drivers for the creation of the CashFusion protocol.
CashFusion Transactions
CashFusion transactions differ from CoinShuffle transactions. They support multiple inputs and outputs for each participant. This solves the change problem. It allows participants to “fuse” their inputs together while still maintaining privacy.
The image shows a CashFusion transaction. Each output is the sum of two inputs. The 1.3 output is funded by the 0.5 input and the 0.8 input. This is not the only possible solution, it could have been funded by the 0.9 input and the 0.4 input.
Cryptocurrency values have many decimal places, this makes it less likely that more than one pair of inputs adds to a specific output. For a small number of inputs, there is often only 1 solution and it is relatively easy for chain analysis to find this solution, and determine the linkages. The privacy of CashFusion rests on the assumption that with enough inputs, there will be significantly more than 1 solution. Chain analysis will not be able to determine which of the many solutions is the actual solution. This topic is discussed in section 3.6 of the audit.
In the CashFusion spec, they give an example of a transaction with 10 participants. Each participant provides 10 inputs and sends the funds to 1 output. All inputs can be arbitrary amounts, but they should all be of similar magnitude. Each output is equal to the sum of the inputs from the corresponding participant. This gives a transaction with 100 inputs and 10 outputs. They show that there are so many ways to split 100 inputs into 10 sets of 10 inputs, that it would be infeasible to break the system by brute force. It is not know if there is a faster way to do it. The problem is similar to the subset sum problem which is an np-complete problem. This suggests that it is actually a difficult problem, but is not proof.
In addition, they show that there would be so many possible solutions that, even if an attacker was able to solve the problem efficiently, there would be no way to determine which solution was the actual solution.
This gives two lines of defense for the protocol. An attacker needs an efficient way to find solutions and then needs to determine which of those solutions is the actual solution. In the audit, the CashFusion team indicate that they consider the large number of alternative solutions their first line of defense.
In practice, participants use multiple outputs and can vary the number of inputs they provide. This increases the number of arrangements of the inputs and outputs and yields even more solutions. The number of fake needles, and the size of the haystack, are both increased.
CashFusion allows participants to combine multiple inputs into a fewer number of outputs. This feature of CashFusion is critical to avoid constantly breaking coins into smaller and smaller values. It comes with a tradeoff. Unlike with CashShuffle, a participant’s privacy can be reduced by using CashFusion.
This is an inherent limitation to any such protocol. To combine multiple coins together, a participant must provide more than 1 coin when using the protocol. If the linkages for the CashFusion transaction are leaked, then the inputs provided by the participants are linked.
This property means that CashFusion represents a greater potential risk to privacy than CashShuffle. The use of CashFusion can result in less privacy as opposed to simply not improving privacy.
Cash Fusion Server
The CashFusion protocol makes use of a server. This server handles two distinct roles. It acts as a matchmaker and facilitates groups of participants to gather. Participants are grouped up by tiers so all participants will produce outputs of roughly the same magnitude. Secondly, once it arranges a group, it follows the CashFusion protocol to assist the participants in creating the transaction. It ejects participants who violate the protocol until the protocol is completed with no violators (or the number of participants drops below a safe number).
Extreme Sybil Attack
When designing a cryptographic protocol, it is helpful to determine any inherent limitations with the method being considered. This helps when designing the individual parts of the protocol. A chain is only as strong as its weakest link. If the method has an inherent limitation, then there is no point in designing any part of the protocol to be stronger than that.
With that in mind, an “extreme Sybil attack” is considered in the CashFusion spec. In a Sybil attack, an attacker creates multiple fake identities so that it can pretend to be multiple participants. In the extreme version, all participants, except the victim, are controlled by the server.
If all the other participants in the fusion are controlled by the server, then the server can easily determine which inputs and outputs are owned by the victim. The server simply has to exclude all inputs and outputs owned by the participants it controls. The server learns that all the inputs (and outputs) the victim sends to the server are linked. This is a total loss of privacy for the victim for information submitted for the round of CashFusion.
Honest Server Assumption
The spec acknowledges that a malicious server can launch an extreme Sybil attack in the Design Trade-Offs section. This is also noted in the audit report (section 3.7) using the term rogue server.
Since the server assigns participants to groups, a rogue server can launch an extreme Sybil attack on all participants by arranging the groups appropriately. The server places each victim in their own group with no other non-Sybil participants.
As a consequence, a rogue server represents complete privacy loss for all participants for any inputs and outputs involved in the round. This is an inherent limitation given the responsibilities of the server in the CashFusion protocol.
In the design trade-offs section of the spec, it is acknowledged that the CashFusion protocol has slightly weaker privacy than an ideal mixing protocol. The additional leakage of information is limited to leaks to the server. It is not leaked to other participants. This is not considered a concern, since if the server is a rogue server, then privacy is lost anyway.
I think the extreme Sybil attack assumption is potentially over-pessimistic. A server which is placing every participant into their own group would be easy to detect. Whitelisted servers could be periodically checked. Ironically, the testers would be launching their own mini-Sybil attack. A tester could connects with multiple clients and see if they are all placed in the same group. If they are always alone, then that is suspicious.
The auditors recommend that participants only use “trusted” servers that have been tested. At this time, the CashFusion plugin for the Electron Cash wallet has a single default server. The developers recommend that everyone uses that one server as part of the bootstrapping process until there are sufficient users to support multiple servers.
Residual Privacy Leakage
The CashFusion protocol depends on the assumption that the server is honest. However, even with an honest server some privacy can still be lost. Information about the linkages between the inputs is partitioned between the server and the participants. If they do not collude, then there is no privacy leakage. Each participant has half the information needed to determine some linkages and the server has the other half. If there is information leakage, then it is only leaked to the server. It is not leaked to the participants.
In the blame phase of the protocol each participant sends a collection of encrypted proofs of innocence to random other participants (relayed by the server). If the proof is invalid, the verifier can send the decryption key to the server. This allows the server to decrypt the proof and then ban the violator for future rounds. If the verifier makes a false accusation, they are banned instead. The information in the decrypted proof leaks some information about the corresponding input or output. This leak is to the server and if more than 2 of a participant’s inputs or outputs are leaked, then that gives linkage information to the server.
There are three types of outcomes. If the server is a rogue server, then all privacy is lost. A participant can collude with the server without the server’s consent by sending a false accusation. If a participant involuntarily colludes with an honest server, some of the linkages are leaked. This leakage is only to the server. An honest server should delete that leaked information, but there is no way to determine if involuntary leaks are being logged. If the server is honest and none of the participants collude with the server, then there is no privacy leaks. In all cases, funds are safe. A participant will not sign a transaction that causes a loss of their funds.
Final Thoughts
The CashFusion protocol is heavily dependent on the integrity of the server. A rogue server can launch an extreme Sybil attack on all participants resulting in complete loss of privacy but not funds.
This means that the honesty of the server is assumed for the design of the protocol. There is little point is hardening the protocol against leaks of information to the server. If the server isn’t honest, then privacy is already lost.
I think that this is overly pessimistic. If defenses against the extreme Sybil attack could be developed, then it would be worth hardening the rest of the protocol. The vulnerability to the attack is due to the server also handling matchmaking. I think it would be helpful to split the problem into two parts.
The first part is the matchmaking step. The function of the matchmaking server is to gather participants together in a Sybil resistant way. Once a group is formed, it can then select a server at random to handle for the rest of the protocol.
The transaction formation portion of the CashFusion protocol would be handled by another server. This server would allow a group of participants to connect, as a group. Since the server didn’t form the group, it can’t launch the extreme Sybil attack. This makes hardening the protocol to protect against leaks of information to the server worthwhile. The protocol would have to be hardened to prevent the server ejecting innocent participants. If the blame stage shows the server is at fault, the group, as a whole, could switch to a new server.
Another defense would be to have multiple parallel servers. The reason not to have multiple servers is that it reduces liquidity during the bootstrapping stage. If there were 10 trusted servers, participants could connect to all of them. This gives the same benefit in liquidity as a single server but each server handles around 10% of the fusions. Participants would have to disconnect from servers that account for more than their fair share of the fusions.
The vulnerability to involuntary collusion does not follow automatically. This may be an area where improvement could be achieved. If the vulnerability could be eliminated, then as long as a participant connects to an honest server, there is no risk of information leakage no matter what the other participants do.
A remaining risk is that the server itself is Sybil attacked. If the attacker makes up a large fraction of the participants in the protocol, this makes the protocol less secure. A sufficiently successful attack could push the number of honest participants low enough that some knowledge of the linkages could be inferred, at least on a probabilistic basis. The responsibility for protecting against this type of attack is the matchmaking part of the protocol. This risk is not specific to CashFusion but is inherent in any mixing protocol.