The Public Remote Node Problem

[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?

[preland]

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]

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.

They don't 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.

method of using @Gingeropolous's proxy

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.

Even though you run a, or multiple, nides yourself, youre also directly responsible for forwarding users traffic directly to chainalysis / feds.

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.

No it isnt. It's literally by design.
Electrum is a "hack".
Monero wallets are a separate piece of software (not a part of monerod). They are (by design) intended to connect to an external node. Whether the node is on localhost, LAN or across the ocean is just a matter of an ip address change.

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.

All nodes are "remote nodes" in relation to the walet software. Again, monerod does not contain a wallet.

You sound like youre writing about bitcoin and electrum...

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.)

You must be referring to simple/bootstrap mode. Monero GUI also includes monerod ajd the ability to run a full node.

Bootstrap mode being bad has nothing to do with the ability to use remote nodes. It's bad because the nodes that it chooses are nodes which had to opt in to --public-node, and are very likely to be honeypot nodes.

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).

I'm not at all understanding what youre getting at. monerujo is the only wallet that randomly chooses a node from a list. None of the mobile wallets use simple/bootstrap mode, as that requires monerod.

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.

--rpc-restricted-bind-ip
--rpc-restricted-bind-port

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.

the crazy thing is that you proxied node.moneroworld.com to spy nodes AND to another proxy.

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).

you can connect a mobile wallet to a node that uses bootstrap mode and use the nkde as a proxy...

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.

the problem is always trust.
The only knowledge it expects of users is for them to understand that, if using clearnet, the receiving node can correlate your IP to the TX that your submitting directly to the nodes RPC port. Your ISP can as well.

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.

Kill --public-node = good
Kill bootsstraps "auto" mode = good

Shut down remote node network? What are you even talking about. All nodes are remote in relation to wallets.

killing bootstrap mode isnt necessary. I can specify whatever node i feel like, whether i run it locally or not.

killing remote nodes isnt even possible without forcing monero to behave like btc, which is worse for privacy (everyone usinf electrum).

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.

retarded.

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.

the code work for this isnt heavy heavy, what r u talking about?? still a stupid idea.
Do you even know how tor/i2p work?? They are essentially port forwarding .... if i can port forward to onion, i can port forward to clearnet. Theres nothing stopping me from serving my "onion-only" rpc to a clearnet bind via iptables, ssh port forwarding or many other solutions.

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.

😑😑😑 are you trolling

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.

If everyone runs a node, its the same as broadcasting your tx yourself. Its not good for privacy.
It literally does NOTHING to address privacy concerns.

[preland]

Doesn't Dandelion++ mitigate linking IP addresses with transactions? (As long as you are running your own node and not using an untrusted node) If so, I don't see how everyone running a node would harm privacy.

[nahuhh]

Doesn't Dandelion++ mitigate linking IP addresses with transactions? (As long as you are running your own node and not using an untrusted node) If so, I don't see how everyone running a node would harm privacy.

I don't want to get into details, but the tldr is:

you cant trust dandelion, due to design choices / flaws.

The majority of nodes allow me to know that they are the origin

--tx-proxy using tor + i2p isnt a perfect solution, but is much better for both propagation times and privacy.

the problem is that we haven't seen anonymous-inbound or hidden services get attacked / sybilled yet, and its very attackable. Its not a panacea either. disable_noise on tx-proxy helps, as it acts similar to feathers multibroadcast.
Relying on external networks is never a good idea though. Tor onion services were attacked brutally a few months ago and a lot of onions were completely unreachable. I2p has had its own ddos issues in the past as well.

[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.

They don't 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.

method of using @Gingeropolous's proxy

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.

Even though you run a, or multiple, nides yourself, youre also directly responsible for forwarding users traffic directly to chainalysis / feds.

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.

No it isnt. It's literally by design. Electrum is a "hack". Monero wallets are a separate piece of software (not a part of monerod). They are (by design) intended to connect to an external node. Whether the node is on localhost, LAN or across the ocean is just a matter of an ip address change.

What I mean is that it seems the software was not really designed for 1 monerod to be serving 50+ or 100+ RPC connections. To me, the fact that the old software would allow any RPC connected wallet to initiate mining on the daemon suggests that the original design of the software didn't consider that the wallet user would be different than the daemon user.

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.

All nodes are "remote nodes" in relation to the walet software. Again, monerod does not contain a wallet.

You sound like youre writing about bitcoin and electrum...

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.)

You must be referring to simple/bootstrap mode. Monero GUI also includes monerod ajd the ability to run a full node.

Bootstrap mode being bad has nothing to do with the ability to use remote nodes. It's bad because the nodes that it chooses are nodes which had to opt in to --public-node, and are very likely to be honeypot nodes.

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).

I'm not at all understanding what youre getting at. monerujo is the only wallet that randomly chooses a node from a list. None of the mobile wallets use simple/bootstrap mode, as that requires monerod.

What I was getting at is that a reason for a network of available remote nodes to exist is that a new user will have an instant-on user experience, and be more likely to continue running the monero software. However, this is somewhat irrelevant because most new users these days probably are using a mobile wallet. So there's no incentive to provide GUI users with an instant on experience, at least from the perspective of getting them to run their own monerod, eventually.

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.

--rpc-restricted-bind-ip --rpc-restricted-bind-port

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.

the crazy thing is that you proxied node.moneroworld.com to spy nodes AND to another proxy.

I think at one point it was pointing to opennode.xmr-tw.org , and then I switched it to like 5 nodes from members of the community once I became aware that the remote node network was being infiltrated. afraid.org DNS doesn't allow mixing CNAMES and A records for the same subdomain.

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).

you can connect a mobile wallet to a node that uses bootstrap mode and use the nkde as a proxy...

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.

the problem is always trust. The only knowledge it expects of users is for them to understand that, if using clearnet, the receiving node can correlate your IP to the TX that your submitting directly to the nodes RPC port. Your ISP can as well.

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.

Kill --public-node = good Kill bootsstraps "auto" mode = good

Shut down remote node network? What are you even talking about. All nodes are remote in relation to wallets.

I mean shutting down directory providers or proxies, like monero.fail, opennode.xmr-tw.org, or node.moneroworld, etc.

killing bootstrap mode isnt necessary. I can specify whatever node i feel like, whether i run it locally or not.

killing remote nodes isnt even possible without forcing monero to behave like btc, which is worse for privacy (everyone usinf electrum).

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.

retarded.

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.

the code work for this isnt heavy heavy, what r u talking about?? still a stupid idea. Do you even know how tor/i2p work?? They are essentially port forwarding .... if i can port forward to onion, i can port forward to clearnet. Theres nothing stopping me from serving my "onion-only" rpc to a clearnet bind via iptables, ssh port forwarding or many other solutions.

Yes, I'm aware. What I'm talking about is providing a user experience like how bisq operates. head to https://bisq.network/ , download their software, and watch it magically connect to the bisq and bitcoin networks using tor, all without the user doing anything. Your average user is not going to be knowledgable or comfortable doing the things you described.

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.

😑😑😑 are you trolling

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.

If everyone runs a node, its the same as broadcasting your tx yourself. Its not good for privacy. It literally does NOTHING to address privacy concerns.

I appreciate your response, but I'm having a hard time gleaning anything that moves us forward. You seem to propose that we do nothing, and continue to expect users to figure out i2p or tor on their own.

[nahuhh]

People like you, pushed for and told ppl to use remote nodes. You, as a "trusted" member of our community, irresponsibly and negligently forwarded users traffic to federal agents. This was against long running advice of "ONLY use nodes where you trust the operator".

youre still running this proxy smfh. and was still pointed to the TW proxy as of a few days ago.
point it to your own node or fkoff. Youre the problem. Trust is the problem. Trusting people who mishandle your data is the problem.

wallet cli even has a flag for --this-is-probably-a-spy-node

monero doesnt support i2p-sam
monero doesnt support tor control

It should support both, should auto-configure tx-proxies and anonymous inbounds.

2. monero doesnt even support blockchain sync over tor/i2p.

3. Monero doesnt encrypt p2p network traffic, and uses self signed certs for rpc traffic (which are easy to MITM). peerlist store ip address, not domain names. You can specify certs to use for your node, but only cli has cert pinning.

4. the root solution to decoy tracking is fcmp.
   so sit back and wait.

5. the solution to ip obfuscation for ANY service, is to use a privacy preserving protocol. Whether that be personal vpn using an anon vps, tor, onion or i2p.
   you cant use ANY service over clearnet HTTP and expect privacy. Its not monero's job to fix clearnet.

monero network traffic is easily monitored and intercepted.
Using a vpn is putting lipstick on a pig.
using tor exit nodes w/o encryption is pointless.
using centrally issued certs requires a domain name.

tldr: solution?

• i2p-sam
• tor control
• kill the "auto" bootstrap parameter
• onion/i2p remote nodes to be recommended but nothing should prevent anyone from use whatever rpc they manually decide to.

the following wallet all support privacy

• cake (socks, includes onion node)
• stack (tor included, default node has a cert but no cert pinning, doesnt include onion node)
• mysu (socks + tor included + onion and i2p nodes included)
• anonero (socks + tor enforced)
• feather (socks + tor included + onion nodes included)

expect users to figure out i2p or tor on their own.

GUI is the only major wallet that has terrible defaults and hard to enable privacy protections.
other wallets offer good privacy to their users.

where other wallets slipped up, was trusting node.moneroworld.com.

stack ONLY ships their own node.
I've advised cake to remove all clearnet nodes that they do not control
speaking to monerujo is a waste of time
feather uses an included tor binary by default, and has onion nodes.

Its trusted node operators + wallet makers jobs to ensure that they are handling your transactions in a private and secure manner.

the problem is simple: people like you who run honeypots like node.moneroworld.com and push(ed) public-node and simple mode, despite well known privacy issues with offering such convenience without any network level protections

[preland]

I am the one who is working on I2P sam integration for monero btw; it’s been a rly tough job for me this past year (plus with me balancing a metric ton of irl stuff while doing it), but I think it should be finished by year’s end (same with neroshop’s I2P integration, though that could take longer since it needs UDP data gram support, which is tougher and currently less documented than TCP). Not sure how long it’ll take to get merged after that point.

[nahuhh]

I am the one who is working on I2P sam integration for monero btw; it’s been a rly tough job for me this past year (plus with me balancing a metric ton of irl stuff while doing it), but I think it should be finished by year’s end (same with neroshop’s I2P integration, though that could take longer since it needs UDP data gram support, which is tougher and currently less documented than TCP). Not sure how long it’ll take to get merged after that point.

also this

monero-project/monero-gui#4337

[preland]

I am the one who is working on I2P sam integration for monero btw; it’s been a rly tough job for me this past year (plus with me balancing a metric ton of irl stuff while doing it), but I think it should be finished by year’s end (same with neroshop’s I2P integration, though that could take longer since it needs UDP data gram support, which is tougher and currently less documented than TCP). Not sure how long it’ll take to get merged after that point.

also this

monero-project/monero-gui#4337

Huh, I wasn't aware that someone had resumed work on the GUI

Tbh that PR was abandoned, so if they can get it working then I'll be happy

[Gingeropolous]

again, i wasn't "pointed to the TW proxy as of a few days ago", again because I can't mix cnames and A records. I think that changed that in 2020, like I stated. And in the video the tracing was from 2020.

I think I'll just point people to monero.fail now, where there is no warning about using a remote node at all, and users should just figure it out.

you cant use ANY service over clearnet HTTP and expect privacy. Its not monero's job to fix clearnet.

I agree.

other wallets offer good privacy to their users.

What wallets? As far as I know, people use cake, monerujo, stack, and feather.

Anyway, it seems your general comment is for option 1, to shut down the public remote node offerings, and for option 3, to get i2p or tor more user friendly.

[nahuhh]

again, i wasn't "pointed to the TW proxy as of a few days ago", again because I can't mix cnames and A records. I think that changed that in 2020, like I stated. And in the video the tracing was from 2020.

youre right. My mistake.

I think I'll just point people to monero.fail now, where there is no warning about using a remote node at all, and users should just figure it out.

better: you should stop offering any advice.

responsible ppl:

1. Recommend against untrusted nodes
2. Warn about clearnet nodes
3. Advise that onion/i2p rpc are best practice if you must use a remote node,
   4 cont. And tx-proxy / anon inbound especially if its your own node

other wallets offer good privacy to their users.

What wallets? As far as I know, people use cake, monerujo, stack, and feather.

Feather, stack, and mysu include tor daemons by default
feather, mysu, cake support i2p via socks
monerujo supports tor via orbot, but implementation is terrible
cake supports tor via socks

feather enables tor by default
anonero forces tor by default

feather includes onion nodes
cake includes onion nodes
mysu includes onion and i2p nodes

etc.

Anyway, it seems your general comment is for option 1, to shut down the public remote node offerings, and for option 3, to get i2p or tor more user friendly.

I literally said
Dev:
kill "auto" bootstrap
kill --public-node

users:
emphasize that "trust" = real trust
clearnet is not friendly, even if you trust the node op. Use onion/i2p for sending tx¹

wallets:
enable cert pinning
¹prefer onion/i2p for sending transactions

node runners:
setup tx-proxy and anon inbound

[jeffro256]

Option 6:

Write a new type of wallet that crawls the p2p network, verifies PoW, and downloads block data from peers. All calculations (fee calc, decoy selection, FCMP tree building) are performed by pulling against data which is verified to be part of the blockchain. Then broadcast transactions only over an anonymity network to random peers. This type of wallet would be a lot more expensive to run than today's full wallet, but much less expensive than a full wallet + local node, and without the storage requirements. This would have a "leeching" effect on the p2p protocol, which might negatively effect node-to-node traffic.

[monero-love]

Something I think should be taken into consideration is that in parts of the world where monero and privacy are paramount for decedents activists, journalists and the like, think Venezuela, Iran, and the United States, downloading the whole blockchain on spotty connections with a netbook from 2009 all the while keeping it synced is a big ask.

Sure, you can get a VPS at a non-KYC host and run a node independently, but some folks don't have the means, skills, or time to do so. How will you fire up Tails and connect to a node without a public node? The barrier to entry for the casual user is still high. That isn't just a Monero-specific problem. Gupax is incredible and, for the most part, point-and-click, yet casual users still have issues.

TOR had/has a similar issue with rouge relays.

Public nodes are necessary, and the community's smart folks will figure out a solution.

chime in smart folks.

[boldsuck]

3. Monero doesnt encrypt p2p network traffic, and uses self signed certs for rpc traffic (which are easy to MITM).

I created CAcert.org certificates for all my nodes. Is it useful to create DANE DNS record?
I saw @vtnerd is working on it: ccs vtnerd 2024-q3

Using a vpn is putting lipstick on a pig.

ROFL

kill --public-node

Should we disable/comment out this on the remote nodes as well?

node runners:
setup tx-proxy and anon inbound

I have, and anyone who trusts me/my nodes is welcome to use the onion addresses.
There is plenty of bandwidth available.