Hey @cassie, the news that Chainalysis was running malicious Monero nodes in an attempt to deanonymize users of popular Monero wallets prompted me to dig into what malicious nodes on the network can achieve and this lead to the following questions:
RPC Calls
Let’s take as example the following RPC calls performed by a user to fetch the balance of their address or transfer tokens:
It is critical to understand that in order to maintain the privacy of your account, that use of these RPCs is kept within secure trust boundaries – do not use an RPC server you do not control, and ensure that your connection to this RPC is secure and encrypted.
Is this because the node receives the parameters as plaintext, meaning the node will know the address of the user, the intended recipient of a transfer and the amount? Does this mean that in order to preserve their privacy, every user has to run a node that they send transactions to? I’m assuming not, because WebAuthn keys are to be supported by the network which means an ordinary user visiting a website should be able to perform transactions securely. How would this work?
Personal Nodes
Let’s say a user is running a node exclusively to send transactions/query their balance. What information would another node or collection of nodes on the network be able to learn about the user by observing the behavior of the user’s node?
RPC calls are intended for the circumstance you’re doing large programmatic volumes of interactions with a node and wish to have clear input/output with no embedding of the node client itself. The scenario differs greatly from ethereum and bitcoin RPCs where someone else may be running an RPC server for others’ behalves.
If you’re wanting to evaluate certain calls programmatically and don’t wish to run a separate node and perform RPC to do so, you would want to embed the node client libraries themselves as essentially a light node.
The 2.0 qclient is essentially an example of a light node client, and the embedded JS SDK is as well.
Light in this context means explicitly does not store long term state (unless needed for an application, but that’s up to the implementer using the SDK) locally, mostly just a replacement to the wallet/public RPC paradigm people are accustomed to.
They should learn nothing. A user’s node does not need to declare prover ranges (if light client), and if a full node does not need to declare their own data within the prover range. The combination of both the onion routing and RPM mixnet essentially defeats side channel analysis (of traffic, to be clear).
Monero suffers a problem of relying on k-anonymity for a pure digital cash equivalent with barely any users. The surface area of attack is simply too great and reliant on centralized entities (e.g. wallets, public RPCs, ease of spam-crushing attacks on k-anonymity).
Thanks for the detailed replies @cassie! I’m adding one bit that I learned since asking the question:
If using a refund address in a transfer to get the amount back in case the transfer is rejected, the refund address must be a new one if you don’t want to reveal your sending address to the recipient (source).
To be clear, if you don’t put a different refund address in than the one you are sending from, the refund address (which is visible to the receiver) will default to your sending address. The receiver still is not aware that they are the same.
This means that while they still don’t know that refund address was your original sending address, that particular address you sent from is now not unknown.