Recently, a conversation unfolded regarding the privacy challenges in Electron Cash (EC), focusing on its address subscription model. This design exposes wallet address data to servers, allowing them to see connections between addresses and coins without advanced techniques. Here’s a summary of the key discussion points:
Privacy Issues with EC
EC’s reliance on centralized servers means user wallets send their subscribed addresses to servers, exposing their data. Even SSL encryption doesn’t prevent servers from seeing these connections, making privacy a significant concern for CashFusion users. Running your own server improves security but doesn’t solve the fundamental design issue of server visibility.
Proposed Solutions
Neutrino Mode: Combining Neutrino + Bloom Filters
Neutrino offers a privacy-enhancing method by only fetching necessary transaction data without revealing all wallet addresses. However, it’s bandwidth-intensive and might not be suitable for everyone as BCH scales a hybrid approach using Neutrino alongside Bloom Filters was suggested to reduce bandwidth usage while maintaining privacy.
Plugins and Permissionless Testing:
Instead of overhauling EC’s architecture, a modular approach was proposed to disable address subscriptions via plugins. This would allow users to test alternatives like Neutrino or other privacy-focused methods.
The Identified Challenges
Neutrino is resource-intensive and not ideal for all users. CashFusion users depend on the privacy of the fusion pool, meaning other user’s leaked data can impact everyone. Implementing changes without disrupting EC’s existing functionality requires careful planning and gradual testing.
Summarized Telegram Group Consensus
The group generally agreed that privacy improvements are essential but acknowledged the technical challenges involved. While Neutrino is considered the ultimate privacy tool, it’s not a one-size-fits-all solution. A combination of Neutrino, Bloom Filters, and other methods could offer a balanced approach. There was agreement on the importance of incremental progress, using EC’s plugin system to experiment without disrupting the wallet’s core functionality. The conversation also highlighted the need to spread awareness about these privacy concerns, as many users might not realize the extent of data exposure.
Anyone can see what data their wallet sent to the server at that moment by typing: print(network.subscribed_addresses) in the EC console. Problem is right now everyone is sharing data. We need that data leak at the minimum possible.
OPReturn: because BCHD has a focus on privacy. Its privacy feature can help remove the need to trust in servers while connecting to them. This affects the effectiveness of CashFusion.
It haven’t been implemented into EC and users currently have to trust servers. But I’m hoping that this is the year that it happens and “someone” starts tackling that issue.
While I’m not yet sure what the best solution would look like, I think a combination of Neutrino (which BCHD is the only node that supports it) and bloom filters could help solve the privacy concerns.
There have been some previous discussions about this in this chat if you’re interested in reading more. You can also refer to the link above to read more about what makes BCHD different from other nodes. And please feel free to message me if you have any questions. To be clear, I didn’t mean the CashFusion protocol has a flaw. It’s related to how wallets exchange info with servers.
Tom: Neutrino is tricky as it requires downloading full blocks. Which is not really an issue today, but if we seriously start to grow the personal wallet using neutrino will very likely not be for most people.
Some research on the topic of privacy that is very interesting to do is here:
In short it is 2 points:
add SSL certificates to normal p2p network traffic.
have a way to self sign in a much more secure way. (This is an issue with fulcrum servers today).
OPReturn: Yeah. I agree that there are cons with it and it’s not for “ALL” use-cases for sure that’s why I mentioned we’ll need other methods in combination with it but this one is the ultimate way of privacy. Also you don’t have to download the whole blockchain, only blocks that contain your transactions and you certainly don’t have to download that whole block either. Only parts of it. There have been precaution for that. CTOR helps with that.
Regarding the BCR topic you mentioned, I think that’s a something we should think of for sure but it’s not related to the issue I’m mentioning. My concern is not the connection safety and breaking the SSL encryption and sniffing. It’s that servers themselves see everything. You can just run a server today and see the connection between addresses and coins of people without any special effort or need for advanced sniffing techniques or help from the government or anything. It’s just there by design.
You run a server → you see the coins the wallet sent into fusion And you see the coins the wallet got after the fusion round. No special skill or resources is needed.
This is from a totally fresh wallet with no transaction. (Those are addresses) This is the data the wallet sends to the server when it connects to it BY DESIGN. Everytime a new address goes into use, it sends it along with others as well. Anyone can see what data their wallet sent to the server at that moment by typing:
print(network.subscribed_addresses)
in the EC console.
JF: That is by design in Electron Cash. It’s an address subscription model.
Tom: Yes, agreed that that’s a pretty bad design problem undermining the entire point.
Would love to see fusion in a wallet that’s not using the centralized server idea.
ABLA: I think possible by using smart contract, Similar to tornado cash
OPReturn : Yes that’s exactly what I’m trying to say. I believe many are not aware of this.
I’m implying that my concern is not the connection getting sniffed or anything like that. (Although that that can be of concern too) But the design itself has no concern for privacy. That’s actually the best way to do it if you don’t care about sharing your coin data around. But I think any cashfusion user has that concern. Getting cash fusion into more wallet help but it does not solve this issue. Just like running your own server will not solve this issue. They help for sure but they do not fix this. The reason for that is because cashfusion is a collaborative protocol. Your privacy and safety relies on privacy and safety of others.
If everyone get their info leaked, and lets say an entity knows everything about their coins, there’s really no point in fusing with them. So We might not need to change the EC arch. I totally understand where you’re coming from. I’m not saying this is going to be trivial or easy or simple or anything. If it was, we would have had it by now.
But I think efforts to eliminate this issue need to start somewhere. And the issue needs more acknowledgment. Also for the record, I don’t think we should start gutting EC and changing things aggressively in it at all. I think a different approach is needed. A permissionless one would be best.
JF: fusion is in stack wallet , same issue is there.
If you want more wallets to be neutrino style, maybe start by building one
OPReturn : But why not try to fix this at all? EC is the dominant wallet. All the big coins are on EC. Almost every innovation happens in EC and I think it’s the most used wallet ever. This issue affects a lot of users. I don’t think implementing another wallet that no one uses is going to help with anything.
JF: Well , if you want to work on a “neutrino mode” or something for EC, go for it
OPReturn: I don’t think a neutrino mode alone is going to be all helpful. But again just to be clear, I’m not advocating for starting to break everything apart. Most of this is uncharted waters. I don’t think we know everything. The only way to know is by actually trying. That’s why I mentioned the permission-less part.
EC is pretty awesome for this. It provides us with tools to add things to it without needing to mess and break everything up in mainline.
Just like the WalletConnect feature.
Once we have everything well tested and established they work perfectly fine, we can think about getting things into mainline.
JF : what is your proposal?
OPReturn: Neutrino is the ultimate privacy but it has it’s cons. And not everyone might need it. Not sure yet. The con with it lies in the bandwidth.
But anyways, I think a combination of that and bloom filters and maybe something else might be the way to go.
OPReturn : I see which part you mean is vague. That’s because as I said this is uncharted waters and I don’t really know what that final product will look like exactly. It’s vague to me too. This is the typical R&D stuff. But I think the good starting point looks like something like this: Implementing a way for a plugin to disable that subscription part which causes the user data getting leaked and start giving the users different options to replace it. ie: Neutrino. - Neutrino + bloom filters etc. We can go from there and iterate on things to improve and reach a final product. Then we start thinking about getting it into mainline.
Ti121x: At present, with EC if you want privacy you have to trust the server and use an SSL connection. There are two issues: should you trust a particular server and are you talking to the server you think you are?
If you are interested in privacy you have to run a server yourself or have someone you trust run a server. If you run a server yourself you can get better security with the self signed certificates than using the public certificate hierarchy based on numerous “trusted” roots. That assumes you use the SSH style of server verification and can actually verify that the server you want is using a particular key.
With SSH, the first time you connect to the server you are told a public key and given the option to accept it. (I suspect many people skip the check if they have some other reason to believe they haven ‘t been hacked already.). Then if the key changes or the connection has been hacked they will get an error. This isn’t particularly convenient and required some networking/crypto skills, but these should be available to anyone running a server.
However, for EC users who just want to run a client, they will have to trust somebody else’s server. Let’s say they just run one of the recommended servers from the EC github.
It turns out that most of these do not have any way for EC to verify that it is connecting to the correct node, since most servers just use self signed certificates and there is no GUI interface to show what the situation is, and I don’t think there are any errors given by EC if the certs changed so network hacks will be possible.
I think the use of recommended servers should be cryptographically sound, which means that the built in github list could have certs or that the public SSL infrastructure would need to be supported. Neither approach is simple to implement correctly and requires ongoing maintenance efforts.
Of course there is also an argument that securing the recommended servers placed the EC devs at risk if they make a bad recommendation.
OPReturn: That only helps so much. Because You are fusing your coins with others and you rely on them. So if others leak their data, you’re also at risk. Although SSL sniffing can make this much worse, you don’t really need SSL sniffing for that to happen.
