Is there interest in a Red Team analysis of CashFusion?

CashFusion’s transaction privacy protocol is one of BCH’s crown jewels. What if it could be made even more robust through a Red Team analysis? Red Team analysis is a concept from the fields of cybersecurity and military planning that involves investigating the strength of security measures by simulating attacks on the defenses and then developing improvements to those security measures.

My question to you all is whether there is interest in performing this kind of analysis on CashFusion. It’s almost a certainty that CipherTrace, Chainalysis, and their ilk are Red Teaming CashFusion for real right now – and they’re playing for keeps. We need to know what the weaknesses are, if any, and address them.

Putting fresh eyes onto privacy protocols has been fruitful for other coins. Last year, a serious flaw in Wasabi Wallet’s BTC CoinJoin protocol was discovered by external researchers. Just a few weeks ago an external engineer discovered a significant privacy bug in Monero’s reference wallet.

Didn’t the June 2020 audit by Kudelski Security already do this?

No, not really. The audit primarily dealt with ensuring that the protocol could not steal coins from CashFusion participants and ensuring secure communication channels while the CashFusion transactions were being negotiated by the central CashFusion server and participants. They did analyze the privacy guarantees, but not very thoroughly.

One of the audit’s recommendations was:

Furthermore, a higher level of assurance could be achieved by providing a thorough security analysis of the protocol under realistic adversarial conditions. Specifically, we would recommend to add: A threat model…[and] more rigorous analysis of the amount linkage risks (the combinatorial arguments is a good start.)…The exercise of working out such documents may in turn reveal overlooked design aspects or unforeseen optimizations.

The audit goes on to state:

The authors of CashFusion argue that, for a reasonable amount of players and components, the sheer number of combinations makes finding these combinations impossible. However, we notice that this is only true for a pure brute-forcing approach. The problem in question reminds vaguely of the problem of bin packing where heuristic algorithms much more efficient than brute-forcing are known. It is not obvious how a direct reduction between the two problems can be found, but we recommend nevertheless checking carefully this security argument against state-of-the-art works found in combinatorics literature.

I have confirmed with Electron Cash lead maintainer Jonald Fyookball that they have not yet made progress on this recommendation from the audit. If I were to do a Red Team analysis, I would follow responsible disclosure procedures by informing Electron Cash developers of all significant findings before they are revealed publicly, if at all.

Who am I?

Long-turn lurker, recently a participant. I’m an empirical microeconomist. That means that I use real-world data, rather than mathematical theory, to investigate economic questions at the level of consumers, businesses, and industries. While reading about bitcoin’s skyrocketing price in 2017, I set out to see if I could prove to myself the hypothesis that bitcoin was just a classic tulip-mania-style asset bubble. I tried to keep an open mind, and the more I read the more I recognized that bitcoin does actually present a solution to many real economic problems. So I rejected my initial hypothesis and have since kept abreast of developments in cryptocurrency.

To demonstrate that I’ve been around for years I am able to cryptographically sign a statement with the private key of a 2017-vintage BCH address and submit it to a trusted community member for verification. (Not publicly though since that address has been KYC’ed to hell and back.)

As a start, I’ve built a simple public-facing web app at that displays basic stats about all CashFusions to date. The intention was to mimic stats dot cash (which seems to be in maintenance mode at the moment) but with some additional interactivity.

(Post has been cross-posted to reddit: )


More details since the OP was getting long:

I’m imagining a multi-phase Flipstarter as a trust- and reputation-building measure. (Repeated games allow more scope for cooperation than one-shot games.) The phases might look something like:

Phase 1:

Part A: Build out fusionstats dot redteam dot cash to allow, among other additional features, visualizations of individual transactions via network graphs.

Part B: Write an R package for RPC queries to the BCH node daemon. There is one for BTC but not one for BCH. I hacked together something to extract the CashFusion transactions for fusionstats dot redteam dot cash , but having a fully-featured package would facilitate blockchain analysis and it would “put BCH on the map” for R programmers. R is ranked 14 among all programming languages in the TIOBE Programming Community index (it’s above Go, Ruby, and Swift) and it is the #1 domain-specific statistical programming language.

Phase 2:

Part A: Identify theoretically unsafe user behavior. Certain spending patterns, such as combining most or all fusioned outputs, could lead to de-anonymization.

Part B: Determine if this unsafe behavior exists “in the wild” on the blockchain in the actual CashFusions made to date.

Part C: Maybe there could be an Electron Cash plugin that would warn you if you are about to make a transaction that would expose you to certain de-anoymizing risks.

Phase 3:

Examine weaknesses in the protocol and wallet behavior that may leak information, excluding the combinatorics. Just from observing CashFusion in my own wallet, I’ve identified 4 avenues to investigate. Revealing them is probably not too sensitive, but to be safe I’ll keep the list close to my chest for now.

Phase 4:

Examine weaknesses in the combinatorial argument itself. Heavy math wizardry here.


I did a review/explainer on CashFusion a while ago.

For the purposes of privacy, the protocol assumes that the server is trustworthy.

The logic behind that is that while a rogue server cannot steal money, it would be able to break anonymity by using a maximum sybil attack.

Since the server decides which groups participants are placed in, it can just place each participant into their own group where all the others are fake participants that it controls. This allows the server to break anonymity.

This gives this table:

With changes to the protocol, it may be possible to mitigate this. I think breaking up matchmaking (group selection) and protocol management would help. Once a group is formed, they would go to another server to actually run the protocol.

1 Like

Thank you. Yes, I had read your analysis. Unless something changes, I’m imagining that the scope of the Red Team project – or at least my contribution to such a project – will be limited to privacy vulnerabilities that stem from data available on the blockchain only, however. Figuring out a way to make the protocol safer when the server(s) are untrustworthy would be great, but my skillset in statistical analysis would not be particularly useful for that goal. Also, certain ways to strengthen privacy may come from encouraging safer user behavior, which may not require any changes to the protocol itself.

I have gotten a decent amount of encouraging feedback from my Reddit post and elsewhere, so I plan to write up a draft of a Flipstarter for a Phase 1 and get feedback from various channels soon.

I now have a draft of the Flipstarter proposal.

Requested budget: 18 BCH

I would very much appreciate any comments you could give within the next 48 hours, especially on the budget request amount:


The Flipstarter is now live:

1 Like