I wanted to share my experience with using the -net=onion option in firo-qt and discuss a potential improvement that could enhance our privacy while using the wallet.
When I tried running firo-qt with the -net=onion option, I noticed that my connections didn’t seem to change. It made me think about how we could improve the privacy for users who want to leverage the Tor network for better privacy.
One idea I had was to implement hardcoded onion addresses for seed nodes within the Firo wallet. By doing this, when users select the -net=onion option, the wallet would automatically connect to these predefined onion seed nodes. This would not only simplify the process for users but also ensure that they are connecting to reliable and privacy-focused nodes.
This is only necessary if you run a full node and you want to propagate locally-originating transactions over Tor. This allows you to mask your IP (as transaction originator) against P2P network surveillence, on top of Firo’s built-in Dandelion++.
There is many privacy implications of using cloudflare. I can list many but for the shear fact that they have a history of blocking Tor/VPN users is concerning. You can’t even visit most sites nowadays without getting cloudflared’d. While I get the security that they provide with their DDoS protection and how its appealing to many. There are many sus or rather I would say abuses with Cloudflare.
Issues #1443 and #1441 on GitHub are a good summery of why adding onions for the existing seed nodes would be a great implementation.
Hello, first of all sorry for the delay in approving the post as I think the system flagged a new user for posting such a big post so we had to approve the post to let it through.
I think you raise a good point that there should be onion seednodes but we always saw seednodes as a way to sync the blockchain (which doesn’t leak sensitive data beyond the IP that downloads the blockchain). You bring up a good point about Cloudflare and we’ll see what alternatives there are on this. Do you have any suggestions?
Let me dedicate some time into this and get back to you.
Again, welcome to the forum and thank you for your suggestion.
I think this would be easy to implement onions for the seed nodes even if it was like 4 nodes would be a nice addition. On another note Campfire users aren’t getting the benefits or rather the protection that running a full nodes provides.
It may make more sense to onionize Campfire servers (or in addition to this), if they are based on ElectrumX they can be configured to run as Tor hidden services, which means they can be accessed via .onion addresses not requiring DNS.
Regarding pull request 1442 one would have to see if “any” of these seednode domains are using Dynamic DNS/Dynamic IP addresses.
When I do dig tokyo.firo.org I get 139.180.194.191 which I don’t see in this pull request which makes me think its possibly dynamic?
I’d wanted to say that Bisq had 4 nodes hardcoded and it hasn’t worked the best for them. With Tor being attacked by DDoS every now and then it became unusable for me and other people i know. It should be something to consider as to not re-discover the hot water, we should take a look at Bisq experiences and try to build a good solution that will cover use cases such as these.
As mentioned here tx-proxy and here monerod has a --tx-proxy option so that only publishing transactions can go through a proxy.
I only see the option for all connections to go through Tor on firo-qt (which is preferable for me).
I would suggest something like this unless I’m getting things confused or mixed up.
You bring up a good point about Cloudflare and we’ll see what alternatives there are on this. Do you have any suggestions?
Well, the PR that @PrivacyExtremist mentioned looks like it would be good to look at. As far As DNS that was the key point was to also have onions as an option. If we are talking the DNS of the seednodes well, you can rotate DNS records for a single IP address without needing to register with multiple DNS providers.
Some DDNS providers allow you to update DNS records dynamically. You can set up multiple subdomains pointing to the same IP address and then rotate them as needed. Services like No-IP or DynDNS can help with this.
I just really don’t like Cloudflare’s control over the web.
You could still use Cloudflare with a DDNS provider I believe while also mapping the nodes to an IP instead of domain. Rather adding a fallback mechanism that attempts to connect to a direct IP address first and then falls back to a DDNS hostname if the IP connection fails. This would ensure reliability and accessibility.
However this doesn’t fully address the Cloudflare issue but rather eliminating DNS calls to Cloudflare I would think right?