It seems to me that you underestimate the ability of MITM attacks on your traffic. When cloudfare MITMs your traffic, they can do anything with it. I mean, really, really anything. Generally speaking, nothing prevents them from MITMing your "second layer of encryption as well as the first one" and sending a fake public key for your ECC to the user. They can also remove the ECC encryption entirely. Theoretically, after that they can even send a fake bitcoin address to the user and seize the BTC the user was going to mix (although in reality, I doubt they are ready to act so openly yet).
With your current design, the easiest technological solution for cloudfare is to access your on-premises server via tor after they receive a HTTPS request to their "ddos-protection" MITM server. Nobody will notice anything. The clearnet user will just see a bitcoin address and send BTC there, and you will see in your server logs that someone accessed your server "via TOR". Nobody will notice anything before the user suddenly gets arrested a few years later.
Thank you for bringing this up. We intentionally omitted to include very important details in the initial explanation but considering your concerns this needs to be addressed now.
Firstly we want to confirm everything you said is completely true.
We are fully aware this is not a perfect solution, and we are not underestimating the power Cloudflare has with such a MITM attack. Using the onion link is the most private way to use the service, but we tried to make the service as safe as possible to use on the clearnet version as well and we believe our implementation is as close to perfection as you can get in this situation.
With the current design, if Cloudflare doesn't implement any
active MITM attacks, all old data which went through Cloudflare will not have been compromised if they weren't running the attack.
With the clearnet frontend, it is basically impossible to 100% guarantee the frontend code is not tampered with, only if we would provide a script with which a user can verify the checksum of the build. Obviously, this cannot happen automatically since Cloudflare can just remove or edit the code snippet.
Another possible solution is to release a CLI or GUI open source app, with the backend's public key directly patched into the code. This way, we would be sure the data cannot be tampered with, since it is downloaded from a safe source. We also thought about having a safe server without Cloudflare where the frontend would just fetch the public key from, but this can be DDoSed, and Cloudflare could again patch the frontend code replacing the server address.
In the short term, we believe this was the best way to get the clearnet service running with as much privacy as possible, and after the service gains more popularity we will definitely switch back to our proprietary solution. We were ddos attacked with a lot of firepower so in order to contain that we would need to spend a lot on severs for load balancing and that just doesen't make much economic sense, that money is better spent elsewhere at the moment especially considering that we just started and we have a system in place to detect if Cloudflare interferes in any way.
We implemented an automatic verification script that runs "honeypots" which access the clearnet version from different IPs and various request fingerprints and automatically check everything is ok. If one server sees the frontend is tampered with it will alert us and automatically shut down the clearnet version. This way, the only possible way for such an attack to happen would be for Cloudflare to target a specific IP. Since users know for a fact their IP is logged by Cloudflare by default this shouldn't be an issue.
This should answer most questions you could have in this regard but if there is anything else don't hesitate to ask.