This is a question I've been asking myself for months now. At first it naturally made sense to focus on CashFusion, as it was the successor to CashShuffle. However, I could never accept the fact that CashFusion required TOR, which restricted its use to desktop and native apps. For that reason, I've been pursuing a more collaborative solution, which I'd like to share now.
As you probably already know, CashFusion successfully funded their security audit by the same company that performed the audit for CashShuffle. As much as I would've preferred to wait until AFTER the audit report to critique the protocol, I honestly have no idea what's taking so long; and I'd like to keep things movin'...
A Quick Intro
Both of these privacy protocols aim to provide greater anonymity for Bitcoin Cash users, by collectively mixing (shuffling & fusing) user's coins together in a trustless manner. The purpose is to remove any "taint" that may exist (knowingly or not) and provide you the maximum fungibility of your digital money. Sounds great!
The Pros
FAST! FAST! FAST!
In testing, I've routinely completed shuffles in less than 5 seconds. That's from pool registration on the server to coin delivery in my wallet.Works in ANY mobile or desktop web browser
This is a big adoption advantage, and this convenience factor should not be underestimated. Also, it should not go unnoticed that to currently use CashShuffle, you need to install a "desktop" application.
— see https://app.nitojs.org for a working web demo (in Alpha release)
The Cons
Cannot create larger coins
This is "The Problem", and the reason for developing CashFusion.
My Recommendations
Why not server-less?
This is something that I've been working on since I started with the protocol back in January. I believe that by using pub-sub messaging, specifically OrbitDB, it would be possible for the pool players to manage their rounds 100% peer-to-peer. Without any central servers, there's literally no one to shutdown; very similar to BitTorrent.Dynamic pool size
I'd really like to see the ability to add more than 5 players per round. One thought would be, upon reaching 5 players, to have a delay before the start of the round of say 30 seconds to add additional players (up to some limit).
The Pros
Can covertly take ANY size input(s) and covertly produce ANY size output(s)
There's simply no reason NOT to pop the champaign (sic) for this universally recognized, outstanding achievement that has eluded the entire crypto community for nearly a decade.
The Cons
Cannot run on iOS devices
Mobile-first! That really should've been the first thought when designing this protocol. Background processes are VERY restrictive on iOS; so there's NO way to natively run this protocol on ANY device. Message notifications, using a centralized service, is an option, but that has its own limitations and trade-offs.Kinda sllooowwww...
The minimum time to complete a fusion is approx. 6 minutes. In my 6+ weeks of testing, the "average" time (see #5) was about an hour.Requires TOR for covert server communications
This is only an issue if you desire web browser access to CashFusion.
NOTE: All desktop and native mobile apps support TCP.Too many tiers
There are currently 48 individual tiers to choose from. In comparison, CashShuffle has 8. This creates a problem (see #5).Lower value tiers have very little liquidity
If you're planning to fuse anything under 1 BCH, you're likely going to wait several hours, if not days.
My Recommendations
Add an alternative covert messaging channel
Pub-sub (aka gossip protocol) would not only enable browser-based compatibility, but would likely simplify integration for BCH wallet developers.
NOTE: After testing several gossip networks; imo, none were quite production-ready, but I feel this is worth further investigation and possibly warrants infrastructure investment.Reduce the number of tiers
I don't really understand the maths behind the reasoning for the 48 tiers (Resistor "E series" values), but this needs to be seriously looked in to, for the sake of improving the overall liquidity and usability.
Best Of Both Worlds
So, finally to the jist of this article. Why not enhance the benefits of both protocols while minimizing their weaknesses? I don't have any flow diagrams, so I'll just do my best to explain.
All coins (UTXOs) would start with a CashShuffle round.
NOTE: There's an 80% chance that your shuffle will have change.If your coin is shuffled to a "desirable" size (value), then you keep it (ie. freeze it). If it's shuffled down to an "undesirable" size (value), then you queue it for CashFusion.
NOTE: There's NO way to know what size coin you will receive until after the shuffle round is completed.You can repeat this process over an over, "freezing" the coins you want and "queuing" the coins you don't.
At some point you won't be able to shuffle any more coins; you would then request all of your "queued" coins be fused together into a single large coin (or multiple coins); and (optionally) start the shuffle process all over again.
There's a bit more to it than this, particularly on the CashFusion side, but then the maths gets way over my head, so hopefully you have the basic idea.
A Final Point
By using the above system, it might then make sense for CashFusion to normalize its outputs to match CashShuffle, ie. 0.0001 BCH through 1,000 BCH. The advantage would be that you could have less tiers (perhaps even just one large tier, or dynamically generated tiers), which would more easily mask the outliers.
By the way, in case you missed it up above, and for those that haven't heard already, you can now CashShuffle your coins from ANY mobile or desktop web browser using https://app.nitojs.org.
Happy Shufflin' 😉
Kudos to you for writing this article A great read