preland
commented
1 day ago Another option would be fixing the root problem: most mainstream users don’t want to/can’t download and maintain the entire blockchain in its current state. This issue will only get worse over time, as blockchain size increases et infinitum. This aspect of the blockchain size will also effect option 3, to the extent that i2p would be the only realistic (and let’s face it: moral) option due to bandwidth constraints on “exit” nodes, and this would only get worse as time goes on.
Option 5: find a way to make the blockchain size constant relative to time, and ideally constant relative to output count.
Pros: everyone and their dog will eventually (or maybe even immediately depending on how small it can be made) be able to trivially run their own node, even on smartphones. This will not only fix the spy node issue, but will also make the network much more secure. Cons: This may be impossible to do, and is at the very least very difficult. This would likely be bottlenecked by FCMP, as the changes made by FCMP would almost definitely influence the implementation.
nahuhh
Gingeropolous
Monero’s remote node problem
As we’re all aware, the cryptosphere is abuzz with the recent leaked chainalysis video, in which they claim the ability to track monero transactions. One of their approaches is the incredibly sophisticated method of running a remote node and tracking the users that connect to it and the txs pushed by it.
As the one semi-responsible for the proliferation of the use of remote nodes, I feel I should take it upon myself to try and stir up our approach to this infrastructure hack that is the remote node network.
It was, and still is, a hack to allow users to hold their own keys and transact on the monero network without downloading the blockchain. This is obviously useful for those using wallets on their phones or other low-storage, not-always-on devices. However, there are clear downsides as demonstrated by the chainalysis intrusion – anyone can operate a remote node, including spies.
The Rationale for the remote node network
In my mind, the counterpoint has always been that with the availability of the “instant-on” nature of a new user using the Monero-GUI with a remote node, the user is more likely to keep using the Monero GUI instead of becoming impatient with the initial-blockchain download and abandoning the Monero GUI for some third party solution that has a high probability of being a scam wallet such as Freewallet or any number of wallets you’ve never heard of (but somehow users on r/monerosupport have found.)
Furthermore, once the GUI is installed, there’s a higher probability that the user will actually sync their own blockchain.
(However, one could argue that most new users are on mobile, so the behavior of the GUI is relatively moot).
The existing landscape
In order for everyone to be on the same page, the current state of the remote node network is as follows, as far as I’m aware. Node operators can open their RPC port to allow users to connect to their node to obtain blockchain data and to push transactions. This can either be done manually, using a combination of –rpc-restricted-bind-port and –rpc-bind-ip and (I think) –restricted-rpc. Or, one can use an “automatic” configuration, using the --public-node, which “Allow other users to use the node as a remote (restricted RPC mode, view-only commands) and advertise it over P2P.” In the manual configuration, the node operator then needs to advertise their node via a directory service like monero.fail , or have their node IP in a domain name DNS entry, like node.moneroworld.com. Additionally, there are some directory providers that scan the monero p2p network for open RPC ports (18089 as opposed to 18081) and then serve those IP addresses via DNS in a geolocated manner to end users that connect, like opennode.xmr-tw.org. In the automatic configuration, the node now indicates to the monero p2p network that its RPC port is open. The automatic configuration and its p2p listing are used by the monero GUI in simple mode, such that a simple mode GUI user is connected to a random monero node that has the –public-node flag active. As far as I’m aware, most mobile wallets do not use the monero p2p network listing, but instead offer defaults, usually hosted by the wallet provider (like xmr-node.cakewallet.com).
Anyway, lets list our options.
I won’t list this as one of the options because it makes a hierarchy weird, but this is our base state: Do nothing. Things are fine, and remote node operators and directory providers just need to do a better job keeping their resources trustworthy, and users should understand the risk and accept the risks of using another persons node. Pros: Easy. Cons: Trustful, doesn’t really address the problem. Puts high expectations on users to be knowledgeable of the risks, and expects remote node operators and directory providers to be super l33t.
Option 1: Attempt to shut down the remote node network. Disable the simple and bootstrap option in the monero GUI.
Pros: Easy to disable in GUI Cons: Unknown whether the entire community will shut down their remote node operations. Users that use remote nodes will seek other solutions, and some percentage of them may be worse than the current situation. Remote nodes that remain will probably be spy nodes.
Option 2: Flood the monero network with remote nodes. Design the daemon software so that the RPC port is open by default, even for GUI users.
Pros: Relatively easy to implement, code-wise. Cons: Unknown how effective this could be, considering some % of users will be behind a firewall that they don’t know how to open. Spy nodes still exist, but its less likely users connect to them. Honestly not really a great option.
Option 3: i2pify / torify all the things. Get i2p and/or tor baked into the monero software so that remote nodes can only offer hidden services, and remote-node users can only connect via i2p and/or tor.
Pros: really takes care of the whole thing, at least regarding IP association. Cons: heavy, heavy code work (relative to other options), and some of it falls on 3rd party developers for mobile wallets. Unless its bisq-like (where things just happen using tor, no user initiative needed), it probably won’t be used.
Option 4: modify remote node network behavior to make it better. For instance, can the RPC enabled nodes perform their own kind of dandelion?
Pros: probably easier than baking in i2p Cons: depends on numerous RPC nodes existing, might require 2 to be most effective. Ends up being just another shell game, in which a high penetration of spy nodes renders this countermeasure useless.
Option 5: find a way to make the blockchain size constant relative to time, and ideally constant relative to output count.
(added by @preland ) Pros: everyone and their dog will eventually (or maybe even immediately depending on how small it can be made) be able to trivially run their own node, even on smartphones. This will not only fix the spy node issue, but will also make the network much more secure. Cons: This may be impossible to do, and is at the very least very difficult. This would likely be bottlenecked by FCMP, as the changes made by FCMP would almost definitely influence the implementation.
So far, options 2-4 really address only the IP tracing. None of these options address the fact that malicious remote nodes can offer poisoned data. I think there are aspects of seraphis / jamtis that function as countermeasures for poison data delivery.
Any other options people can think of?