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.
Tbh, I don’t trust PG team members. I don’t know any of them personally, so the initial link to web of trust breaks. PG recommendations are easier to trust since you can always go to the primary source and research them yourself. Here the user wouldn’t have any way to verify the endorsement, and there is no primary source to verify. Also the IRL identity or the past projects of most team members is not known, which further damages trust. Like I’d trust Seth since I know of him, likewise Artemis and Project Segfault, but that’s because I know the IRL identity or their past work to trust them.
I primarily use wallet recommendations or use my own node when needed. I can see feather wallet list being more useful than web of trust.
Maybe something like wallet lists with another list of operators who run multiple other community services? Their credentials can be easily verified by going to their last works and interacting with the users of their other services.
I agree. And the post I replied to was soliciting opinion on if a web of trust model where PG team recommends nodes for listing would be a good idea. So my reply advocates against it by citing my concerns.
This was the original proposal:
We were discussing what can be the criteria, not the fact that criteria allows you to not explicitly trust PG.
Ultimately, finance is tricky and cryptocurrency tricker still. PG should be careful venturing into this. Loss of credibility due to subjective recommendations should not be affecting objective recommendations.
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.
Oh my bad. So it would be hard for me to trust individual PG team members recommending random nodes, but if they:
Recommend nodes run by entities that have great reputation
Or PG itself runs a node
I would be fine.
It was just my attempt at trying to make web of trust more robust, since maybe a single PG team member can recommend a malicious node, but the entire PG team wouldn’t run a malicious node. Similarly other projects that run community services can be sorta trusted to not run malicious nodes. It’s mostly hedging against individual PG members turning rogue.
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.
