For reference, our current guidance on public nodes is as follows:
Using another person’s node will expose some information to them, such as the IP address that you connect to it from, the timestamps that you sync your wallet, and the transactions that you send from your wallet (though no other details about those transactions). Alternatively, you can connect to someone else’s Monero node over Tor or I2P.
Secondly, while Monero people would love it if everyone ran their own independent node to mitigate this problem, I don’t think this is feasible for the average user given that it requires 250GB+ for a full node or 50GB+ for a pruned node, both of which represent a very substantial fraction of the average person’s disk space, and neither of which are reasonable for mobile/web clients. We live in a mobile first world, and assuming someone even has a(n always-on) desktop computer at all is not a given.
Given these two things, I think we should compile a list of recommended remote nodes to use alongside your Monero wallet, similar to how we recommend DNS providers, with pre-defined criteria for trustworthiness and technical features.
I would love it if anyone in the Monero community could provide more insight into this topic.
For reference, these are the nodes that are included by default in the wallet I personally use (Cake Wallet) and that are online as I’m writing this, which we could consider as a potential starter list:
@Lukas a default node in Cake Wallet was recently compromised
See :
This is a bad idea. We should have strict criteria ( a bit like the one for CA) for transparency, safety measures, etc.
Listing nodes before we have those criterias would violate PG’s principles.
I was more suggesting that we could use those nodes as a reference to establish criteria.
However I looked a lot more into this topic since last night and I don’t think that is a good idea anymore, even the configuration on the node they run themselves leaves a bit to be desired, not to mention the issue you brought up.
i think it would be a good idea to list nodes on PG, but i’m not sure what the criteria could be? i guess for DNS and Search it’s based on their privacy policy but it still requires trust.
It’s a little more web-of-trust-y than verifiable by readers, but I don’t really know how else we would handle this, and I think info about who current team members trust is still more helpful than directing people to monero.fail which lists 240+ random nodes.
And web-of-trust isn’t terrible, I don’t think.
Of course, there would still also be technical criteria that would be verifiable by readers to prevent it from being a free-for-all.
I am interested in hearing everyone’s thoughts about this approach though, and alternative ideas if you have any.
I get your general point, but then when you say this I don’t really follow the logic behind these community projects being trustworthy and Privacy Guides not being trustworthy for the very same reasons.
I think we generally agree actually, what I am envisioning is something like this, with operator information listed on the website:
To illustrate the point I was making more clearly though, imagine there’s a hypothetical node operator, and maybe they’re well-known or even well-regarded in the Monero/privacy community, or they have a lot of users.
However, if none of us on the team at Privacy Guides knows who this operator is ourselves, I don’t really see how we can even review them adequately in the first place regardless of their reputation.
Therefore, the criteria—or at least one of the criteria—has to be that it’s operated by someone trusted by the Privacy Guides team.
Right?
The alternative is that we try and discern how trustworthy based on what we see in the community, which is still a subjective decision we have to make that I think leaves more room for error.
I think it’s probably obvious that what certainly cannot happen is listing any node that meets a certain technical criteria, which is why this has to be handled differently.
Secondly just to be clear, when I say something is the opinion of the Privacy Guides team, that means: at least 2 team members agree that there is a consensus among the team and/or community that the opinion is true. (Because that is our change review criteria)
Otherwise, it is just a personal opinion a team member has.
I run a public Monero remote node that is listed in Feather’s remote node repo. The node runs on a rented dedicated server I do not have physical control of.
I assume that part of the criteria is good uptime. node.sethforprivacy.com has 90% uptime in the last month according to xmr.ditatompel.com. Probably the node isn’t actually crashing and coming back alive, but instead it’s getting overloaded by connected wallets since Seth’s node is recommended in a lot of guides. You can contribute to overloading it by making it the only recommendation in Privacy Guides
Of course, Privacy Guides is more than welcome to perform their own due diligence checks for Monero remote nodes instead of just endorsing someone else’s list. You could use the personally-known criterion if you want.
I haven’t seen anyone mention logs policy as a criterion. You may want to get a statement from the operators of candidate remote nodes that they do not log anything related to Monero wallets connecting to nodes through the RPC ports. The default log level of Monero nodes do not log any of that information (but operators can manually change the log level to record that information if they want). So far so good.
A lot of public remote node operators that use a domain name probably use a reverse proxy like NGINX to route wallet RPC connections to the Monero node. By default, the NGINX access log records IP address information. Not good. Monero node operators can disable this logging by setting access_log off in the http context of their NGINX config or by setting a custom logging format: Module ngx_http_log_module
You may want to include onion hidden service nodes in your list for users whose wallet software support connecting to onion addresses. The IP address of users that connect to these nodes are hidden by the Tor network, no exceptions.
Anyway, maybe this is a good opportunity to set and raise a standard for good public remote nodes. As stated, for best privacy, Monero users should run their own node. Or they could connect to a node operated by someone they personally know and trust. Users should keep in mind that a “community-trusted” node will become a targeted node.
I don’t see how it is possible to trust a node you don’t operate yourself, aside from considering probabilities like “it seems unlikely that this would be compromised,” which is not good enough.
The Tor idea is probably better for people not running their own node. But the emphasis should be on running your own node. This is a big investment because even with great internet and 50+ GB of free SSD space it often takes a week to sync.
