Remote nodes

[Jaqueeee]

See discussion in #572 and #602

Not ready to be merged yet.

• Added page in wizard for daemon settings
• Added option to automatically connect to remote node while syncing local node
• added node.xmrbackb.one and node.moneroworld.com to dropwdown in wizard and settings

Ping @Gingeropolous, Snipa (github user?)

[ghost]

I am strongly against the idea of adding a dropdown list of remote nodes to the GUI. Here's my thoughts as posted recently on Reddit (source):

how does having a drop down list make it centralized?

Great question. It's the exact situation we struggled in the GUI with during the Dwarfpool hashrate centralization problem that happened in December. To combat the miner centralization, we rushed to include pool mining (not just solo mining) in the official GUI. In the end, we decided against it, because having a list of pools in the GUI would amount to a certain degree of centralization, along with all the problems inherent in that. Here's what I wrote at that time (source):

Pool mining is the one page in the wallet where we're suddenly relying on a third party. What qualifies a pool to be added to this list? Certainly cryptmonero.com isn't included since this pool is tied to Reddit-reported malware mining. So there is already a distinction between good and bad pools, and suddenly our devs are tasked with making that distinction. Suddenly our work begins to grow exponentially, especially if XMR really takes off and a hundred new pools appear and have to be evaluated. Who does the evaluating and what is the criteria?
Suddenly pool operators have an incentive to get in good graces with XMR devs? Already we can see MoneroWorld (where I personally mine, so I love it there) is at the top of the list?
What if one of the listed pools gets hacked, malware, or leaks private data? Are we partly responsible / could be sued? We have to wait for a whole release before we can change the code away from an adversarial pool?
This is not decentralized, and thus sort of goes against the spirit of The Monero Project.

Including a list of default remote nodes in the GUI leaves us with a similar (albeit milder) situation. It tasks us with maintaining a list of good and bad remote nodes, adding to the official dev workload. It creates vulnerabilities within the GUI, where if one node gets compromised then a large portion of Monero users are at risk simply by using the official software. And removing a compromised remote requires an entire software release, and not all users update their software religiously, so the problem could be with us for years.
Decentralization is our credo. I'm personally open to compromising on this value, but it needs to be non-contentious and very thought out.

[Snipa22]

I could see the complaint for this. Perhaps there's something to be said here for the possibility of moving to SRV records? I know that I would happily register my nodes in a central database that could maintain a status check on all of the nodes involved.

It would be a small set of changes to move such support into something like: https://github.com/monero-project/xmr-seeder (Which I already redid to CF support), and using SRV records, we could use non-standard ports that would be registered at the DNS servers. Then an automation tool could manage these records, keeping an eye on the state (Height anyone...) of the nodes and knock them in and out automatically.

This would allow the DNS records to be controlled centrally by the Monero project, and would allow control without excessive centralization, then allow a manual punch-in override box. Yes, it's still centralization, but it's no better/worse than the current DNS seeding system in my eyes.

[ghost]

As mentioned in #602 I think we should wait with integrating non-manual node support until we have a discussion with the wider dev community, perhaps include this as an item during the Sunday dev meeting. If people like it, the concept of scanning the p2p network for open remote nodes (or whatever mechanism we decide on) could be integrated at the protocol/CLI level, and the wallet could simply add pure GUI functionality (which, I think is all we've been doing anyways).

[danrmiller]

Snipa22 wrote:

but it's no better/worse than the current DNS seeding system in my eyes.

What are the specific privacy implications to using a remote node?

EDITED: [Suggesting a node to connect to is less severe than suggesting a node to leak all the outputs you are interested in to.]

[fluffypony]

I'm against this as I don't think we should be encouraging remote nodes at all - they place an incredible burden on the network by chewing up the same amount of downstream bandwidth as a full node, but with no upstream assistance to the network, and with no validation. People are better served either running a full node, or waiting for the light wallet / remote viewkey scanning stuff that we're building out. If people want to manually connect to a full node, that's fine, but we shouldn't make it easy:)

[SamsungGalaxyPlayer]

@danrmiller see here.

You no longer leak the outputs you are interested in, but you connect your IP address with your outgoing transactions, and you leak some other metadata.

[Jaqueeee]

@fluffypony Don't really understand what you are saying here. There's no difference between a remote node and and a local node in p2p bandwidth usage. If you are referring to the wallet bandwidth usage it's ~98% less than a node after the recent wallet optimization work iirc. Please correct me if i'm wrong @moneromooo-monero and @luigi1111.

I do however fully understand the points raised by @xmr-eric about centralization.

The point of this PR is to improve the user experience by speeding up the time between download and first usage from several hours to seconds. As soon as the local node is synced the wallet automatically switch to the local node.

[fluffypony]

@Jaqueeee a wallet needs all the block headers, and then it needs a copy of every new tx output as blocks come in. That's ~the same bandwidth as a full node, from an inbound perspective, just that it doesn't have to relay blocks are txs so it doesn't use upstream bandwidth.

[ghost]

Monero's principle is Security by Default. So the GUI should not encourage users to use untrusted (random) remote nodes.

[dternyak]

This is ultimately a debate over optimizing for usability or privacy. There is not a lack of a security by using untrusted remote nodes, but a lack of privacy (and only some loss of privacy). Additionally, it wouldn't need to be the default option, only an option. Personally I believe the slight hit to privacy to be okay in this instance, as *most* users will opt to use a remote node anyway, whether its through a light-wallet or this. This just makes it easier for them to do it. Riccardo's point about the node getting some extra usage is a good one, so perhaps we don't want to encourage usage of remote nodes at such a level that those nodes begin to suffer.

…

On Sat, Mar 25, 2017 at 2:31 PM, maitscha ***@***.***> wrote: Monero's principle is Security by Default. So the GUI should not encourage users to use untrusted (random) remote nodes. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#605 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHf02exPO_QtFvSFfPMGPAsFyTTyCcX0ks5rpWt6gaJpZM4MouoZ> .

[fluffypony]

Ok it's added to the meeting agenda for tomorrow's dev meeting, so we can discuss it then.

monero-project/meta#58

[MBuffenoir]

What about having a normal mode where everything is taken care of for you (automatically connecting to a load-balanced pool of remotes nodes) and an advanced mode (where more options granularity is available ?)

[Jaqueeee]

@dternyak after recent wallet optimizations the bandwidth used by each wallet is not a big issue. However, the trust issue seems to be the biggest concern. I'll remove the dropdown by request from @fluffypony. People who want to use remote nodes will need search for them.

[Jaqueeee]

Dropdown replaced with an empty input field.

• added advanced daemon settings checkbox
• renamed "start/stop daemon" to "start/stop local node"

Please test @xmr-eric and @medusadigital

Question is if this PR adds any value to the user when they have to input the daemon address manually? I think it does because it adds a page in wizard where new users gets information about daemon/node setup. It also makes it easier to follow the status of the local node sync when connected to a remote node.

[iamsmooth]

@fluffypony I don't understand how headers+outputs would be similar bandwidth to a full node. That would not include signatures nor range proofs, which make up most of the current bandwidth usage.

Eventually I think lightweight wallets (by which I mean lightweight in terms of bandwidth) are very possible with ~90% less bandwidth usage than full nodes (not even factoring in upstream). They can use the p2p and check PoW just like Bitcoin light wallets do. (This might require some protocol changes, but it is do-able). There was a previous objection to this concept raised elsewhere in terms of a wallet with private keys in process memory making untrusted p2p connections, but that could be addressed with a separate "light deamon".

Whether that is desirable in terms of privacy and security is a different matter.

[Jaqueeee]

Closing for now. Could bring up the discussion again after next beta.